Combining marks advance width

Adam Jagosz

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.

Adam Jagosz

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.

Thomas Phinney

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.

Adam Jagosz

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.

Adam Jagosz

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.

Georg Seifert

Glyphs.app is setting the marks to zero width automatically on export. No extra steps involved.

John Hudson

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?

Khaled Hosny

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.

Adam Jagosz

@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).

André G. Isaak

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.

Khaled Hosny

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)?

Yes, most likely.

Btw, this means FontLab doesn't set glyph classes automatically (I compared files exported from FF and FL).

You can compare the GDEF table of the two fonts using ttx -t GDEF font.ttf and see if there is a difference in the glyph classes.

Erwin Denissen

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

John Hudson

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.

Nick Shinn

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).

Erwin Denissen

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?

Thomas Phinney

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.

John Hudson

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.

Erwin Denissen

We are both talking about 1. I've just located the previous topic were it was discussed:

https://typedrawers.com/discussion/comment/39992/#Comment_39992

Nick Shinn

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.

Erwin Denissen

Both should work just fine, but combining marks are recommended.