UFO glyph and group names vs. SFNT glyph names and FEA glyph and class names

[Adam Twardoch (List)]

Dear UFO spec authors,

In 'UFO proper', glyph and group names can be of any length and can include any Unicode characters. For example, the glyph names:

* "A"
* "A.salt2"
* "Zhe-cy"
* "Ж.stylisticAlternate(2)"
* "Książęcych spóźnień czułość jest wspaniała"

are all valid UFO glyph or group names.

However, only the first two (but not the last three) are valid FEA names (glyph or class or anchor names), or valid SFNT glyph names (for use in the 'post' or 'CFF ' table).

UFO specifies that the features.fea file "should be a plain text file and it should be in AFDKO syntax. No assumption should be made about the validity of the syntax."

Currently, unless I'm mistaken, there seems to be no mechanism in UFO that allows font developers to define (in a standardized way) how the UFO glyph and group names relate to FEA names, and how they relate to glyph names intended to be written into the SFNT format.

Since the requirements for a valid FEA name and for a valid SFNT glyph name, are virtually identical, I will refer to such a name as "psname". The most common-sense limit for a psname is that it may only use the ASCII characters from the set "A-Z a-z 0-9 . _" and that the entire name (including "@" in a class name) may not be longer than 31 characters. A useful extension to the psname concept would that a psname consisting only from digits would be permitted, and would be interpreted as a CID.

Since the requirement for a valid psname is vastly different from the requirement for a valid UFO name (which, as I said, can be of any length and include any Unicode characters), I believe that, if a way to define the relation of UFO names to psnames was included in the UFO spec, it would be very beneficial for tool developers.

IMO, one potential thing could be sensible and practical for UFO group and glyph names, though -- to explicitly disallow spaces in them. Additional practical candidates to be disallowed could be the characters disallowed in GLIF filenames, that is " * + / : < > ? [ \ ] | and, if I were to give a vote, also ( ) =.

If such a "psnames.plist" map was permitted by the spec, identical in structure to "contents.plist", where the key is an UFO name (glyph or group) and the value is the psname, it would simplify our lives a lot. Tool and font developers could finally freely use development glyph names which are not limited by the psname limitations, and the psname limitations would only need to apply where they really have to: FEA names (glyph, class, anchor) and SFNT glyph names.

The psnames.plist would of course be optional. Many font developers will, for simplicity's sake, continue to use UFO names which fulfill the validity requirements for psnames. Also, the psnames.plist should allow only partial listing -- i.e. you specify the "translation" only for names that you want translated. The map should also recommend that the mapping is unambiguous in both ways (1:1).

Best,
Adam

[Dave Crossland]

Hi

Great suggestion Adam. The FontForge developers are currently looking at this issue; I guess a psnames.plist in the data directory for UFOv3 files is a good start? :)

--
You received this message because you are subscribed to the Google Groups "Unified Font Object Specification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ufo-spec+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Cheers
Dave

[Tal Leming]

On Sep 2, 2014, at 2:02 PM, Adam Twardoch (List) <list...@twardoch.com> wrote:

> Dear UFO spec authors,
>
> In 'UFO proper', glyph and group names can be of any length and can include any Unicode characters. For example, the glyph names:
>
> * "A"
> * "A.salt2"
> * "Zhe-cy"
> * "Ж.stylisticAlternate(2)"
> * "Książęcych spóźnień czułość jest wspaniała"
>
> are all valid UFO glyph or group names.
>
> However, only the first two (but not the last three) are valid FEA names (glyph or class or anchor names), or valid SFNT glyph names (for use in the 'post' or 'CFF ' table).

Right. This was a conscious decision and it’s not the only place where we have veered from the limitations of old specs. For me at least, this comes out of teaching type design. While I understand why there are naming limitations, try explaining to a group of design students why A should be named “A”, 1 should be named “one” and “ should be named “quotedblleft” in a way that doesn’t immediately make them pull out their phones to check in with MyFaceSpacrr.

> If such a "psnames.plist" map was permitted by the spec, identical in structure to "contents.plist", where the key is an UFO name (glyph or group) and the value is the psname, it would simplify our lives a lot. Tool and font developers could finally freely use development glyph names which are not limited by the psname limitations, and the psname limitations would only need to apply where they really have to: FEA names (glyph, class, anchor) and SFNT glyph names.

I’ve been thinking about some sort of designer name -> binary name field. I don’t think a separate file is necessary. That puts distance between the glyph and the entry. We try to avoid that when we can. The way that I have been thinking of handling it is to add a field to GLIF. I’m not sure if this should be an official attribute or element or if it should be in the lib. An attribute would be tricky to add as it would involve modifying parsers. Adding something to the lib would be easy but I don’t want to start dumping everything into the lib. Also, maybe it should be more than one field to support different output formats.

How about for UFO <= 3 we add something like this to the GLIF lib Common Key Registry:

public.outputname.<format> : string

Thanks,
Tal

[Adam Twardoch (List)]

On 02 Sep 2014, at 20:29, Tal Leming <t...@typesupply.com> wrote:

>
> On Sep 2, 2014, at 2:02 PM, Adam Twardoch (List) <list...@twardoch.com> wrote:
>
>> Dear UFO spec authors,
>>
>> In 'UFO proper', glyph and group names can be of any length and can include any Unicode characters. For example, the glyph names:
>>
>> * "A"
>> * "A.salt2"
>> * "Zhe-cy"
>> * "Ж.stylisticAlternate(2)"
>> * "Książęcych spóźnień czułość jest wspaniała"
>>
>> are all valid UFO glyph or group names.
>>
>> However, only the first two (but not the last three) are valid FEA names (glyph or class or anchor names), or valid SFNT glyph names (for use in the 'post' or 'CFF ' table).
>
> Right. This was a conscious decision and it’s not the only place where we have veered from the limitations of old specs. For me at least, this comes out of teaching type design. While I understand why there are naming limitations, try explaining to a group of design students why A should be named “A”, 1 should be named “one” and “ should be named “quotedblleft” in a way that doesn’t immediately make them pull out their phones to check in with MyFaceSpacrr.

I wholeheartedly agree. To me, the relation between UFO names and psnames is similar as between named points and point indexes, or between modern filenames and DOS 8.3 filenames.

>> If such a "psnames.plist" map was permitted by the spec, identical in structure to "contents.plist", where the key is an UFO name (glyph or group) and the value is the psname, it would simplify our lives a lot. Tool and font developers could finally freely use development glyph names which are not limited by the psname limitations, and the psname limitations would only need to apply where they really have to: FEA names (glyph, class, anchor) and SFNT glyph names.
>
> I’ve been thinking about some sort of designer name -> binary name field. I don’t think a separate file is necessary. That puts distance between the glyph and the entry. We try to avoid that when we can. The way that I have been thinking of handling it is to add a field to GLIF.

I agree. Storing it in the GLIF file makes sense -- in case of names of glyphs.

I imagine that you are not too concerned between allowing explicit mapping between the UFO group names and FEA class names? You're actually right. UFO group names are only used for kerning design, while FEA class names are used to control technical aspects of GSUB and GPOS lookups. There's no real reason why even the contents kerning groups should always translate 1:1 to FEA classes used in the "kern" feature. Historically, they did, but over time, more and more tools abstracted this relation.

Things like "you should put Cyrillic A into a separate class than Latin A or otherwise you'll get subtable overflows when compiling your 'kern' feature" are of technical nature and tools should take care of that -- but the designer should be free to put all kinds of As into one kerning group for the purpose of designing the kerning. Also, the FEA class names only exist in an intermediate format (FEA, that is), and are neither part of UFO proper nor of SFNT. Finally, with the UFO3 kerning group naming (the public.* stuff), these group names won't really translate directly into the FEA class names used for the 'kern' feature anyway, so a tool must do some processing. And since hardly anyone will edit "kern" code by hand, it doesn't really matter how exactly they are produced, as long as they conform to the FEA limits.

So actually, I agree with your suggestion to put this info into the GLIF file.

> I’m not sure if this should be an official attribute or element or if it should be in the lib. An attribute would be tricky to add as it would involve modifying parsers. Adding something to the lib would be easy but I don’t want to start dumping everything into the lib. Also, maybe it should be more than one field to support different output formats.
>
> How about for UFO <= 3 we add something like this to the GLIF lib Common Key Registry:
>
> public.outputname.<format> : string

I think one public.postname is enough. Actually, "postname" is perhaps a neat key: it alludes to the SFNT "post" table whose name comes from "PostScript", but it also suggests that it's an "after-name" or "name to be used later".

If we try to go with the <format> subkey, we'll have to deal with coming up with standardized <format> names for, well, I don't even wanna know :) CFF-flavored vs. TT-flavored something? OpenType? SFNT? Open Font Format? No no, let's keep it simple :)

Most people will be happy with just the normal UFO name and the postname field, perhaps as public.postname for the lib.

If some people need to use more names, they probably have very customized workflows and for that, they can just make up their own lib keys.

Best,
Adam


>
> Thanks,
> Tal

[Tal Leming]

On Sep 2, 2014, at 2:50 PM, Adam Twardoch (List) <list...@twardoch.com> wrote:

> I agree. Storing it in the GLIF file makes sense -- in case of names of glyphs.
>
> I imagine that you are not too concerned between allowing explicit mapping between the UFO group names and FEA class names? You're actually right. UFO group names are only used for kerning design, while FEA class names are used to control technical aspects of GSUB and GPOS lookups. There's no real reason why even the contents kerning groups should always translate 1:1 to FEA classes used in the "kern" feature. Historically, they did, but over time, more and more tools abstracted this relation.
>
> Things like "you should put Cyrillic A into a separate class than Latin A or otherwise you'll get subtable overflows when compiling your 'kern' feature" are of technical nature and tools should take care of that -- but the designer should be free to put all kinds of As into one kerning group for the purpose of designing the kerning. Also, the FEA class names only exist in an intermediate format (FEA, that is), and are neither part of UFO proper nor of SFNT. Finally, with the UFO3 kerning group naming (the public.* stuff), these group names won't really translate directly into the FEA class names used for the 'kern' feature anyway, so a tool must do some processing. And since hardly anyone will edit "kern" code by hand, it doesn't really matter how exactly they are produced, as long as they conform to the FEA limits.

Right. The class names for kerning will have to be modified. This isn’t official, but I wrote a translator for kerning class names in the ufo3 branch of my ufo2fdk package:

https://github.com/typesupply/ufo2fdk/blob/ufo3/Lib/ufo2fdk/kernFeatureWriter.py#L333

> I think one public.postname is enough. Actually, "postname" is perhaps a neat key: it alludes to the SFNT "post" table whose name comes from "PostScript", but it also suggests that it's an "after-name" or "name to be used later”.

Hm, that ambiguity makes me nervous about misinterpretations. We tend to go for making things verbose just in case. “postscriptName” has symmetry with the font info fields like postscriptIsFixedPitch. Are the glyph names in OTF-TTF only stored in the post table? I can’t remember if they are stored elsewhere. If not, we don’t need to worry about any other formats right now. :-)


I opened an issue so that I can add this to the spec next time I am working on it:

https://github.com/unified-font-object/ufo-spec/issues/9


Thanks,
Tal

[Adam Twardoch (List)]

Tal,

In TrueType-flavored SFNT fonts, PostScript glyph names are only stored in the "post" table, and they are optional (many fonts such as Calibri don't include any glyph names if they use "post" table format 3).

In CFF-flavored SFNT fonts, PostScript glyph names are only stored in the "CFF " table. For these fonts, "post" table format 3 (i.e. the one without glyph names) is mandatory. In CFF-flavored SFNT fonts glyph names are also, in a way, optional: CID-keyed CFF-flavored fonts don't use glyph names.

So in fact, PostScript glyph names are optional in both flavors, and if they're there, they only stored in one table ("post" or "CFF ", appropriately).

I'm completely fine with "postscriptName". In fact, the longer the better, as it implies "optionality" a bit ;)

A.