A call for better metadata

ebuka
ebuka Posts: 13
edited October 25 in Font Technology
Whenever I come across a font I like, one of the first things I do is look for the person or people behind it.

I want to know who designed it, which foundry it came from, and whether there’s a description telling me a little more about it.

I once came across a font with a description that explained its origins and the inspiration behind it. It felt like reading a short story. It gave me a little more context about the typeface and made me appreciate it differently.

That’s why it’s a little disappointing when I come across fonts with missing or incomplete metadata. Sometimes, the designer’s name is nowhere to be found. Other times, fields are filled with information that belongs somewhere else. I’ve seen copyright notices and trademarks placed in the name or description fields, for example.

The OpenType specification defines more than 20 standard name IDs covering everything from copyright notices and designer names to descriptions, licensing information, and URLs. Yet, so many fonts leave some of these fields empty or put information in places where it doesn't belong.


I know metadata probably isn’t the first thing on a designer’s mind when finishing a typeface, but I think it’s worth paying attention to. These details help people discover the people and stories behind the fonts they use.
Tagged:

Comments

  • pavljenko
    pavljenko Posts: 43

    I completely agree. Even in serious professional typefaces, studios sometimes don’t pay much attention to correctly filling in all the fields and don’t give it the necessary focus. I would also add to your call a call to software developers who create and edit typefaces — to place more emphasis on the font metadata fields in the user interface or to somehow encourage users to fill them in

  • Dsche
    Dsche Posts: 39
    Just yesterday, I happened to notice that if you enter a description for a style set in a "Style Set Names" field within FontForge and then delete that styleset, the description doesn't actually disappear; instead, it remains in the file and gets written into the copyright field when the font is generated.
    In other words, at least some of these errors might not be due to a designer’s carelessness, but rather to the limitations of the software we are forced to use.
  • ebuka
    ebuka Posts: 13
    pavljenko said:

    I completely agree. Even in serious professional typefaces, studios sometimes don’t pay much attention to correctly filling in all the fields and don’t give it the necessary focus. I would also add to your call a call to software developers who create and edit typefaces — to place more emphasis on the font metadata fields in the user interface or to somehow encourage users to fill them in

    Ah, you mean the developers of type design software. That’s a good point. Making these fields more visible and easier to understand in the software could encourage everyone to fill them in properly.

  • ebuka
    ebuka Posts: 13
    Dsche said:
    Just yesterday, I happened to notice that if you enter a description for a style set in a "Style Set Names" field within FontForge and then delete that styleset, the description doesn't actually disappear; instead, it remains in the file and gets written into the copyright field when the font is generated.
    In other words, at least some of these errors might not be due to a designer’s carelessness, but rather to the limitations of the software we are forced to use.

    I hadn’t considered that some of these mislabels could be caused by the software itself rather than the designer. It reinforces the point above about the need for software developers to prioritise font metadata and make sure these fields are handled properly, or for plugins that can run checks.

  • John Hudson
    John Hudson Posts: 3,892
    In 2016, we added the STAT table to OpenType to enable a more flexible approach to font naming in the kind of complex design relationships made more common in variable fonts. This moved away from the static naming fields of the name table, and enabled fonts and variable instances to be identified by attributes.
    Perhaps we need to something similar for font credits and other meta data? Perhaps a CRDT table?
    The name table has fields for font manufacturer, vendor, and corresponding URLs, copyright, and trademark, and a general ‘description’ field for everything else. It isn’t ideal for capturing the complex kinds of collaboration that are often involved in designing, making, and publishing a font.
  • Andreas Stötzner
    Andreas Stötzner Posts: 846
    John Hudson said:
    In 2016, we added the STAT table […]
    Perhaps we need to [have] something similar […] Perhaps a CRDT table?
    […]
    John, who actually knows about the existence (?) of a STAT table? And: where is it?
    Who will actually get it right when yet another table gets added?
    There are rumors going that even more such ‘sinister tables’ exist, such as the Math table, but I dare to say that only 3 or 5 people on earth know about to deal with it. That is the problem. When I’m at work in my font editor, where is the button “Edit table X”, “Edit table Y”? 
    The complexity with all the different (or not so different) name entries alone is a huge mess. The vertical metrics ‘philosophy’ is crazy annoying. All this stuff is far too goofy and complicated, because the people programming it in the first place seem to love goofish complications which no one can understand. Then everyone else from the fontist to the user is the hooked one.
    There are too many secrets involved and therefore people get things wrong or incomplete.
    My plea:
    • Text applications with a hunger for much and more metadata should be set on diet 
    • Metadata as a whole need a severe clean-out
    • Metadata should get a more slim and neat, standardized structure
    • Mandatory entries ought to get more clearly differentiated from optional stuff
    • Font applications should provide a much more easy and obvious way to see, check and handle all metadata options which exist, and provide a better guidance how to understand and to define them.
    (writing this I have mainly the ‘Info’ box menu of FL in mind; I assume the situation is similar with other editors)
  • ebuka
    ebuka Posts: 13

    I guess this comes down to responsibility. Whether you design, engineer, subset, or extend a font, you should make sure the necessary metadata fields are filled in correctly before making it public.

  • Thomas Phinney
    Thomas Phinney Posts: 3,229
    I wish it were as simple as “people being responsible.” This is made more complicated by the facts that:
    • some of the metadata settings are quite complicated
    • in numerous cases the general consensus has itself evolved over time (e.g. nameID 1 & 2 on Mac, the unholy nightmare of vertical metrics)
    • even data fields themselves have been added over time, even after the invention of OpenType (e.g. WWS name table entry, STAT table…)
    Many of the folks on this forum (indeed, many in this thread, even!) have been deeply, personally active in trying to evangelize best practices in these very areas, or making/maintaining tools to help, or both.
  • Kent Lew
    Kent Lew Posts: 1,073
    @ebuka The original point is well taken. But as others have mentioned, in our defense, it can be more complicated than it seems at first glance. Also, I have to say, getting all the *technical* requirements is hard enough; filling every single metadata field often feels like so much. That’s not an excuse, just a human explanation.
    Also, personally, I find the description field an inadequate place to try to tell the complicated story of a typeface. Especially as that story is evolving over versions. A short tagline is perhaps in order (guilty of leaving it empty ✋), but I hope you’ll visit the designer’s or manufacturer’s site for any interesting history. 
    I consider Designer, Designer URL, Manufacturer, and Manufacturer URL as good baselines (along with Copyright and Trademark). Ideally following those will get you to the real story.
  • Dsche
    Dsche Posts: 39
    Kent Lew said:
    but I hope you’ll visit the designer’s or manufacturer’s site for any interesting history. 

    People die. Companies cease to exist. All it takes is failing to pay for hosting, and every trace of their websites vanishes.
    Am I exaggerating? In my collection, I have fonts that I downloaded from a type foundry’s official website—a site that once likely featured project descriptions and the rationale behind the design decisions, but now, nothing remains.

    Admittedly, as far as I know, no one currently includes such information directly within the font file itself—perhaps it’s time we started doing so.
  • SCarewe
    SCarewe Posts: 135
    This would blow font files out of proportion. File size is crucial. When you purchase a font, get the PDF specimen as well, which is almost always freely available right on the font's page.
  • Dsche
    Dsche Posts: 39
    Well, I just tested this by adding four paragraphs of explanatory text (a copy of what I have on my website) to the *Name ID 10 — Description* field; the size of the otf file increased from 44,340 bytes to 47,764 bytes.
    I used to include a separate description file in the archive alongside the font file, but experience shows that fonts tend to take on a life of their own quite quickly—so embedding the description directly into the file itself is a more reliable approach.
  • SCarewe
    SCarewe Posts: 135
    That's a 7% file size increase, for the text alone. Not saying whether that that's too much or not, but one should just be aware of this. Take this stuff out before webfont compression, at least.
  • ebuka
    ebuka Posts: 13
    edited October 27
    SCarewe said:
    This would blow font files out of proportion. File size is crucial. When you purchase a font, get the PDF specimen as well, which is almost always freely available right on the font's page.

    My point is more about when you come across a font in the wild, whether it’s a commercial font or one released under an open licence. You may not have access to its specimen or the original page, so the metadata embedded in the font itself can be the only way to learn about its designer, origins, and other details.

    As @Dsche mentioned, people, companies, and websites can disappear over time. The font file itself should be one of the most reliable places to preserve concise information that might otherwise be lost.

    A few extra bytes for meaningful metadata seem like a worthwhile trade-off to me, especially when that information could help someone identify or learn about a font years down the line.

    For example, the description in this screenshot gives some context about the typeface beyond its name and technical details.


  • Kent Lew
    Kent Lew Posts: 1,073
    @Dscheand @ebuka You both make fair points regarding longevity and fonts in isolation. As a maker, I appreciate the perspective. Thank you.
  • ebuka
    ebuka Posts: 13
    @Kent Lew Thank you for being open to the discussion.
  • Roel Nieskens
    Roel Nieskens Posts: 222
    SCarewe said:
    That's a 7% file size increase, for the text alone. Not saying whether that that's too much or not, but one should just be aware of this. Take this stuff out before webfont compression, at least.
    I wonder how much of that increase is left after compressing to WOFF2.

    Including or excluding this data from webfonts is always a two-sides-of-the-coin thing for me. On one hand, this name table data is never made available to anything in the world of browsers, so what's the point of adding it. Nobody will see the description. Some dev tools will show a font's name (ID 4), and variable instances or axes names, but that's it.

    On the other hand, webfonts are easily downloaded from any random site, converted back to .ttf or .otf and sent off to lead a new life of its own.
  • SCarewe
    SCarewe Posts: 135
    On the other hand, webfonts are easily downloaded from any random site, converted back to .ttf or .otf and sent off to lead a new life of its own.

    That's actually a good argument for keeping this complementary process documentation and info in the licensed uncompressed fonts  :)

  • Thomas Phinney
    Thomas Phinney Posts: 3,229
    I like the idea of having a bit of info there… in theory.
    It does of course bring up the question of “in what language(s)?”
    More than one is probably a bad idea, for space/size reasons.

    Also, note that for almost anything that doesn’t initially seem like a high cost in file size… what about when the font is subsetted for a single heading or the like? (sigh)
  • Dsche
    Dsche Posts: 39
    edited October 30
    It seems to me that any language used in a description—provided it doesn’t contain overly complex puns—can be translated into another language in just a couple of clicks, even if the result loses some of its original polish.
    The problem, as I’ve observed in my own system, is that the only field suitable for this is the copyright field. I don’t see any way to access the "description" field without specialized software; Google Drive doesn’t display it, and while Windows shows the beginning of the text in the file properties, it doesn’t allow you to copy it—not even via PowerShell.

    Update: It seems to me that the right approach would be this: if the community starts making more active and meaningful use of the "description" field, then industry giants like Google and Microsoft—and who knows who else might be on the scene decades from now—will sooner or later follow suit by updating their software. In the meantime, it might be worth including an extremely concise summary within the "copyright" field—something like of "inspired by [X], incorporating ideas from [Y]."
  • Thomas Phinney
    Thomas Phinney Posts: 3,229
    Personally, I would not overload the copyright field. This is the kind of hackery that is really hard to recover from.

    The description field is the right thing and already exists as a distinct entity; if font makers use it, other players will eventually make it visible.

    Yes, this sort of thing takes many years. It is a long game.
  • Ray Larabie
    Ray Larabie Posts: 1,506
    Maybe go external? I've been using Wikidata to provide extended, multilingual info on my fonts.
  • Dsche
    Dsche Posts: 39
    More than thirty years ago, when I first launched FontMonger on my work computer, the Internet was something of a curiosity—accessible only to a select few within certain academic circles (in contrast to the TrueType format, which was already widely used at the time). I might be exaggerating slightly, but today, the idea of ​​“storing a font’s description separately from the font itself—somewhere on the Internet”—seems entirely natural and sensible. It is much like how, thirty years ago, I would have accepted without hesitation the suggestion to “write this information on the envelope of the five-inch floppy disk that contains the font.”
  • Thomas Phinney
    Thomas Phinney Posts: 3,229
    Internal and external info can be complementary rather than mutually exclusive.

    Brief info in an internal field is a Good Thing.

    More/longer external info as suggested by @Ray Larabie could also be nice.

Categories