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

Question, Ch. 3.2: what about openTypeNameUniqueID? #2

Open
madig opened this issue Jan 2, 2018 · 9 comments
Open

Question, Ch. 3.2: what about openTypeNameUniqueID? #2

madig opened this issue Jan 2, 2018 · 9 comments

Comments

@madig
Copy link

madig commented Jan 2, 2018

I'm restaurating the Ubuntu font family and was wondering about the Unique ID in the name table. Is it necessary and if so, for what? The OpenType spec doesn't say much about it. Should a font set it to something particular?

@jvgaultney
Copy link
Collaborator

I'm not sure - would love to have more info on this too. We do set it in our projects using the pattern (using UFO key names, and replacing currentyear with the current one for the build)

openTypeNameManufacturer: familyName styleName: currentyear

@madig
Copy link
Author

madig commented Sep 24, 2018

Hm. Maybe we can put the SHA256 digest of the font in there? That would make sure it is indeed unique. I suppose at the end of the production pipeline, one could use fonttools to temporarily delete the name table entry, SHA256 the binary and then write that to the name table again.

Or maybe just the git commit ID if present.

@bobh0303
Copy link
Collaborator

Maybe we can put the SHA256 digest of the font in there? That would make sure it is indeed unique. I suppose at the end of the production pipeline, one could use fonttools to temporarily delete the name table entry, SHA256 the binary and then write that to the name table again.

Just don't expect such a SHA256 to match the resulting binary since in the process of rewriting the name table the font-wide checksum in the head table must be recalculated.

@madig
Copy link
Author

madig commented Sep 24, 2018

Hm yeah. Maybe the commit ID makes more sense.

@orvn
Copy link

orvn commented Nov 22, 2019

Not really part of this repo and this is a late response, but I figured I'd chime in.

The desired format for the unique font ID (openTypeNameUniqueID) is semicolon separated version;author;nice-name, no spaces.

An example is 2.108;mlss;ProximaNova-Medium

  • 2.108 is the version,
  • mlss is the notation Mark Simonson Studio, the creator of the typeface uses
  • MyriadPro-Regular; is a dash separated name for this particular font

You can use the same string for all platforms (platEncID).

@bobh0303
Copy link
Collaborator

Hey, thanks for chiming in.

The desired format for the unique font ID (openTypeNameUniqueID) is semicolon separated version;author;nice-name, no spaces.

I'm curious: Where do you find this recommendation and why do you say this is "the desired format"? Is it a specific font vendor's practice?

As far as I can find, the Microsoft and ISO versions of the Standard give no specific recommendations, but only an example:

  1. A unique identifier that applications can store to identify the font being used. Monotype: Times New Roman Bold:1990

and Apple's TrueType Reference manual gives a different example:

Apple Computer Helvetica Semibold

@orvn
Copy link

orvn commented Nov 25, 2019

I'm curious: Where do you find this recommendation and why do you say this is "the desired format"? Is it a specific font vendor's practice?

@bobh0303 Unfortunately I've always found the resources on the web that describe typeface name table syntax lacking.

I wouldn't say it's a specific font vendor's practice, but this is what I usually see from the biggest font studios and it's echoed by Adobe. Actually, since so many typefaces are initially designed with Adobe products, this is how the format became so popular.

I even see it with some (but not all) Microsoft and Google fonts. I do also see colons : being used in place of semicolons ;.

Let's take a look at some popular fonts and what they use as identifiers:

Lucida Console

  • Microsoft font
  • Lucida Console Regular; B&H alpha25

Calson Pro Bold

  • Adobe font
  • 2.092;ADBE;ACaslonPro-Bold;ADOBE

PT Sans Bold Italic

  • ParaTypeLtd:PTSansBoldItalic:2010

Circula Regular

  • JanSchmoeger/Paragraph:Circula:2010

Raleway Medium

  • Independent, but distributed by Google Fonts
  • MattMcInerney,PabloImpallari,RodrigoFuenzalida:RalewayMedium:2012

Montserrat Medium

  • Independent, but distributed by Google Fonts
  • 3.100;ULA ;Montserrat-Medium

@jvgaultney
Copy link
Collaborator

Your examples prove that there is no standard, as Microsoft, Google, and Paratype are significant vendors. I don't see any need to follow Adobe's pattern.

Actually, since so many typefaces are initially designed with Adobe products, this is how the format became so popular.

I don't think that's the case. Most fonts are built with Glyphs, FontLab, Robofont, or Fontforge.

@orvn
Copy link

orvn commented Dec 2, 2019

Your examples prove that there is no standard

There's no explicit standard, just an approximate syntax that most people seem to follow. More of a tradition I see echoed by most typefaces.

I don't think that's the case. Most fonts are built with Glyphs, FontLab, Robofont, or Fontforge.

That's fair, and true. The final font compilation is done using these tools, I use Fontforge myself.

However, at the conceptualization stage, and within the design industry as a whole, it's no secret that Adobe dominates the toolset (for instance, GIMP is an open source alternative to Adobe Photoshop. It's often popular among tech savvy enthusiasts, but is rarely used by professional designers). That's why I think I tend to see Adobe guiding the industry more than other large entities.

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

4 participants