[mpeg-OTspec] OpenType 1.7 new "OS/2" size-range requires "name" table addition

[Karsten Luecke]

Hello Adam,

I am all for a generic approach.
I would even go with a new "nam2" table for such an all-new approach. 
Same data structure but a fresh start as regards predefined NIDs. (How 
to deal e.g. with name records referenced from GSUB/GPOS? Maybe 
something like: Check "nam2" for requested NID. If "nam2" not present or 
NID not in "nam2", then check "name" instead.)
In addition to what you suggest, the NID 31–34 parameter might be set to 
"interpolated" in case that a multiple-axes or multiple-masters font 
addresses Weight or Width or Optical Size or other.
Not sure about the arbitrary NID 40+ pairs, though, isn't that waste of 
records?

The latter hint at what I consider a problem, no, three problems of such 
an approach:
a) The immediate one is font management:
Applications need a different kind of font management as well as GUI for 
font selection. How willing are the respective companies to invest in 
revamping their applications?
b) Which leads to GUI:
That GUI will occupy quite some screen estate. For now applications can 
get away with two popup menus (family plus style). Your suggestion 
requires a minimum of four (your NIDs 31–34) and needs to be able to add 
more if needed (your NIDs 40+). (What I could imagine is that these are 
concatenate such that a conventional font GUI can show, again, family 
plus style.)
c) Which in turn leads to use of it:
Do I really want to deal with a list of parameters just to select a 
family and then italicise and bolden a word or headline? What is at most 
two changes in a currently common font GUI may be up to four changes in 
a future GUI. When at the same time many families don't address even 
half the parameters you offer by default. Imagine you try to set certain 
parameters, only to find out they are not served by the family anyway. I 
already see application developers fake what's missing in the font so 
the GUI's "promises" are fulfilled regardless what the font offers. (If 
there is a button, users expect that it'll do something.)

I came up with my admittedly utterly unoriginal suggestion only after 
some thought games along these lines.
One aspect: Possibilities of such an approach is one thing, inevitable 
consequences of such an approach is another thing.
Another aspect: Which amount of complexity can users deal with, or more 
trivially, which amount of complexity do they actually need?
If you manage to reduce complexity again, GUI-wise, fine.

Best wishes,
Karsten


On 26.03.15 12:41, Adam Twardoch (List) wrote:
> When the font selection mechanism evaluates a collection, it should compile a list of all parameters that are defined in any font that belongs to the collection.
>
> If a given parameter is defined in at least one font in that collection, then that parameter is considered a valid parameter in that collection.
>
> Not every font in the collection needs to explicitly provide a value for each valid parameter in the collection. When a font does not provide a value for a valid parameter in the collection, then that parameter assumes the implicit value Default for that font.
>
> The combination of the values for all valid parameters fonts (including when the value is Default) must be unique for each font in the collection.
>
> When the collection's valid parameters are presented to the user individually (in a "parameter matrix" or "parameter list" UI), the default value for a parameter in the fonts may be presented using the string "Default", possibly in parentheses, or other similar term.
>
> For the predefined parameters, the Default value may be presented using other, customary, terms (possibly in parentheses):
>
> For Weight: "Regular"
> For Width: "Normal"
> For Slope: "Plain"
> For OpticalSize: "All Sizes"
> For Charset: "Standard"
>
> The font with the greatest number of Default parameter values with the collection is considered the default font of that collection.
>
> If the fonts in the collection are presented to the user as a list of font entries (one per font), the app may construct the name of each entry by reading the values of the predefined valid parameters in the order: Weight, Width, Slope, OpticalSize, followed by the values of the custom valid parameters in the dominant order of their corresponding name table ID in the font collection name tables, and concatenating them using spaces. The Default values are omitted from this process.
>
> (I just realized that the term "Collection" may not be the best because of potential of confusion with "OpenType Collection" (.ttc, .otc).
>
> A better term is needed.
>
> A.
>
> Sent from my mobile phone.
>
>> On 26.03.2015, at 11:46, Adam Twardoch (List)<list.adam at twardoch.com>  wrote:
>>
>> "Charset" could be made a predefined parameter for one important reason: font fallback.
>>
>> For things like Noto or Source Han Sans and other such font collections, it would be easy to group fonts that cover various charsets, and the font selection mechanism could attempt font fallback within the same collection first, which would yield more consistent results.
>>
>> In a way, the predefined parameters echo the registered OT features like smcp, onum or liga — but for fonts.
>>
>> If we predefine Weight, Width and Slope, then supplemented with the already existing numerical params, fonts could be switched within a WWS context.
>>
>> If we predefine the OpSize parameter, then the new OS/2 optical size stuff is solved. And, as I said, predefining Charset would help in font fallback.
>>
>> And the custom name-value parameter pairs are a bit like named ssXX features: we don't really define the exact semantics but allow foundries to establish some still-common parameters as conventions, and still be flexible in things to come.
>>
>>  From such a pool of parameters, it'd bd trivial for font creation apps to generate WWS names correctly, and also allow foundries a naming scheme (deciding what params go into nid 16 and which into nid 17, and in which order).
>>
>> Altogether, this is sort of like "mini PANOSE by names": less complex than PANOSE (because incremental) yet actually more flexible.
>>
>> Of course, thanks to such itemized parameters, also Collection switching would be easier. If vendors stick to conventions (which would be still developed) then when a user switches the "Helvetica" collection to the "Frutiger" Collection, the app could parse the new collection for closest matches for all the params and produce the most sensible result.
>>
>> The old systems of naming would still work, of course. But completely new apps or text engines could gradually adopt aspects of the Collection system for certain functionality.
>>
>> A.
>>
>>
>> Sent from my mobile phone.
>>
>>> On 26.03.2015, at 11:22, Adam Twardoch (List)<list.adam at twardoch.com>  wrote:
>>>
>>> I would like to propose something similar but different :)
>>>
>>> I don't like this adding more and more nids into the name table every tome to address some small issue.
>>>
>>> Why don't we look at how fonts are made, what kinds of family groupings there are, and reserve a set of name IDs that reflect the commen sense.
>>>
>>> I can think of the following system of 10 name components that could together form a Collection of fonts.
>>>
>>> The Collection is a superset of related fonts and families as we know them today.
>>>
>>> The first and topmost name is the Collection name itself, which is the name that unifies all fonts with a collection.
>>>
>>> nid 30 Collection: Helvetica
>>>
>>> And then we have up to 9 name IDs which have name components for the most common stylistic differentiators (predefined parameters) within a collection: Slope, Weight, Width, Optical Size (we may agree to add a few others or reserve a few).
>>>
>>> nid 31 Weight: Black | Light
>>> nid 32 Width: Wide | Cond | ""
>>> nid 33 Slope: Italic | ""
>>> nid 34 OpSize: Caption | Subhead
>>> nid 35-39 (reserved)
>>>
>>> Then, we'd have 10 more name IDs which come in pairs: one defines a name of a custom parameter, another a corresponding value.
>>>
>>> nid 40 ParamName: Charset
>>> nid 41 ParamValue: Arabic | WGL4
>>> nid 42 ParamName: Grade
>>> nid 43 ParamValue: G1 | G2
>>> nid 44 ParamName: Style
>>> nid 45 ParamValue: Serif | Slab | Naskh | Kufi | Engraved
>>> nid 46-59 as above
>>>
>>> We can suggest some commonly-known parameters but this would be less strictly predefines, because different vendors may produce collections that differ on different parameters.
>>>
>>> For example the Noto collection would differ on "Script" parameter while the ITC Stone collection would differ on "Style".
>>>
>>> People could come up with other parameter names like "Edition" (for things like Neue and Next).
>>>
>>> There could be a "Version" parameter where the vendor could put some Version info if two coexisting versions were desired (eg during testing).
>>>
>>> Or a "ColorPallette" parameter if there are several multicolor fonts in the collection that differ on the default color pallette.
>>>
>>> Or a "Client" parameter or a "License" parameter (OFL | Commercial). Or a "Medium" parameter (Web | Print | UI | Offc).
>>>
>>> For each font within the Collection, the combination of all parameters should be unique. Each parameter (both predefined and custom) could form an "axis" through which a font selection mechanism could iterate, while "freezing" all the other ones.
>>>
>>> If the font selection needs WWS uniqueness, then it could in memory concatenate all parameters except Weight, Width and Slope to form WWS groups. So a group could be formed as "Helvetica Arabic Naskh G1" and within it, all fonts would differ by WWS.
>>>
>>> If the font selection needs optical size switching, it concatenates together all parameters except OpSize and forms groups this way, and then goes through all fonts within one such group (which then will differ only by OpSize) to switch the size.
>>>
>>> But fancier font selection mechanisms could traverse the tree of available fonts via not just "CollectionName" but other parameter combinations: group all installed fonts by Width and only then show collections.
>>>
>>> In essence, this naming system is more like "tags". It has a stricter section of predefined parameters and a looser section of name-value pairs which allow some flexibility.
>>>
>>> In font creation apps, a designer would really only fill in those params. The traditional name IDs like 16, 17 etc. could be easily created by the software, and later could be made on the fly.
>>>
>>> I proposed only 4 parameters to be predefined: Weight, Width, Slope and OpSize. This is because these happen to also be the differentiated numerically in fonts.
>>>
>>> We could add 1-2 more but I think the custom parameters are a better mechanism for anything beyond WWS+size.
>>>
>>> We could reserve a bit more space so the predefined params could be on nids 30-49 and the custom ones on 50-69 or something.
>>>
>>> What do you think?
>>> Adam
>>>
>>> Sent from my mobile phone.
>>>
>>>> On 26.03.2015, at 08:35, Karsten Luecke karsten.luecke at kltf.de [mpeg-OTspec]<mpeg-OTspec-noreply at yahoogroups.com>  wrote:
>>>>
>>>> Hello all.
>>>>
>>>> Microsoft has just published the specification for OpenType 1.7:
>>>> http://www.microsoft.com/typography/otspec>
>>>>
>>>> It specifies a new version of the "OS/2" table which has two additional
>>>> entries, "usLowerOpticalPointSize" and "usUpperOpticalPointSize". They
>>>> define the range of sizes for which a font has been designed:
>>>> http://www.microsoft.com/typography/otspec170/os2.htm#lps
>>>> http://www.microsoft.com/typography/otspec170/os2.htm#ups
>>>>
>>>> These two new entries would be an elegant way to enrich a font family
>>>> with optical size specific designs. For every style, for every optical
>>>> size specific design, there would be a separate font.
>>>>
>>>> Unfortunately, the mechanism is broken right from the start because it
>>>> is incompletely defined, or rather, not defined at all. Determining a
>>>> font's size range is only half the thing. Defining how the size range
>>>> definition participates in font identification, and hence interacts with
>>>> "name" table records, is the other half that is missing.
>>>>
>>>> I would suggest a simple solution:
>>>>
>>>> * * *
>>>>
>>>> a)
>>>>
>>>> Add three new "name" table NameIDs:
>>>>   1) NameID 25: Size-aware Typographic Family name.
>>>>   2) NameID 26: Size-aware Typographic Subfamily name.
>>>> Essentially the same as NameIDs 16 and 17, except that there is no
>>>> mention of anything size specific in these names. Size specific
>>>> information are exclusively provided in the new "OS/2" entries. Usually,
>>>> proper optical size specific font would be selected automatically based
>>>> on the font size determined by the user.
>>>>   3) NameID 27: Size name.
>>>> This may be helpful for applications which want expose an optical size
>>>> name in the UI so users can choose an optical size manually.
>>>>
>>>> The "OS/2" specification for "usLowerOpticalPointSize" and
>>>> "usUpperOpticalPointSize" needs to refer to the "name" specification for
>>>> NameIDs 25–27, and vice versa.
>>>>
>>>> b)
>>>>
>>>> Extend the OpenType specification's recommendations, either directly in
>>>> the "name" table specification or in the Recommendations document, to
>>>> make sure type designers and font makers do not get overwhelmed by so
>>>> many name table records to deal with.
>>>> In the end, font naming remains simple. One may get away with using as
>>>> few as two or – if a family serves optical sizes – three pairs of
>>>> family/style records. All one needs to do is stick to a few
>>>> recommendations or guidelines:
>>>>
>>>> 1) Set up the family such that NameID 17 is WWS-conformant right away.
>>>> Any style parameter outside WWS must be part of NameID 16.
>>>> ->  That way NameIDs 21 and 22 can be omitted right away.
>>>>
>>>> 2) Since only Regular/Bold/Italic/BoldItalic are accepted in NameID 2,
>>>> anything in NameID 17 which is not one of these four will move to NameID
>>>> 1. Note: This includes fancy style names!
>>>>
>>>> 3) Even though Microsoft's WWS-mechanism allows having both Italic and
>>>> Oblique styles in fonts, do not do this. Make Italic and forget about
>>>> Oblique.
>>>>
>>>> Only if optical sizes are involved:
>>>>
>>>> 4a) Exclude optical size name additions from new NameIDs 25 and 26.
>>>> ->  Up-to-date font engines know that it is new "OS/2" entries that make
>>>> the difference.
>>>>
>>>> 4b) Include optical size name additions in NameIDs 1 and 2 and NameIDs
>>>> 16 and 17. (And in NameIDs 21 and 22 if present, but again, try to avoid
>>>> them.)
>>>> ->  Old font engines that don't know about new "OS/2" entires simply sees
>>>> a different(ly
>>>> named) family per each optical size range.
>>>>
>>>> Fancy style names:
>>>>
>>>> 5) Avoid fancy style names as they are – obviously – not WWS conformant.
>>>> See 2) in case you cannot avoid them.
>>>>
>>>> c)
>>>>
>>>> [Please use monospaced font for what follows.]
>>>>
>>>> Example:
>>>>
>>>> | range | ID 24  | ID 25           | ID 26 || ID 16       | ID 17
>>>>    || ID 1             | ID 2    |
>>>> |-------|--------|-----------------|-------||-------------|-----------------||------------------|---------|
>>>> |  0- 8 | MyFont | Regular         | Note  || MyFont Note | Regular
>>>>    || MyFont Note      | Regular |
>>>> |  9-13 | MyFont | Regular         | Text  || MyFont Text | Regular
>>>>    || MyFont Text      | Regular |
>>>> | 14-x  | MyFont | Regular         | Head  || MyFont Head | Regular
>>>>    || MyFont Head      | Regular |
>>>> |-------|--------|-----------------|-------||-------------|-----------------||------------------|---------|
>>>> |  0- 8 | MyFont | Italic          | Note  || MyFont Note | Italic
>>>>    || MyFont Note      | Italic  |
>>>> |  9-13 | MyFont | Italic          | Text  || MyFont Text | Italic
>>>>    || MyFont Text      | Italic  |
>>>> | 14-x  | MyFont | Italic          | Head  || MyFont Head | Italic
>>>>    || MyFont Head      | Italic  |
>>>> |-------|--------|-----------------|-------||-------------|-----------------||------------------|---------|
>>>> |  0- 8 | MyFont | SemiBold        | Note  || MyFont Note | SemiBold
>>>>    || MyFont SmBd Note | Regular |
>>>> |  9-13 | MyFont | SemiBold        | Text  || MyFont Text | SemiBold
>>>>    || MyFont SmBd Text | Regular |
>>>> | 14-x  | MyFont | SemiBold        | Head  || MyFont Head | SemiBold
>>>>    || MyFont SmBd Head | Regular |
>>>> |-------|--------|-----------------|-------||-------------|-----------------||------------------|---------|
>>>> |  0- 8 | MyFont | SemiBold Italic | Note  || MyFont Note | SemiBold
>>>> Italic || MyFont SmBd Note | Italic  |
>>>> |  9-13 | MyFont | SemiBold Italic | Text  || MyFont Text | SemiBold
>>>> Italic || MyFont SmBd Text | Italic  |
>>>> | 14-x  | MyFont | SemiBold Italic | Head  || MyFont Head | SemiBold
>>>> Italic || MyFont SmBd Head | Italic  |
>>>> |-------|--------|-----------------|-------||-------------|-----------------||------------------|---------|
>>>>
>>>> What you get in applications' font menus:
>>>>
>>>> i) Application is aware of sizes:
>>>>
>>>> MyFont>  Regular
>>>>         Italic
>>>>         SemiBold
>>>>         SemiBold Italic
>>>> No size info mentioned since choice is made automatically by the
>>>> application.
>>>>
>>>> ii) Application is aware of sizes, designer software:
>>>>
>>>> MyFont>  Regular
>>>>         Italic
>>>>         SemiBold
>>>>         SemiBold Italic
>>>> Optical sizes are offered in a separate popup. (Greyed out with non-size
>>>> font families.)
>>>> If NameID 26 is not defined in "name", use "OS/2" size range as a name,
>>>> turning it into a string like "8–12".
>>>>
>>>> iii) In oldstyle applications, aware of Typographic names:
>>>>
>>>> MyFont Note>  Regular
>>>>              Italic
>>>>              SemiBold
>>>>              SemiBold Italic
>>>> MyFont Text>  Regular
>>>>              Italic
>>>>              SemiBold
>>>>              SemiBold Italic
>>>> MyFont Head>  Regular
>>>>              Italic
>>>>              SemiBold
>>>>              SemiBold Italic
>>>> New "OS/2" entries are ignored.
>>>>
>>>> iv) In legacy applications, not aware of Typographic names:
>>>>
>>>> MyFont SmBd Note>  Regular (default)
>>>>                   Italic (via "I" button)
>>>> MyFont SmBd Text>  Regular (default)
>>>>                   Italic (via "I" button)
>>>> MyFont SmBd Head>  Regular (default)
>>>>                   Italic (via "I" button)
>>>> MyFont Note>  Regular (default)
>>>>                   Italic (via "I" button)
>>>> MyFont Text>  Regular (default)
>>>>                   Italic (via "I" button)
>>>> MyFont Head>  Regular (default)
>>>>                   Italic (via "I" button)
>>>> New "OS/2" entries are ignored.
>>>>
>>>> * * *
>>>>
>>>> While I sympathize with the idea of coming up with a completely new way
>>>> of identifying fonts, the damage has been done already when rushing to
>>>> specify half the thing. Designers who feel tempted to make use of these
>>>> new "OS/2" entries will by definition produce buggy fonts. For this
>>>> reason, I think, a backward compatible solution needs to be presented
>>>> sooner rather than later.
>>>>
>>>> Best wishes,
>>>> Karsten Lücke
>>>>
>>>>
>>>> ------------------------------------
>>>>
>>>> ------------------------------------
>>>>
>>>>
>>>> ------------------------------------
>>>>
>>>> Yahoo Groups Links
>>>>
>>>>
>>>>