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

Basic Latin: Significance of NULL and CR? #14

Open
madig opened this issue Feb 11, 2018 · 5 comments
Open

Basic Latin: Significance of NULL and CR? #14

madig opened this issue Feb 11, 2018 · 5 comments

Comments

@madig
Copy link

madig commented Feb 11, 2018

Why are these required? And what properties (contents, spacing, ...) should they have?

@felipesanches felipesanches transferred this issue from googlefonts/gftools Dec 17, 2021
@arrowtype
Copy link

Should these / can these be removed? It seems to be the consensus opinion...

#21

@anthrotype
Copy link
Member

they are not required, they are legacy TrueType recommendations and serve no purpose.

The "First Four Glyphs" section of the OT spec was removed since OT 1.8 (2016) (see changelog)

@bobh0303
Copy link

IMO, yes they should be removed. Currently, if CR (aka nonmarkingreturn) and/or NULL (aka .null) are included then one of two things happens:

  1. If the are unencoded, then fontbakery's unreachable_glyphs check complains about them.
  2. If the are encoded, then fontbakery doesn't complain but the OS2.usFirstCharIndex will have to be set below 0x0020 which (a) goes against the OpenType recommendations and (b) has been known to cause problems — at least in the past — with some software.

Can we just do this? If we are concerned about risk of some latent bug, then we should change the unreachable_glyphs check so it doesn't complain.

@bobh0303
Copy link

According to fonttools/fontbakery#938 (comment) and MicrosoftDocs/typography-issues#346 (comment) there is some relatively recent software that expects glyph 1 to be empty (and presumably width-less), though the most recent such are only in COLR fonts.

Thus I change my opinion:

  • We should not be recommending anything between .notdef and space except in COLR fonts in which case NULL/.null is recommended.
  • The NULL/.null glyph, if present, should be empty and width-less.
  • Neither of these glyphs should be encoded, and the resulting OS2.firstCharIndex should be 0x0020.
  • There should be no other glyphs between these first one or two and U+0020 space, in particular no CR/nonmarkingreturn, tab, etc.

I intentionally did not say that NULL/.null may not be in non-COLR fonts — but others may want to challenge that idea.

@yanone
Copy link
Collaborator

yanone commented Jul 23, 2024

Since you're discussing Fontbakery checks, I think it's a good idea to move the conversation over there, as it would also have more eyes look over it, and then have the tooling such as glyphsets follow whichever outcome is accepted there. Fontbakery is kind of the central source of truth.

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

No branches or pull requests

5 participants