Combining marks advance width
Adam Jagosz
Posts: 689
Sooo, when developing fonts with FontForge, I got used to desigining my combining marks on a width of an average letter. The main reason was that it's impossible to select for edition a zero-width glyph, so I'd need to open it in new tab every time I needed to adjust something (prove me wrong?). I never experienced any ill effects of this approach, though I wondered if it would break in some obscure software I never used.
But when I moved my project into FontLab VI (btw just exporting and importing UFO is just a brief prelude to porting the whole project including features... thanks FL), I discovered that the exported font does require combining marks to be zero-width, otherwise there's a gap after the positioned mark.
Any way to collapse width automatically on export in FontLab VI? Or an idea on how to do it manually on a batch of glyphs?
What's interesting to me is where the difference actually comes from. Does FontForge add extra code to GPOS upon export to collapse the advance widths when glyphs are positioned?
Btw my preference (if wrong) is for combining marks to be non-zero-width. This way I see it clearly when positioning is missing or fails and I can do something about it. When it's zero-width (and especially positioned to the left of the sidebearings), it may well look as if positioned, which is a nice fallback in some cases, but produces an ugly illegible clash in others, and inhibits completing the feature properly.
Tagged:
0
Comments
-
I found that I can batch set width using Tools > Actions, then rebuild mark and mkmk features.I wonder if there is a possibility that I need to adjust/fix something somewhere else, like some complex feature code if I had some. I hope not. In FontForge changing left sidebearing of glyph would make its references misaligned, but not in FontLab, luckily.0
-
If you used mark attachment, then the sidebearings don’t matter... as far as the attaching goes.
Yet, strictly speaking, the combining marks with “zero-width” in their long name in Unicode ... are supposed to have zero advance width.
In FontLab VI, use Tools > Actions > Metrics > Set Width. Enter zero, and use the drop-down to tell FontLab where you want the width taken from: right, left or both sides.0 -
The composite glyphs (actually using references, because of a related issue affecting composites that copies all anchors — not as “smartly” as advertised — upon export) using mark attachment turned out fine, but I had some composites that were made using custom recipes with a script I wrote for FontForge: most notably i-accents with narrowed down diacritics, and some Vietnamese letters with a top diacritic and dot below. /ij also had the second tittle shifted.Not sure what you meant asking if I used mark attachment. I didn't use Auto layers, obviously. And my composites were converted to references, save for a couple stubborn nested composites that I discovered weren't converted when I used a global command. Actually these ones were the ones that suffered.0
-
For these i-components (and also i-cy and iota), it appears the components were groupped (why? FontForge has no notion of groups...) and and they weren't converted to references because of that maybe.The component here has an X delta that would be correct for the reference itself, but applied to the component it fails.I know I should be hitting the support desk, but I'm just not sure how to phrase this as an issue. Intangible.0
-
Glyphs.app is setting the marks to zero width automatically on export. No extra steps involved.
1 -
Glyphs.app is setting the marks to zero width automatically on export. No extra steps involved.
How are you setting marks to zero? Collapsing to origin point? Collapsing to anchor? Collapsing to RSB?0 -
Adam Jagosz said:What's interesting to me is where the difference actually comes from. Does FontForge add extra code to GPOS upon export to collapse the advance widths when glyphs are positioned?FontForge will try to guess the GDEF glyph class and most of time it will correctly set mark class for mark glyphs. Some layout engines (e.g. Uniscribe and HarfBuzz) will zero the width of glyphs with mark class, others (e.g. Core Text, last I checked) don’t.2
-
@Khaled Hosny Translating into layman's terms: there's a big chance fonts with non-zero-width marks will not work as expected in some apps on iOS (those that don't use HarfBuzz)?Btw, this means FontLab doesn't set glyph classes automatically (I compared files exported from FF and FL).0
-
I place combining accents so they will be placed properly over a preceeding 'u'. For those applications which don't support mark attachments features, this results in most diacritics being at least readable even if they aren't well-spaced. I'd rather do this manually than have an application set the widths to zero unless I knew exactly how it would achieve that.1
-
Adam Jagosz said:@Khaled Hosny Translating into layman's terms: there's a big chance fonts with non-zero-width marks will not work as expected in some apps on iOS (those that don't use HarfBuzz)?
You can compare theBtw, this means FontLab doesn't set glyph classes automatically (I compared files exported from FF and FL).GDEF
table of the two fonts usingttx -t GDEF font.ttf
and see if there is a difference in the glyph classes.
0 -
Marks are usually non-spacing (zero advance width), as they just belong to the base character without changing the space occupied by the combination.
This article about how to go beyond precomposed characters by means of OpenType layout features might be of interest:
https://www.high-logic.com/font-editor/fontcreator/tutorials/latin-diacritical-marks-accents
1 -
For anyone looking at this beyond European scripts:
Sometimes it is necessary to class a glyph as a mark in GDEF in order to be able to filter it out of a GSUB or GPOS operation, and this can mean classifying a glyph that you want to be spacing as a mark, which means that Microsoft and Harfbuzz shapers will set the width of that glyph to zero. The best way to handle this is to set the advance width of the glyph to zero yourself, and then to use GPOS to add width to it. Of course, this has implications for how you build your kern adjustment and other lookups involving the width of such glyphs.5 -
I advise against making /i by combining dotlessi with dotaccent. Same thing for /j.
I did that in a typeface, and discovered that there are some layout applications which don’t render it correctly (eg Windows 10 Word).
2 -
No offense, but since I have made such font in the past without issues, I suspect it was an issue with your font. Can you please show us a font that has this issue, so we can know for sure what is going on?
0 -
It seems to me that there are multiple types of "combining" in this situation. Perhaps Nick and Erwin might each clarify which they mean?
Two possibilities occur to me off the top:
1) Creating precomposed glyphs using the dotless glyphs as components, and putting the composed glyphs in the regular /i and /j slots
2) Using 'ccmp' and dynamic mark attachment ('mark') and not even having precomposed glyphs for /i and /j.
I have done (1) often enough with no problems. I haven’t done (2) for these basic characters.0 -
2) Using 'ccmp' and dynamic mark attachment ('mark') and not even having precomposed glyphs for /i and /j.That's really not a good idea. The i and j characters do not have any Unicode decompositions, so will simply appear to layout engines as missing, causing either .notdef display or fallback to another font.
Even for characters that do have Unicode canonical decompositions, such as precomposed diacritics, you can't rely on layout engines to correctly display these if they're not supported with precomposed glyphs in the font. Alas, layout engines have favoured precomposed encoding and display for so long, they're far more likely to display decomposed sequences with precomposed glyphs than they are to display precomposed characters with decomposed glyphs.
4 -
We are both talking about 1. I've just located the previous topic were it was discussed:0
-
Yes, I recall now.
So my warning appears to be: if you make i and j from precomposed glyphs, use U+0307, with an advance width of zero, not U+02D9?
Although I haven’t tried that—rather, I’ve abandoned the idea as being too complicated to wrap my head around, and resorted to basic decomposed i and j.1 -
Both should work just fine, but combining marks are recommended.
0
Categories
- All Categories
- 40 Introductions
- 3.7K Typeface Design
- 793 Font Technology
- 1K Technique and Theory
- 609 Type Business
- 444 Type Design Critiques
- 536 Type Design Software
- 30 Punchcutting
- 135 Lettering and Calligraphy
- 82 Technique and Theory
- 53 Lettering Critiques
- 478 Typography
- 300 History of Typography
- 113 Education
- 65 Resources
- 494 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 161 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports