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.
Comments
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.
How are you setting marks to zero? Collapsing to origin point? Collapsing to anchor? Collapsing to RSB?
GDEF
table of the two fonts usingttx -t GDEF font.ttf
and see if there is a difference in the glyph classes.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
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.
I did that in a typeface, and discovered that there are some layout applications which don’t render it correctly (eg Windows 10 Word).
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.
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.
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.