-
Notifications
You must be signed in to change notification settings - Fork 102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow zero width glyphs in monospaced fonts, fixes #1076 #1077
Conversation
@graphicore, could there be a better solution. In a Monospace there are three valid widths: 0, $width, $double_width. There's only about a dozen that could be zero-width. And those that are normal or double-width are laid down in the Unicode database. ie. rather than simply allowing everywhere, would it make sense to check that zero-width only concurs on that those that it might be sensible for? |
If the fonts sets PostScript isFixedPitch or the corresponding PANOS bit, then all glyphs no matter what should have the same width otherwise Windows and older version of FreeType would use wrong glyph widths. DejaVu Sans Mono worked around this by given the glyphs that should be zero-width and advance width, then have GPOS single pos lookups that zero their widths. If the font does not set any of those two bits, it should be fine to have glyphs with different width but some applications that need to identify monospaced fonts will not recognize it as such. |
I think that we should be pessimistic, so the current code is - I think - what I want. We should make a note in the output that, if there are are non-$width glyphs, they should use set the glyphs that should be zero-width and 2x-$width to $width, then add a GPOS single pos lookups that zeros/doubles the widths. And we could even have an autofix for that, but its in the future (milestone v2.0.0) |
All diacritics in that font are zero width, this is a lot actually. Making the diacritics zero width is widely considered best practice. This is done for similar legacy reasons as Khaled mentions in his argument for having all glyphs the same width: old and broken systems. In this case, I can make the diacritics $width, but I wouldn't do the GPOS thing with them. Because garbage systems who can't apply diacritics properly may also not apply GPOS properly. The only other glyph would be |
AFAIK, Core Text does not zero-width the mark glyphs (unlike Uniscribe and HarfBuzz), so you will need to test there to see if giving them a width breaks any thing. |
Is the concern with "Windows and older version of FreeType would use wrong glyph widths" that Win/FT will use a global value, ignoring all per-glyph advanceWidths? If a diacritic glyph with zero width is instead typeset with a global advanceWidth, what's the problem? |
IIRC (but this was long time ago), you can end up with Windows giving all glyph zero width. |
Right, if the glyph picked to set the global $width has a zero advanceWidth, it will break like that. So, some non-$width (eg, zero/double width) glyphs are allowed, as long as they aren't picked for the global $width. @aaronbell How is the global $width picked by Windows? @lemzwerg How is the global $width picked by FreeType? |
(and, @graphicore , for the purposes of shipping VT323, please just leave the zero-width diacritics in, and test on Windows :) |
It seems that there's still no consensus on this issue, so I'll leave this pull request open and not merged for now. |
@felipesanches sure, leave it! |
Yes, thanks
|
Still not fixed? Or I failed to update fb properly? PressStart2P Combining accents are zero width — as they should be — and fontbakery considers this as an error. Tested on his ttf
mtx of zero width glyphs:
Full hmtx table: |
@davelab6 said: "if there are are non-$width glyphs, they should set the glyphs that should be zero-width and 2x-$width to $width, then add a GPOS single pos lookup that zeros/doubles the widths." |
No description provided.