Combining marks advance width

Adam Jagosz
Adam Jagosz Posts: 689
edited September 2019 in Type Design Software
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:

Comments

  • Adam Jagosz
    Adam Jagosz Posts: 689
    edited September 2019
    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
    Thomas Phinney Posts: 2,896
    edited September 2019
    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
    Adam Jagosz Posts: 689
    edited September 2019
    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
    Adam Jagosz Posts: 689
    edited September 2019
    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
    Georg Seifert Posts: 674
    edited September 2019
    Glyphs.app is setting the marks to zero width automatically on export. No extra steps involved.
  • John Hudson
    John Hudson Posts: 3,227
    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
    Khaled Hosny Posts: 289

    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
    Adam Jagosz Posts: 689
    edited September 2019
    @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
    André G. Isaak Posts: 634
    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
    Khaled Hosny Posts: 289
    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
    Erwin Denissen Posts: 302
    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

  • Nick Shinn
    Nick Shinn Posts: 2,216
    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
    Erwin Denissen Posts: 302
    edited September 2019
    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
    Thomas Phinney Posts: 2,896
    edited September 2019
    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
    John Hudson Posts: 3,227
    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
    Erwin Denissen Posts: 302
    We are both talking about 1. I've just located the previous topic were it was discussed:
  • Nick Shinn
    Nick Shinn Posts: 2,216
    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
    Erwin Denissen Posts: 302
    Both should work just fine, but combining marks are recommended.

Categories