Update font metadata #11
Comments
|
Font formats seem to be an arcane world, somehow coming straight from the 80s... OS/2 in 2020, and it's apparently still important? |
|
Looking for a straightforward, concise description of the many different "name" keys and how they all work together to e.g., get font families recognized correctly. I am assuming there must be some best practices for this. Say we have "Leutkirch Sans Light". Where do we need to put it as "Leutkirch", where as "Leutkirch Sans", where as "LeutkirchSans", where to put the Light (and where not), when to use a "-" as part of the name, etc. Another point of confusion is whether to include the terms "Roman" (=non-italic, non-oblique) and "Regular" (=non-bold, non-light) in which names. With Bold, it gets even more complex. Where to put the word "Bold", is it part of the title (name) or is it a property of the font (like what is known today as a "tag")? What about "Semi Bold" (or is it "SemiBold"?) then? (Most text processing applications have buttons for italic, bold, bold italic but not for e.g. light, semi bold, etc. - is this a leftover from the early 80s? What good is it for? Why hasn't it been eliminated a long time ago? Does clicking the "bold" button do the same thing as selecting the font which has "Bold" as part of its name? Is this consistent for all fonts or is the answer still "it depends"?) In which cases does "Demi" have to be used instead of "Semibold"? Is there an authoritative lookup table of such equivalent names? Then there is abbreviations. In some places you will find "Bold Italic", in some places "BoldItalic", and in some places "BolIta". What goes where and how do we know? Is "Light" supposed to be abbreviated as "Lt" or "Lig"? Is Italic supposed to be "It" or "Ita"? Why does e.g., Adobe use "SourceSerifPro-SemiboldIt.otf" where one is a very long unabbreviated word and the other is abbreviated? Then there is capitalization. Is it "SemiBold" or "Semibold"? "Extralight" or "ExtraLight"? Then there is numbers that are supposed to describe weight. The Frutiger numbering system ("55", "65",...), the Linotype numbering system - these are apparently part of the font name rather than metadata. And there is metadata for the same thing, usually three-digit ints (400, 600,..) - these are apparently not part of the font name but metadata. Also, sometimes the font foundry name seems to sneak into font names, but also in an apparently inconsistent way. There is "Univers LT 55 Oblique" and "Univers 56 Oblique" (with and without "LT" which probably is meant to stand for "Linotype"). Is there a clear definite description, ideally one that covers both otf and ttf as it is used (and as is best practice) today (as opposed to the days when OS/2 was still a thing)? FontLab seem to have invented their own terminology (PSN | TFN | TSN | SGN | SLN) which makes things even more complex since their terminology is not part of neither what UFO3 nor Adobe are using. The whole situation seems to be such a huge mess (legacy, or "technical debt", piled up over decades) that one needs long-winded threads that are started out of noble intentions but are so confusing that you don't even want to start reading them. To make this pragmatic, what exactly do we need to put into all the values that have "name" as part of their keys? |
|
Saying "best practice" probably means looking at how Adobe is doing things. Unfortunately, they seem not to be working from UFO3 (which appears to be the emerging standard for open source based workflows) but their own set of tools. Especially relevant seems to be Seemingly that file only covers a fraction of the whole naming complexity, with other parts of the metadata coming in from other files with no immediately visible relationship between them. How does this translate to the fields in UFO3? |
|
Right now we have: Which seems to be different from what most fonts are using. Hence the quest to find out what to put into which UFO3 fields according to "industry best practice". |
|
Here is what Adobe is using, based on
This is what FontForge converts this to when exported as UFO3: Can we assume this to be "industry best practice"? |
|
To be pragmatic, here is a table with what I could figure out so far (please double-check!) and what I am struggling with. Maybe this is useful for other font projects wondering the same things, too.
Question 1Which one is industry best practice and why?
Question 2
Note that in the case of Source Serif Pro Semibold Italic, Question 3Which one is industry best practice and why?
Question 4Which is industry best practice and why?
Question 5What to put here? Source Serif Pro Semibold Italic has just Question 6Should Question 7Should Question 8Should Question 9Should Question 10Should Question 11Should Question 12Apparently |
|
Let me try to answer your questions: First of all, you are using UFO conventions, so please see http://unifiedfontobject.org/versions/ufo3/fontinfo.plist/ , e.g. section "Name Record Format" and then https://docs.microsoft.com/en-us/typography/opentype/spec/name#name-ids to match the IDs there to see what the spec actually says about each. Q1(OT Name ID 17) It is wrong to think of there as being an "industry best practice" for this. Medium and Regular are typographically different, a font can have both a Regular weight and a Medium weight, or both a Book and Regular. I'd go with Regular, but there's no wrong answer here. Q2(OT Name ID 17) "Extra Bold" is best. There is no need to abbreviate anything. When you see abbreviations or lack of spaces, you are almost always seeing some intermediary program just getting them from the PostScript font name, which had limitations. These limitations are usually still respected, as ancient programs choke on them, but actually the format has evolved to the point where they ought to be relaxed from errors to warnings as many foundries, especially CJK ones, ignore them. See fontforge/fontforge#3941. Q3(OT Name ID 1) Name IDs 1 and 2 are used to inform more basic programs, especially word processors, et cetera, of which of the four "regular", "bold", "italic", or "bold italic" your font corresponds to. See e.g. https://robofont.com/documentation/how-tos/setting-font-names/#2-style-linked-sub-families for a good example: So, the correct answer is, it depends on how many styles there are. If you have only two, a bold and a regular, correct answer is Q4(OT Name ID 1)
Q5(OT Name ID 2) Yes. It should be, for maximum compatibility, always one of Q6(OT Name ID 5) Yes and no. You should provide a version for your fonts, but tools often populate extra information. String must always begin with e.g. Q7(OT Name ID 3) The story of this Auto-population is therefore fine, but these fields shouldn't be relied on to be unique. See Q10 for what should be relied on instead. Q8(OT Name ID 16) Yes, although UFO specification is agnostic. Q9(OT Name ID 17) Abbreviation certainly has same cause as Q2. They shouldn't ever need to be different, just Adobe's tools sometimes favor the PostScript name as it's not out-of-spec to do so. Q10(OT Name ID 6) No, not always, but most of the time. To-spec PostScript font names cannot contain Unicode, but many CJK fonts have Unicode names. So, they often have an OT 16 like PostScript font names should always be unique, in many modern systems, the PS font name serves the purpose the defunct XUID/UID used to serve. Apple cautions:
Fontconfig, AFAIK, does the same. Q11(CFF /FullName) No, it should be the same as Q12(CFF /Weight) The reason it might be different is that it's in sync with OS/2 So, the UFO3 spec is saying to put a string "in sync" with an integer, which is a bit absurd and probably a spec bug. Since this field is so old, it can literally contain anything. I'd match it up to the strings FontForge uses, and assume most programs will prefer OT ID 17 over it. |
|
Thanks a ton @ctrlcctrlv - this is really helpful. So this is what I will go with. Turns out to be way more orderly than what I had anticipated.
Again, thanks for your help. Anyone, please comment in this ticket if you think I did not follow best practices anywhere. |
Best practice means reading the OpenType spec and applying strictly all its recommendations. Anyway, here is a short summary. It all starts by defining clean target font family and font style values.
GOOD:
BAD:
LESS BAD (but probably breaks somewhere):
Microsoft listed quite a lot of those in their key WPF whitepaper, that served as base for later OpenType spec evolutions All the design of name ID 21 & 22 and later of CSS4 font attributes and the default variable OpenType axes can be traced to the analysis detailed in this document.
Width Weight Slant correspond to the default OpenType variable axes. Any other kind of style variation won’t map correctly to variable font naming. https://docs.microsoft.com/en-us/typography/opentype/spec/dvaraxisreg If you feel adventurous, you can play with optical sizing (the 4th default variable axis). But, it is so new and badly defined even OpenType spec authors admit they only included it in the hope some clear conventions would emerge.
GOOD:
BAD:
See also
GOOD:
BAD:
https://www.w3.org/TR/css-fonts-4/#font-stretch-prop GOOD:
BAD:
(Arial Narrow antedates modern Width conventions & specifications.)
Contrary to what @ctrlcctrlv wrote using spaces in style keywords badly breaks software that attempts to read and understand your style values. The Microsoft WPF whitepaper details the level of complexity induced by non regular style naming. It’s a fascinating (if sick) read, if you are interested in this kind of thing. Once you have a clean target family/style pair you can put them in Name ID 16 & 17 and derive all the other Name IDs from those following the rules set down in For example:
And so on. The OpenType spec is pretty thorough on how each naming layer is constructed, as long as you remember that in OpenType speak “it would be nice to” means “you should really really do this unless you want to break apps”, and the spec was amended for a long time (for example Name ID 4 rules forget to state relationship to Name ID 21 & 22, because those were added later. You need to remember that the part of the spec that states 21 & 22 are the same thing than 16 & 17, means that every time you saw 16 & 17 in the rest of the spec, that means 16 & 17 or 21 & 22 if defined). |
|
Also, for a long time you could put whatever garbage you wanted as width or weight numeric values, apps mostly ignored those. That changes with the introduction of OpenType variable axes. The values are actually used to coordinate the various styles, and take precedence over the style namings (because, variable fonts permit more width weight slant values than previous OpenType formats, so it was not possible anymore to restrict processing to standard style keywords). That‘s why CSS4 dropped the rounding of standard keywords to specific values (as was done before). To quote the specification of the OpenType variable weight axis:
Variable numeric axis values can also be set in non variable OpenType font (in the usual euphemistic way the spec is written, that means you bloody well should set those if you can, even in non variable fonts). And that continues with
Translation: and you should bloody well make sure the values set in OS/2 tables are consistent with the values you set or someone else will eventually set in STAT, before things break. https://docs.microsoft.com/en-us/typography/opentype/spec/dvaraxistag_wdth Other variable axes definitions contain similar wording in the spec. |
|
The WPF whitepaper is not the standard. OT 17 shouldn't be "read and understood"...just sorted according to OS/2 value. |
|
Thank you very much for your detailed answers everyone - turns out what I hoped were questions with straightforward answers is really a complex can of worms. Maybe it would really be worth a chapter in the "Design with FontForge" book, fontforge/designwithfontforge.com#202. |
Of course it is not the standard. It’s a research paper written by the Microsoft fonts team. However Microsoft are co-editors of the Opentype spec, and they apply everything they learn in research to the spec. A lot of later (now current) OpenType spec changes can not be understood without reading this whitepaper. 80% of what’s in OpenType variable axes today is the clear continuation of WWS (making WWS continuous axes, not discrete values) and the WPF whitepaper explains WWS objectives much better than the short paragraphs that ended up in the spec. The remaining default variable axis, optical sizing, can not be traced to the WPF whitepaper, and (surprise!), it’s a thorough mess right now.
Except apps do need to read style:
I’m pretty sure that one key reason Microsoft invested in variable fonts in the OpenType spec, is that variable fonts can not work without clean metadata in font files, so even if variable fonts remain marginal app side (as is the case today), they are forcing font makers to clean up their act both regarding numeric metadata values, and string naming metadata values. Without the first, you can not select an arbitrary point on the variable axis. Without the second, transition from traditional non variable font names to variable instance names breaks. Microsoft is historically an app company. Their contributions to the OpenType spec always aim first and foremost to make fonts files useful to the apps that are the company moneymaker. The other OpenType key editor, Adobe, has a thriving font business, and will care a lot less about the app side. They are as ready to earn money with app-unfriendly font files as the next font maker. They will accept to do very strange things in their own apps (things that the average app author will never do) to avoid fixing the font files they already sold in the past. |
|
You're right about one thing, OT name IDs 21 & 22 are stricter. And it is genuinely useful to have them. That doesn't mean you're right about the conventions around OT ID 17. |
|
By the way, Microsoft's own documentation reads, for ID 22:
I understand your frustrations with the format. How could I not, I contribute to FontForge. But you're simply wrong that it's invalid to have spaces there... |
|
@ctrlcctrlv I'm not stating that Name ID 17 (or Name ID 22) can not have spaces, I am stating that the Width Weight Slant keywords in Name ID 17 (or Name ID 22) should not have spaces. The keywords are themselves space-separated. None of the spec canonical “good” examples use keywords with spaces. Be it in the text you quoted, in https://docs.microsoft.com/fr-ca/typography/opentype/spec/namesmp, or elsewhere. Name ID 17 was initially very weakly specified, because its initial objective was to lift the limitations of Name ID 2. So, it started with “Name ID 2, without constrains”. The spec authors could not imagine at that time how font makers would take advantage of the “without constrains” bit to invent app-breaking ID 17 strings (remember, pre ID 17 world was RBBI, no room for garbage here). When Microsoft actually tried to use ID 17 in its apps, and audited the vast pool of font files out there, they had a “what were they thinking” moment. And then they proceeded to add ID 21 22 to the spec, and published the WPF whitepaper to detail with actual parser algorithms why free-for-all ID 17 did not work for apps in practice, and needed fixing (either directly in ID 17 or indirectly via ID 22). I also strongly suspect that Adobe was among the pro-eminents font makers that had produced app-breaking font files, and ID 22 was invented to avoid embarrassing Adobe. Otherwise Adobe customers could have complained Adobe had sold them non-compliant OpenType files. That’s why the spec is very elliptic on WWS and name ID 17 & 22, and the WPF whitepaper serves as main documentation here. That is also probably one reason Microsoft Office is still stuck in RBBI land. Franckly, I don’t understand why you’re insisting here that Name ID 17s that contain spaces in their Width Weight Slant keywords are “right”:
I know that many people font maker side took it bad when Microsoft stated they were doing it wrong and amended the OpenType spec to add WWS restrictions, but let’s stop being childish here, @probonopd asked for best practices, not loopholes that can be used to justify producing broken font files. The specified best practice in the OpenType spec is WWS, both in the spec wording, and in the spec examples. And, even if the spec had not written it down, OpenType variable formats use WWS as default axes, so non WWS naming will not transition to OpenType variable. (Again, excepting Optical Sizing, which is not a WWS concept, and is woefully under-specified, be it in the spec or elsewhere). |
|
OTM Light has a Consistency Checker which complains about this font:
These are the different messages that can be produced with the OTF Light Consistency Checker and which should possibly be considered when writing the "industry best practice" guide on font name metadata:
|
|
@nim-nim Actually we have no disagreement. I just misunderstood you. I thought you meant ID 17 should read |
|
To be honest, the output of OTM Light is cryptic to me. What is wrong about the line that it has marked red, and which field in UFO3 does this correspond to? (Maybe I should really ask this question to the OTM Light developers, but possibly someone more knowledgeable than me can make more sense of that dialog box.) |
|
I think it's complaining about OT ID 1, but both RoboFont's devs and I disagree with what they're saying. |
|
Oh and it seems like they list the exceptions right there, but their program isn't considering them. I would take the output with a grain of salt. |
|
Note to self, https://glyphsapp.com/tutorials/naming is a long writeup on naming which we also might to consider if we ever turn this into some generic documentation/checker. |
|
Dr. Jürgen Willrodt in OpenType Status 2009 https://www.youtube.com/watch?v=29jQAZ-H6Wk (around 21:40) gives information on font naming and basically confirms that it is a mess ("there is no hope this will get better")... |
|
It is a mess but it is getting better due to pressure from web and module devs (the W3C did not give up and removed all the excuses built-in the OpenType spec in the CSS spec, so careless font makers see the web/mobile market go to others). |
|
See also By 2009 the general clean up had just started and many believed garbage as usual in metadata would continue forever. |
http://designwithfontforge.com/en-US/Font_Info_&_Metadata.html contains a section on Font Info & Metadata.
Unfortunately this does not explain what to put where. Many fields, little explanation...
It would be worthwhile to have a pragmatic explanation what to put into which field, from today's "industry best practice" perspective. See below for some questions that may come to mind when being confronted with this dialog for the first time.
The text was updated successfully, but these errors were encountered: