Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

graphicore
Copy link
Collaborator

No description provided.

@sladen
Copy link

sladen commented Sep 29, 2016

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

@khaledhosny
Copy link
Contributor

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.

@davelab6
Copy link
Contributor

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)

@graphicore
Copy link
Collaborator Author

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?

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 NULL, and I think I can make it $width and must not even do the GPOS kung-fu, right?

@khaledhosny
Copy link
Contributor

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.

@davelab6
Copy link
Contributor

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?

@khaledhosny
Copy link
Contributor

IIRC (but this was long time ago), you can end up with Windows giving all glyph zero width.

@davelab6
Copy link
Contributor

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?

@davelab6
Copy link
Contributor

(and, @graphicore , for the purposes of shipping VT323, please just leave the zero-width diacritics in, and test on Windows :)

@felipesanches
Copy link
Collaborator

It seems that there's still no consensus on this issue, so I'll leave this pull request open and not merged for now.

@graphicore
Copy link
Collaborator Author

@felipesanches sure, leave it!

@davelab6
Copy link
Contributor

davelab6 commented Sep 29, 2016 via email

@alexeiva
Copy link

Still not fixed? Or I failed to update fb properly?

PressStart2P
is a monospaced font (width=1000).

Combining accents are zero width — as they should be — and fontbakery considers this as an error.

Tested on his ttf

ERROR    Font is monospaced but 6 glyphs (0.911854103343%) have a different width. You should check the widths of: ['gravecomb', 'acutecomb', 'uni0335', 'brevecombcy', 'uni0326'] Changes that must be applied to this font: post isFixedPitch from 0 to 1 | OS/2 panose.bProportion from 0 to 9  

mtx of zero width glyphs:

    <mtx name="NULL" width="0" lsb="0"/>
    <mtx name="acutecomb" width="0" lsb="-610"/>
    <mtx name="brevecombcy" width="0" lsb="-810"/>
    <mtx name="gravecomb" width="0" lsb="-710"/>
    <mtx name="uni0326" width="0" lsb="-750"/>
    <mtx name="uni0335" width="0" lsb="-740"/>

Full hmtx table:
https://gist.github.com/alexeiva/435dd0bbce7832a8856ea9424e253432

@alexeiva alexeiva reopened this Oct 15, 2016
@felipesanches
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants