[mpeg-OTspec] OpenType 1.7 new "OS/2" size-range requires "name" table addition
Adam Twardoch (List)
list.adam at twardoch.com
Thu Mar 26 11:22:09 CET 2015
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
>
>
>
More information about the mpeg-otspec
mailing list