Private use of name table entry

yanone

I'm "signing" my fonts by placing encrypted information in name table ID 32137 (chosen for no particular reason).
The spec says:

Name IDs 256 to 32767, inclusive, are reserved for font-specific names such as those referenced by a font's layout features.

and not:

Name IDs 256 to 32767, inclusive, are reserved for arbitrary stuff.

What do you say? Is it okay to put my stuff there or is there maybe a better place?

John Hudson

I think what you're doing is pretty safe. As the spec says, names in that ID range are font specific, so are not at risk of being misinterpreted or in conflict with other fonts or software functionality. Where the spec refers to 'a font's layout features', this means things like name strings for stylistic set or character variant OTL features, which rely on a mechanism in those feature lookups that points to the name IDs in the name table. Because this is always font specific, i.e. not standardised across fonts, I can't think of any reason why you shouldn't use IDs in this range as you describe.

Hrant Հրանդ Փափազեան Papazian

Just please don't emulate Apple...

https://twitter.com/jeremyburge/status/868017009677787136

John Hudson

Entirely different topic, Hrant. Yanone is asking about private name table IDs, not private use area encodings.

[Also, that article isn't about Apple, as far as I can gather, but about a third party app. And the app seems to require that the recipient device also have the special app and font installed. So it's essentially a private, closed environment, and the use of PUA is legit. But its still pretty daft because sending PUA text isn't any improvement over sending sticker graphics in terms of interoperability.]

Hrant Հրանդ Փափազեան Papazian

I stand corrected, on both counts (although Apple should not approve such an app for distribution).

KP Mawhood

Are naming IDs 1–25 sufficient for display / usage in most typesetting purposes – e.g., which might possibly be flagged by us or our typesetters in an automated process? With a plan to list 0–6, 14, 16–18, 20–22, 25. Our current list is insufficient (0–6, 14) + format (detailed).

There's a few listed for human factors, e.g. 0 and 14. ID 13 gets quite lengthy sometimes, so we don't list it.

John Hudson

Katy,

Are naming IDs 1–25 sufficient for display / usage in most typesetting purposes ...?

Yes and no. The name IDs tend to follow technology, so when new technologies come along, new name IDs have been defined to handle them. But that, thankfully, seems to have stopped with variable fonts. Which means that reliance on name IDs will be tautologically sufficient for the usages for which name IDs were defined, but may not be moving forward.

By way of background:

When the Sitka fonts were being built, Microsoft decided to come up with a new way of defining intended size ranges for optical size fonts (i.e. discrete optical size fonts, not variable fonts with an optical size axis). This was in recognition that the OpenType Layout 'size' feature, which hacked the data structure of a GPOS lookup to store information about size ranges, has proved to be a non-starter in software support. The new model we — Microsoft and Tiro; we were building the Sitka fonts and took part in the discussions around possible models for implementing optical size — came up with was to new fields in the OS/2 table, recording minimum and maximum intended sizes, expressed as twips (1/20th of a point), for the font.

At the time, I pointed out that we would have to provide careful specification of with what name table IDs the size information should be used, and I wasn't sure which would be appropriate. As it turned out there is no existing name ID that can be used for this purpose beyond a simple style family such as Sitka, because there is no name ID that presents a unique string capturing every attribute of a font except size. Which means there is no way to parse name table entries to get at the relationship between fonts that differ only in target size range as expressed in the new OS/2 fields. Unfortunately, by the time this was realised, the new OS/2 version spec had already been published, so we had two new data points available to font makers that couldn't be used.

That's the point at which the inevitable question arose 'Should we define a new name table ID for this purpose?' That is, after all, the historical response to any new technology that requires differentiating and capturing the relationship between fonts on a new basis. I argued against this, on the basis that the name table already confused many font developers, and also limited interoperability between fonts by relying on concatenated strings of font and style names, without any standardisation of the order within these strings. So, for example, one font maker calls a font 'X fu bar' and another calls the same style of font 'Y bar fu'. You can see in InDesign how this prevents easy switching of styled text between different font families.

So I wrote a proposal to Microsoft that we should create a new table that, instead of using strings for names, identified style attributes as attributes, i.e. with separate fields for each identifiable aspect of a font design, including both standard, registered fields for common attributes (weight, width, roman/italic), and fields for custom attributes. My thinking was that this would need only a single, family name to be defined by the font maker, and the rest of the existing name table IDs could be automatically filled from the new attributes table. Further, software could use the new attribute table data directly, rather than relying on the legacy name IDs, and could present fonts in menus in standard orders, or even ordered by user preference (e.g. a user might decide that ordering by width first and then weight is preferable, or vice versa). Software could also provide better interoperability between fonts in different families based on attributes, rather than relying on font makers using e.g. identical subfamily name ID strings.

The response from Microsoft was that this was a really interesting idea, but would require a big update in both fonts and software, and this wasn't likely to get support just to address optical size selection. So the idea languished for some time until variable fonts came along.

In one of the first variable font working group meetings I attended, I asked about the name table issues around named instances in variations design space, and wondered if the time had come to look again at the attributes table idea. It turned out that, independent of my proposal, Rob McKaughan in Microsoft's Advanced Reading Technologies group had had the same idea, and had begun drafting a specification for such a table. This became the basis of what is now included in the OpenType 1.8x specification: the STAT (style attributes) table.

The STAT table is unique among the new OT variations tables in that it is not only required for variable fonts, but also recommended for new non-variable fonts. So moving forward, Katy, — and sorry it took so long to get to the conclusion — I think automated processes will need to look first for a STAT table, and only secondarily at the name table, and that the name table spec is less likely to be updated with new IDs than in the past, meaning that it can't be relied on to be sufficient for future usages.

Rob McKaughan

To @yanone's question: you might also consider the meta table. Seems a more appropriate for your purpose as the name table theoretically is for stuff that shows up in a UI. Be sure to use a capitalized tag. https://www.microsoft.com/typography/otspec/meta.htm

To @John Hudson's summary: @Peter Constable was instrumental and authored the STAT table proposal based on the concepts, more than the specific implementation, of my proposal. 

In the next release of Windows, Sitka will have STAT tables in each of its static fonts. 

John Hudson

Rob, is the idea for the STAT table to be used in coordination with the two OS/2 size fields? Will the spec for the latter be updated in this regard?

Peter Constable

@John Hudson : Interestingly, I don't think I ever saw your proposal. I wasn't working in the text/font space at the time, though.

For a bit more history...

In the spring of 2014, we had finished Windows 8.1 and were starting Windows 10 planning, and I had just joined the Windows Graphics team to work on DirectWrite. Greg & Rob's team, working with you, had recently completed the Sitka fonts and added them into Windows. Their desire for Sitka all along was to have automatic selection of optical size variants. So, Rob came to me to ask if we'd consider supporting that in DirectWrite.

My immediate reaction was, I really like the idea, but:

- DirectWrite (like WPF and XAML) assumes a weight/width/slope family model. In that family model, different optical size variants entail different families.
- If there is automatic optical-size switching, then a family must encompass different optical sizes -- i.e., an app selects "Sitka", not "Sitka Text" or "Sitka Display", etc.
- Therefore, this ask entails that DirectWrite needs to support a family model that includes optical size as well as weight/width/slope.
- I don't want to support a WWSO family with one more name pair; if we support this, then we need a way to support an open-ended, extensible family model.

It didn't take much for me to convince Rob we should solve that general family problem if we want to support auto-optical-size selection. So, their team and ours, along with Sergey Malkin, had a few meetings in which we grappled with the problem. We considered an extension of the algorithm in WPF/DWrite that parses name strings looking for recognizable tokens, and concluded we really didn't want to parse, but instead wanted some way to have recognized name tokens that we can compose together in different ways. We ended that set of meetings with Rob taking an action item to flesh out that model, thinking through different scenarios, including font families getting extended over time, older browsers working with newer fonts or pages, etc.

Then it was time to start Windows 10 coding, and all this went onto a back burner.

Move forward to late 2015. We had released Windows 10 and the subsequent November update, and were evaluating what our next big investments for DirectWrite should be. It was then we decided to extend OpenType with variable fonts. As you know, we established the partnership with Adobe, Apple and Google early in 2016, and had our first face-to-face meeting in March. Over the next few months, in a series of meetings, we worked through a series of technical design decisions needed for the format. By summer, we had made most of the design decisions.

In the two years since the spring 2014, we had never gotten back to auto-optical-size selection or how to support extensible family models in DWrite. But as we were closing on many of the font-format decisions, I had a chance to start thinking ahead to DWrite implementation. I think it was probably sometime in June that it dawned on me: We're going to _have_ to support extensible family models in DWrite.

I don't recall exact timing -- it may have been in the previous partner meeting or the following one, that someone from Adobe (I think, Sairus) brought up a "DIAL" table proposal that Eric Muller had written several years earlier. I think the context was a discussion about user interfaces. At any rate, I asked Sairus if he could make Eric's document available, which he did.

So, with this somewhat late realization we needed to have data we could use to compose (not parse) font names for different family models, I drafted the STAT proposal. I had my two-year-old recollection of our internal meetings and some of Rob's follow-up work, and had recently read Eric's document: these were my main influences in drafting a proposal for the table. It was distributed for discussion at our next meeting (must have been in July). It got pulled together pretty quickly -- under two weeks, IIRC. I didn't accommodate all of the capabilities Eric's "DIAL" table proposal had, but allowed for the possibility of future extension to include them.

It was during the discussion at that next meeting that the format 3 axis value table was added (to allow for explicit style-linking information -- I think it may have been Read's idea), and we also decided to have a registered 'ital' (italic) axis, so that all relevant attributes of a font can be captured in a uniform manner.


OK, that's the (long) additional history on STAT. As for your question regarding the OS/2 size fields: it was at that same partner meeting when STAT was discussed that we agreed that STAT would supersede both the OS/2 fields and the 'size' feature tag. So, in OpenType 1.8, the following was added to the descriptions of the OS/2 size fields:

"Note: Use of this field has been superseded by the 'STAT' table. See Recommendations Section for more information."

Similarly, the following was added to the description of the 'size' feature:

"Note: Use of this feature has been superseded by the 'STAT' table. See “Families with Optical Size Variants” in the Recommendations section for more information."

And, at the end of the Recommendations page, a section "Families with Optical Size Variants" was added:

"In families that have fonts for different optical sizes or in variable fonts that support the optical size ('opsz') design axis, a 'STAT' table with format 2 axis value tables should be used to indicate text size ranges for which the different optical-size variants or variable-font named instances are recommended. This supersedes the use of the usLowerOpticalPointSize and usUpperOpticalPointSize fields in the 'OS/2' table, and the OpenType Layout 'size' feature."

John Hudson

Peter,

Interestingly, I don't think I ever saw your proposal.

It was in an email to you. 

This is what I wrote on the subject, early Spring 2014:

The old Windows 4-style families have come in for a lot of criticism
over the years, mostly in contrast to Apple's suitcase model in which
arbitrary family relationships were possible, and mostly ignoring the
kind of problems that the latter could and did cause. I actually think
there's a good case to be made for a kind of limited, constrained and
solid subfamily structure in the background behind the variety of ways
we now have to present fonts to users, and for a long time the 4-style
family has provided that for most fonts.

Trouble is -- apart from the unwieldy name length -- once one has a
family whose ID 1 name is

    Blotto UltraLight SemiCondensed Subhead

there's no way to determine which of the style attributes in the name
takes priority in selection. And the same design might just as
reasonably have been called

    Blotto UltraLight Subhead SemiCondensed
    Blotto SemiCondensed UltraLight Subhead
    Blotto SemiCondensed Subhead UltraLight
    Blotto Subhead UltraLight SemiCondensed
or    Blotto Subhead SemiCondensed UltraLight

IDs 16/17 provide the font maker with a way to express one preference
suggesting a kind of organisational priority, but really only affecting
how the fonts are presented in some menus, and typically reflecting the
same arbitrary order as in ID 1, e.g.

    Blotto
    UltraLight SemiCondensed Subhead

Meanwhile, the font maker's colleagues are busy creating families with
similar constituent designs, but using different arbitrary ordering of
style attribute descriptions in existing name IDs.


I think this idea of style attributes is a useful one, and it suggests
to me a possible way forward. What if, instead of looking at linking in
terms of subfamily naming, we look at it in terms of individual style
attributes. So rather than having a subfamily name field that
concatenates these various attributes in arbitrary ways, or setting
constraints on such names that require particular order or other
convention to be used, why not define attribute fields? This would allow
fonts in a family (the family name either ID 16 or ID 1) to be linked in
a variety of ways, based on common attribute field entries. Some
attribute fields could be specified based on common data types (weight,
width, slope, size), while provision could also be made for custom
attributes.

A nice possibility that arises from this is dynamic font menu ordering
and presentation based on user sort criteria, e.g. show me the members
of this family based first on size and then by weight.

So in the case of our example, we'd have something like this:

    Family ID = Blotto
    Size Attribute ID = Subhead
    Width Attribute ID = SemiCondensed
    Weight Attribute ID = UltraLight

To which might be added

    Custom Attribute ID = Plain

to create another kind of subfamily link to differentiate from

    Custom Attribute ID = Fancy


From a selection perspective, it seems to me that the contents of all
but the family ID can be arbitrary text strings, because all that
matters is that the fonts share the same entries if they share the same
attributes. This means that complex family relationships can be
expressed quite freely by font makers, while enabling software to
reliably parse these relationships for specific purposes. 

Of course, in the context of variable fonts, this fairly simple idea for static fonts with arbitrary strings as attributes needed to become more complex, to capture variation axis information. When I wrote the above, it looked very unlikely that anything like it would emerge, given the updates that would be necessary in software support, and without the context of a major format update that would drive such support. And then variable fonts came along, and I was thrilled to discover that other people were thinking along the same lines.

Thanks for the reminder of the role of Eric's DIAL table in the drafting of the eventual STAT table. I'd mostly discussed this sort of idea with Rob at various times, so had his draft table in mind.

This is why history is something to do, not just something to live through: different people remember and assign importance to different aspects of what is happening.

Peter Constable

@John Hudson Thanks for that reminder. I recall now Rob mentioning you had brought this up, though I'm not sure I ever got around to reading that email. (I may have been relying on Rob to inform me of what mattered.)

Great to have made history together, and now to _do_ history -- as opposed to making up history. ;-)