Please normalise the naming of Merriweather faces

[nim-nim]

Merriweather is a great and rich font design. Thank you very much.

However, its naming conventions seem to deviate significantly from OpenType specs. It is a huge problem for Merriweather use on non Apple platforms. OSX allows very lax font naming, relying on users to select things in raw name lists; other platforms assume spec compliance and rely on strict naming rules (building on those rules to to interesting things). Apple has a complex relation with OpenType and it shows.

It would be very nice if Merriweather could honor WWS rules and only use width weight slant qualifiers in its face naming (in that order, in Name ID 16/17), as recommended by the OpenType spec: https://docs.microsoft.com/fr-ca/typography/opentype/spec/namesmp

It would be very nice if the width weight slant keywords in style names conformed to the OpenType and CSS defaults, when one of those defaults matches exactly the intended value.

For example both specs define a 50% width as UltraCondensed. There is no need to rename it to Narrow except to confuse users and software (some software will display UltraCondensed regardless of what the font files declare because software authors are utterly fed up with font maker spec deviations; that makes non conformant font faces very confusing to users, as they appear under different names in different softwares) https://docs.microsoft.com/en-us/typography/opentype/spec/os2#usweightclass https://docs.microsoft.com/en-us/typography/opentype/spec/os2#uswidthclass https://www.w3.org/TR/css-fonts-4/#font-weight-prop https://www.w3.org/TR/css-fonts-4/#font-stretch-prop

(you can write multi token keywords as UltraCondensed or Ultra-Condensed, it’s the same for users and software, just do not use spaces in keywords like Ultra Condensed, software chokes on them)

Optical size variations should be given a separate font family name to allow automatic application by software (software understands the optical axis in variable fonts or separate font families for non variable fonts; no software I know can cope with optical axis variations as separate faces in the same family).

It would be nice if the intended ranges optical sizes should be applied on was documented

Although the exact intended sizes vary by family, the general size ranges include: caption (6-8 point), regular (9-13 point), subhead (14-24 point) and display (25-72 point). https://www.adobe.com/products/type/opentype.html

If some of the faces I missed correspong to design variations, please do not make them separate faces; make them separate font families (if they are not accessible via standard opentype features) or integrate them in standard faces (otherwise).

Lastly Merriweather35 does not seem to me maintained. Should it be considered as a past experiment? Or has it got some future?

[nim-nim]

Ok, digging into it some more (that was quite painful) Merriweather is a nice regular font family, with the following OpenType axes:

• weight: { Light: 169, Regular: 220, Bold: 300, Black: 350}
• width: { Narrow: 80, Regular: 100, Wide: 125}
• optical size: { Regular: 12, Text: 54, Heading: 90, Display:144}

However, its naming is horrible and does not follow the OpenType & CSS recommendations, which makes it a PITA to use and software-side.

Now, according to the OpenType & CSS spec:

• for widths:
  • Narrow should probably be renamed Condensed (it is stuck between Condensed and SemiCondensed, but closer to Condensed)
  • Wide should definitely be renamed Expanded (perfect spec match)
• for weights:
  • Light and Regular match the spec
  • Bold is closer to a Medium
  • Black is closer to SemiBold
  • historically one could ignore default weight designations but the OpenType spec converts back and forth between historical weight constants and the variable weight axis values, so that does not work for a variable font family
  • also the CSS spec requires software to ignore naming and work from weight values, so names that diverge from the associated values will create incompatibilities between manual and automated text processing workflows
• there are no rules for optical size yet, so its free for all for now

Therefore, according to WWS rules:

• the family should be split into Merriweather, Merriweather Text, Merriweather Heading and Merriweather Display (a lot of apps won’t be able to apply optical sizing if it optical sizes are not separated in distinct families, that sucks but optical size axis is not baked yet OpenType side)

• in each of those families the WWS attributes should be declared in width weight slant order for legacy compatibility

• and please remove the redundant Regulars everywhere, the spec is very clear Regular is a placeholder for the default face only, to avoid an empty face name.

Of course, you can ignore all this, but it would be a shame not to do it, the font family is quite regular, only its naming completely diverges from the standard.

[EbenSorkin]

I'll chat to Google about the condensation names. The weight names will probably not be changed because they have existed this way for a long time and users of the font won't want to see change of that kind I think. In terms of the WWS rules: it is unclear to me if VF standards really exist in the sense that you are asserting. This stuff is evolving. I will have to take my guidance from Google on this since they are funding the dev. With regard to "regular" in non-variable OTF and TTF fonts this irrational use of regular in parts the name tables along with the actual weight name ( semi-Bold for example) is a legacy of past standards and cannot be eliminated without causing problems with use outside of web use e.g. in Adobe Apple and MS apps etc. If what you are talking about is inside the VF then that something I'll need to ask Google about.

[nim-nim]

Thanks for answering.

The weight naming is not critical so far but the whole situation sucks since CSS4 states in https://www.w3.org/TR/css-fonts-4/#font-weight-prop

A font might internally provide its own weight name mappings, but those mappings within the font are disregarded in CSS.

So CSS-oriented workflows will derive naming from weight values

However the OpenType spec states in https://docs.microsoft.com/en-us/typography/opentype/spec/dvaraxistag_wght

Scale interpretation: Values can be interpreted in direct comparison to values for usWeightClass in the OS/2 table, or the CSS font-weight property.

The Weight axis can be used as a variation axis within a variable font. It can also be used within a STAT table in non-variable fonts within a family that has weight variants to provide a complete characterization of a font in relation to its family within the STAT table.

In a variable font that implements 'wght' variations, the value in the usWeightClass field of the OS/2 table must match the default 'wght' value specified in the 'fvar' table. For non-default instances of a variable font, the 'wght' axis value can be used as the OS/2.usWeightClass value for the instance

And in https://docs.microsoft.com/en-us/typography/opentype/spec/os2#usweightclass

usWeightClass values use the same scale as the 'wght' axis that is used in the 'fvar' table of variable fonts and in the STAT table. While integer values from 1 to 1000 are supported, some legacy platforms may have limitations on supported values. The following are commonly-used values:

So here naming means a specific weight and all the weight layers in OpenType are linked together

The only way to square the wheel now that the spec links everything together is to use standard step names for standard weight values

[nim-nim]

As for Regular, https://docs.microsoft.com/en-us/typography/opentype/spec/namesmp

shows how it is supposed to be used in naming. It is omitted everywhere except for the default width default weight default slant face. It’s like a leading zero in numbers: you're not supposed to write it except when your number is really zero and not writing a zero will result in an empty number.

And even when you do have to use Regular at Name ID 2, 17 or 22 (because otherwise it will be empty) the spec insists it should be removed from Name ID 4, when combined with the family name

Note that name IDs 16 and 17 should also be included in these fonts, and that name ID 4 would typically be a combination of name IDs 16 and 17, without needing any additional qualifications regarding “Regular”.

Also https://docs.microsoft.com/en-us/typography/opentype/spec/namesmp shows how writing face qualifiers in Width Weight Slant order is nicely backwards compatible with pre-width naming

The spec is pretty sparse on instance naming, however it is clearly intended to follow the same rules as Name ID 16/17 (corrected in Name ID 21/22 in case of WWS non conformance)

https://docs.microsoft.com/en-us/typography/opentype/spec/name states

Note, in particular, that variable fonts can include a large number of named instances, each of which will use a shared typographic family name (name ID 16) and will have a typographic subfamily name (equivalent to name ID 17).

Not following the same rules would break transparent conversion of documents from non variable to variable fonts anyway, so it’s the only sane way to do it.

[nim-nim]

Since I realise the OpenType spec is an arid document, let’s get a concrete example of why adding Regular right and left in style (or style instance) names is incorrect.

If that was the intended behaviour

https://docs.microsoft.com/en-us/typography/opentype/spec/namesmp

would not name the Bold style Bold but Regular Bold (to distinguish it from Narrow Bold), or Bold Regular (to distinguish it from Bold Italic) or Regular Bold Regular (to distinguish it from Narrow Bold Italic)

That Bold is named plain Bold in the spec, and that everyone expects it to be named plain Bold without reading the spec, shows that Regular is not supposed to be mentioned in style names, except the the default (weight width slant all at default values) because otherwise the default would be an empty string.

[EbenSorkin]

I think I found the way to get this done generally but I have not checked the name IDs getting generated.

[nim-nim]

Thank you very much for working on a fix!

Just ping me in this issue when you have produced some font files, that you would like to be tested on our software stack.

[davelab6]

@nim-nim This project is still very much work in process! Thanks for your detailed comments, and offer for further testing. You may be interested in https://github.com/TypeNetwork/Roboto-Flex also :)

[EbenSorkin]

I'm going to look at posibly using TTFont, used in Python to provide better WSS support after I compare what Fontmake is now generating for us to the spec listed above. Again I am not sure what name table policy will be in the end for some of this. At the moment I am most interested in ID 16 & 17 because Menu structures and population in Adobe CC on the Mac seem not to be OK yet. This could also be an Adobe bug.

[nim-nim]

Thanks. You don’t need to bother with ID 21/22 if you create good ID 16/17. ID 21/22 are just a way to override ID 16/17 if those are broken and do not follow WWS rules. A new font project like Merriweather should just create good ID 16∕17 that do not need overriding later.

[EbenSorkin]

It may be a good idea to have a look at the newest build uploaded this evening because the naming has changed a very great deal. Note that TTFs and VFs use fontmake interpretation of the sources and OTFs are generated by Glyphs App so the names tables may differ a bit. The new VFs files have stat table support.