googlefonts / fontc

Where in we pursue oxidizing (context: https://github.com/googlefonts/oxidize) fontmake.
Apache License 2.0
83 stars 14 forks source link

name table for NotoSerifHentaigana doesn't match fontmake's #906

Closed anthrotype closed 2 months ago

anthrotype commented 3 months ago

I suspect that fontir's NameBuilder isn't matching 100% the ufo2ft's default fallbacks for family/style

$ diff -u /Users/clupo/oss/fontc/build/default/fontc.name.ttx /Users/clupo/oss/fontc/build/default/fontmake.name.ttx
--- /Users/clupo/oss/fontc/build/default/fontc.name.ttx 2024-08-19 16:52:22
+++ /Users/clupo/oss/fontc/build/default/fontmake.name.ttx  2024-08-19 16:52:22
@@ -3,22 +3,22 @@
       Copyright 2023 The Noto Project Authors (https://github.com/notofonts/hentaigana)
     </namerecord>
     <namerecord nameID="1" platformID="3" platEncID="1" langID="0x409">
-      Noto Serif Hentaigana
+      Noto Serif Hentaigana EL
     </namerecord>
     <namerecord nameID="2" platformID="3" platEncID="1" langID="0x409">
       Regular
     </namerecord>
     <namerecord nameID="3" platformID="3" platEncID="1" langID="0x409">
-      1.000;GOOG;NotoSerifHentaigana-Regular
+      1.000;GOOG;NotoSerifHentaigana-EL
     </namerecord>
     <namerecord nameID="4" platformID="3" platEncID="1" langID="0x409">
-      Noto Serif Hentaigana Regular
+      Noto Serif Hentaigana EL
     </namerecord>
     <namerecord nameID="5" platformID="3" platEncID="1" langID="0x409">
       Version 1.000
     </namerecord>
     <namerecord nameID="6" platformID="3" platEncID="1" langID="0x409">
-      NotoSerifHentaigana-Regular
+      NotoSerifHentaigana-EL
     </namerecord>
     <namerecord nameID="7" platformID="3" platEncID="1" langID="0x409">
       Noto is a trademark of Google Inc.
\ No newline at end of file
@@ -38,6 +38,12 @@
     <namerecord nameID="14" platformID="3" platEncID="1" langID="0x409">
       https://scripts.sil.org/OFL
     </namerecord>
+    <namerecord nameID="16" platformID="3" platEncID="1" langID="0x409">
+      Noto Serif Hentaigana
+    </namerecord>
+    <namerecord nameID="17" platformID="3" platEncID="1" langID="0x409">
+      EL
+    </namerecord>
     <namerecord nameID="256" platformID="3" platEncID="1" langID="0x409">
       Weight
     </namerecord>
anthrotype commented 2 months ago

there are a few issues with the current NameBuilder, and the way it's used by two main front-ends (glyphs and ufo).

1) glyphs2fontir is currently using the familyNames attibute to mean the legacy family name (nameID=1), but it actually should correspond to the typographic sort (nameID=16) 1) similarly, the UFO fontinfo familyName is currently assumed to mean the legacy family name, whereas it actually is equivalent to a typographic family name, i.e. without any restrictions as to the valid RIBBI style it can be associated; 1) NameBuilder::default() always defaults to "Regular" subfamily name (nameID=2); and being already predefined, the fallback logic never kicks in; 1) glyphs2fontir never sets any subfamily, neither legacy nor typographic, so all .glyphs source currently get the default "Regular" as nameID=2 all the time; it should instead use the default master's name as the typographic subfamily name. 1) ufo2fontir never sets the typographic subfamily name (font_info.open_type_name_preferred_subfamily_name in norad)

The way it works in fontmake/glyphsLib/ufo2ft it is that the more general family/style names without RIBBI restrictions are usually the ones present, and used to make the legacy (non typographic, RIBBI) names; unless the more specific legacy are actually defined (only UFO allows to set them directly, .glyphs source don't even allow you to set those directly as far as I am aware). And the way the legacy names are derived from the typographic ones is, by checking if they meet the RIBBI requirements, then use those; otherwise append the non-RIBBI style name to the legacy family (nameID=1) and set legacy subfamily (nameID=2) to "Regular", so the non RIBBI styles go into a separate legacy family of their own.

Note this only manifest itself when the default master is not a "Regular", which is often the case.

I have a local patch that fixes all this, and am working on tests as well.