No subject

enerate WWS names correctly, and also allow foundries a naming scheme (deci=
ding what params go into nid 16 and which into nid 17, and in which order).=
=20

Altogether, this is sort of like "mini PANOSE by names": less complex than =
PANOSE (because incremental) yet actually more flexible.=20

Of course, thanks to such itemized parameters, also Collection switching wo=
uld be easier. If vendors stick to conventions (which would be still develo=
ped) 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.=20

The old systems of naming would still work, of course. But completely new a=
pps or text engines could gradually adopt aspects of the Collection system =
for certain functionality.=20

A.


Sent from my mobile phone.

> On 26.03.2015, at 11:22, Adam Twardoch (List) <list.adam at twardoch.com> wr=
ote:
>=20
> I would like to propose something similar but different :)=20
>=20
> I don't like this adding more and more nids into the name table every tom=
e to address some small issue.=20
>=20
> Why don't we look at how fonts are made, what kinds of family groupings t=
here are, and reserve a set of name IDs that reflect the commen sense.=20
>=20
> I can think of the following system of 10 name components that could toge=
ther form a Collection of fonts.
>=20
> The Collection is a superset of related fonts and families as we know the=
m today.=20
>=20
> The first and topmost name is the Collection name itself, which is the na=
me that unifies all fonts with a collection.=20
>=20
> nid 30 Collection: Helvetica
>=20
> And then we have up to 9 name IDs which have name components for the most=
 common stylistic differentiators (predefined parameters) within a collecti=
on: Slope, Weight, Width, Optical Size (we may agree to add a few others or=
 reserve a few).=20
>=20
> nid 31 Weight: Black | Light
> nid 32 Width: Wide | Cond | ""
> nid 33 Slope: Italic | ""
> nid 34 OpSize: Caption | Subhead
> nid 35-39 (reserved)
>=20
> Then, we'd have 10 more name IDs which come in pairs: one defines a name =
of a custom parameter, another a corresponding value.=20
>=20
> 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
>=20
> We can suggest some commonly-known parameters but this would be less stri=
ctly predefines, because different vendors may produce collections that dif=
fer on different parameters.=20
>=20
> For example the Noto collection would differ on "Script" parameter while =
the ITC Stone collection would differ on "Style".=20
>=20
> People could come up with other parameter names like "Edition" (for thing=
s like Neue and Next).=20
>=20
> There could be a "Version" parameter where the vendor could put some Vers=
ion info if two coexisting versions were desired (eg during testing).=20
>=20
> Or a "ColorPallette" parameter if there are several multicolor fonts in t=
he collection that differ on the default color pallette.=20
>=20
> Or a "Client" parameter or a "License" parameter (OFL | Commercial). Or a=
 "Medium" parameter (Web | Print | UI | Offc).
>=20
> For each font within the Collection, the combination of all parameters sh=
ould be unique. Each parameter (both predefined and custom) could form an "=
axis" through which a font selection mechanism could iterate, while "freezi=
ng" all the other ones.=20
>=20
> If the font selection needs WWS uniqueness, then it could in memory conca=
tenate 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.=20
>=20
> If the font selection needs optical size switching, it concatenates toget=
her all parameters except OpSize and forms groups this way, and then goes t=
hrough all fonts within one such group (which then will differ only by OpSi=
ze) to switch the size.=20
>=20
> But fancier font selection mechanisms could traverse the tree of availabl=
e fonts via not just "CollectionName" but other parameter combinations: gro=
up all installed fonts by Width and only then show collections.=20
>=20
> In essence, this naming system is more like "tags". It has a stricter sec=
tion of predefined parameters and a looser section of name-value pairs whic=
h allow some flexibility.=20
>=20
> 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 s=
oftware, and later could be made on the fly.=20
>=20
> I proposed only 4 parameters to be predefined: Weight, Width, Slope and O=
pSize. This is because these happen to also be the differentiated numerical=
ly in fonts.=20
>=20
> We could add 1-2 more but I think the custom parameters are a better mech=
anism for anything beyond WWS+size.=20
>=20
> We could reserve a bit more space so the predefined params could be on ni=
ds 30-49 and the custom ones on 50-69 or something.=20
>=20
> What do you think?=20
> Adam
>=20
> Sent from my mobile phone.
>=20
>> On 26.03.2015, at 08:35, Karsten Luecke karsten.luecke at kltf.de [mpeg-OTs=
pec] <mpeg-OTspec-noreply at yahoogroups.com> wrote:
>>=20
>> Hello all.
>>=20
>> Microsoft has just published the specification for OpenType 1.7:
>> http://www.microsoft.com/typography/otspec>
>>=20
>> It specifies a new version of the "OS/2" table which has two additional=
=20
>> entries, "usLowerOpticalPointSize" and "usUpperOpticalPointSize". They=20
>> 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
>>=20
>> These two new entries would be an elegant way to enrich a font family=20
>> with optical size specific designs. For every style, for every optical=20
>> size specific design, there would be a separate font.
>>=20
>> Unfortunately, the mechanism is broken right from the start because it=20
>> is incompletely defined, or rather, not defined at all. Determining a=20
>> font's size range is only half the thing. Defining how the size range=20
>> definition participates in font identification, and hence interacts with=
=20
>> "name" table records, is the other half that is missing.
>>=20
>> I would suggest a simple solution:
>>=20
>> * * *
>>=20
>> a)
>>=20
>> 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=20
>> mention of anything size specific in these names. Size specific=20
>> information are exclusively provided in the new "OS/2" entries. Usually,=
=20
>> proper optical size specific font would be selected automatically based=
=20
>> 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=20
>> name in the UI so users can choose an optical size manually.
>>=20
>> The "OS/2" specification for "usLowerOpticalPointSize" and=20
>> "usUpperOpticalPointSize" needs to refer to the "name" specification for=
=20
>> NameIDs 25=E2=80=9327, and vice versa.
>>=20
>> b)
>>=20
>> Extend the OpenType specification's recommendations, either directly in=
=20
>> the "name" table specification or in the Recommendations document, to=20
>> make sure type designers and font makers do not get overwhelmed by so=20
>> many name table records to deal with.
>> In the end, font naming remains simple. One may get away with using as=20
>> few as two or =E2=80=93 if a family serves optical sizes =E2=80=93 three=
 pairs of=20
>> family/style records. All one needs to do is stick to a few=20
>> recommendations or guidelines:
>>=20
>> 1) Set up the family such that NameID 17 is WWS-conformant right away.=20
>> Any style parameter outside WWS must be part of NameID 16.
>> -> That way NameIDs 21 and 22 can be omitted right away.
>>=20
>> 2) Since only Regular/Bold/Italic/BoldItalic are accepted in NameID 2,=20
>> anything in NameID 17 which is not one of these four will move to NameID=
=20
>> 1. Note: This includes fancy style names!
>>=20
>> 3) Even though Microsoft's WWS-mechanism allows having both Italic and=20
>> Oblique styles in fonts, do not do this. Make Italic and forget about=20
>> Oblique.
>>=20
>> Only if optical sizes are involved:
>>=20
>> 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=
=20
>> the difference.
>>=20
>> 4b) Include optical size name additions in NameIDs 1 and 2 and NameIDs=20
>> 16 and 17. (And in NameIDs 21 and 22 if present, but again, try to avoid=
=20
>> them.)
>> -> Old font engines that don't know about new "OS/2" entires simply sees=
=20
>> a different(ly
>> named) family per each optical size range.
>>=20
>> Fancy style names:
>>=20
>> 5) Avoid fancy style names as they are =E2=80=93 obviously =E2=80=93 not=
 WWS conformant.=20
>> See 2) in case you cannot avoid them.
>>=20
>> c)
>>=20
>> [Please use monospaced font for what follows.]
>>=20
>> Example:
>>=20
>> | range | ID 24  | ID 25           | ID 26 || ID 16       | ID 17=20
>>    || ID 1             | ID 2    |
>> |-------|--------|-----------------|-------||-------------|-------------=
----||------------------|---------|
>> |  0- 8 | MyFont | Regular         | Note  || MyFont Note | Regular=20
>>    || MyFont Note      | Regular |
>> |  9-13 | MyFont | Regular         | Text  || MyFont Text | Regular=20
>>    || MyFont Text      | Regular |
>> | 14-x  | MyFont | Regular         | Head  || MyFont Head | Regular=20
>>    || MyFont Head      | Regular |
>> |-------|--------|-----------------|-------||-------------|-------------=
----||------------------|---------|
>> |  0- 8 | MyFont | Italic          | Note  || MyFont Note | Italic=20
>>    || MyFont Note      | Italic  |
>> |  9-13 | MyFont | Italic          | Text  || MyFont Text | Italic=20
>>    || MyFont Text      | Italic  |
>> | 14-x  | MyFont | Italic          | Head  || MyFont Head | Italic=20
>>    || MyFont Head      | Italic  |
>> |-------|--------|-----------------|-------||-------------|-------------=
----||------------------|---------|
>> |  0- 8 | MyFont | SemiBold        | Note  || MyFont Note | SemiBold=20
>>    || MyFont SmBd Note | Regular |
>> |  9-13 | MyFont | SemiBold        | Text  || MyFont Text | SemiBold=20
>>    || MyFont SmBd Text | Regular |
>> | 14-x  | MyFont | SemiBold        | Head  || MyFont Head | SemiBold=20
>>    || MyFont SmBd Head | Regular |
>> |-------|--------|-----------------|-------||-------------|-------------=
----||------------------|---------|
>> |  0- 8 | MyFont | SemiBold Italic | Note  || MyFont Note | SemiBold=20
>> Italic || MyFont SmBd Note | Italic  |
>> |  9-13 | MyFont | SemiBold Italic | Text  || MyFont Text | SemiBold=20
>> Italic || MyFont SmBd Text | Italic  |
>> | 14-x  | MyFont | SemiBold Italic | Head  || MyFont Head | SemiBold=20
>> Italic || MyFont SmBd Head | Italic  |
>> |-------|--------|-----------------|-------||-------------|-------------=
----||------------------|---------|
>>=20
>> What you get in applications' font menus:
>>=20
>> i) Application is aware of sizes:
>>=20
>> MyFont > Regular
>>         Italic
>>         SemiBold
>>         SemiBold Italic
>> No size info mentioned since choice is made automatically by the=20
>> application.
>>=20
>> ii) Application is aware of sizes, designer software:
>>=20
>> MyFont > Regular
>>         Italic
>>         SemiBold
>>         SemiBold Italic
>> Optical sizes are offered in a separate popup. (Greyed out with non-size=
=20
>> font families.)
>> If NameID 26 is not defined in "name", use "OS/2" size range as a name,=
=20
>> turning it into a string like "8=E2=80=9312".
>>=20
>> iii) In oldstyle applications, aware of Typographic names:
>>=20
>> 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.
>>=20
>> iv) In legacy applications, not aware of Typographic names:
>>=20
>> 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.
>>=20
>> * * *
>>=20
>> While I sympathize with the idea of coming up with a completely new way=
=20
>> of identifying fonts, the damage has been done already when rushing to=20
>> specify half the thing. Designers who feel tempted to make use of these=
=20
>> new "OS/2" entries will by definition produce buggy fonts. For this=20
>> reason, I think, a backward compatible solution needs to be presented=20
>> sooner rather than later.
>>=20
>> Best wishes,
>> Karsten L=C3=BCcke
>>=20
>>=20
>> ------------------------------------
>>=20
>> ------------------------------------
>>=20
>>=20
>> ------------------------------------
>>=20
>> Yahoo Groups Links
>>=20
>>=20
>>=20