Glyphs 1.3.17
Monospaced font, in which all glyphs, including marks are width 600.
There are two different issues/questions here:
The combining marks, when exported, end up with a 0 width instead of the original 600, even those that start with comb in their name, e.g., breveinvertedcomb.
The .case versions keep their width of 600. In a monospaced font, I’d expect them to stay the same; in a proportional font, I’d make them 0 width.
I was trying to find solid info on the recommendation for the width of combining marks when in a monospaced font. One mention by John Hudson from 2009 is here: http://www.typophile.com/node/61330#comment-363963
Or, has the recommendation for monospaced fonts changed?
Are the mark and mkmk features built automatically, including for the .case variants for uppercase letters? Or do I need to add the positioning features for the .case variants, for now?
A quick test seemed to use the non .case variant and had the combining mark and uppercase glyph overlap. The blog post on Mark to Base Positioning: http://glyphsapp.com/blog/mark-to-base-positioning/
seems to indicate that some of the features are generated automatically, now, but didn’t include mention of the .case variants.
[ I’ll admit that I haven’t yet pulled apart the mark features in the exported font to review, yet. So more testing may show what’s needed here. ]
I disagree with John here. Combining marks should under no circumstances advance the cursor position, especially when the mark and mkmk features do not work. That, for me, includes monospaced fonts.
I need to look into that again, but I believe the …comb.case accents should be exchanged in ccmp and possibly also in the case feature.
I wonder if the issue, in the past, with monospaced fonts was some programs assuming that a font wasn’t monospaced if any of the glyphs were of a different width. I’m happy to go with whatever works, today. It was just difficult to find an authoritative recommendation for monospaced fonts.
The …comb.case marks do end up in the case feature.
Coming back to this. Has there been any change in this in the past 11 years? Currently, Glyphs exports combining marks in monospace fonts with advance width. Fontbakery treats this as a Fail (at least TypeNetwork’s profile does). I am unsure as to whom to trust.
Fontbakery checks are often inaccurate, or based on anecdotal evidence. I also use fontbakery, but trust my own research more
In my opinion, Glyphs exporting the combining marks with full advance width in monospaced fonts is correct. At minumum all encoded glyphs in a monospaced font must have the same advance width. Otherwise the font will not be accepted as monospaced in some environments, e.g. terminal emulators. In such cases, the font may not be selectable in such apps.
In my Sudo monospaced styles, I added this in the ccmp feature to use GPOS to set the widths of combining marks to 0 by subtracting the original width (448):
# Set width of combining marks to 0. Is this needed?
# PowerShell fails in any case, and centers the composed
# glyph inside the multiple width.
pos @Markscomb <0 0 -448 0>;
pos @MarkscombCase <0 0 -448 0>;
I’m not sure if this is needed …
Fun fact: If you set the combining marks width to 0 in a monospaced font, fontbakery will complain that there are too many different widths in the font.
It should be possible that combining marks keep their advance width even in proportional fonts, as the shaper engine should ignore their width when they are in the GDEF marks class. Zeroing their width is a workaround for buggy text processing implementations.
I have compromised on this ever since. There are indeed apps that misbehave if not all glyphs of a monospaced font have the same advance width assigned.
