Family Name error - Githubissues

jeremymickel commented 5 years ago

Observed behaviour

I'm getting name table errors for fonts in a non-RIBBI family.

com.google.fonts/check/name/familyname with RedHatDisplay-Black.ttf Check name table: FONT_FAMILY_NAME entries.

FAIL: Entry [FONT_FAMILY_NAME(1):MACINTOSH(1)] on the 'name' table: Expected 'Red Hat Display' but got 'Red Hat Display Black'.

Result: FAIL

com.google.fonts/check/name/subfamilyname with RedHatDisplay-Black.ttf Check name table: FONT_SUBFAMILY_NAME entries.
FAIL: Entry [FONT_SUBFAMILY_NAME(2):MACINTOSH(1)] on the 'name' table: Expected 'Black' but got 'Regular'. [code: bad-familyname]

Result: FAIL

Expected behaviour

I currently have name tables set up in the FontMenuNameDB as follows, which works correctly for style-linking in non-RIBBI families. Is there another approach which is recommended?

[RedHatDisplay-Regular]
    f=Red Hat Display
    s=Regular

[RedHatDisplay-Italic]
    f=Red Hat Display
    s=Italic

[RedHatDisplay-Bold]
    f=Red Hat Display
    s=Bold

[RedHatDisplay-BoldItalic]
    f=Red Hat Display
    s=Bold Italic

[RedHatDisplay-Medium]
    f=Red Hat Display
    s=Medium
    l=Red Hat Display Medium
    m=1,Red Hat Display Medium

[RedHatDisplay-MediumItalic]
    f=Red Hat Display
    s=Medium Italic
    l=Red Hat Display Medium
    m=1,Red Hat Display Medium Italic

[RedHatDisplay-Black]
    f=Red Hat Display
    s=Black
    l=Red Hat Display Black
    m=1,Red Hat Display Black

[RedHatDisplay-BlackItalic]
    f=Red Hat Display
    s=Black Italic
    l=Red Hat Display Black
    m=1,Red Hat Display Black Italic

Resources and exact process needed to replicate

https://github.com/jeremymickel/RedHat

felipesanches commented 5 years ago

@m4rc1e, can you help us here?

m4rc1e commented 5 years ago

We don't set mac name table records in the same manner has Win. I don't think Mac records need to use nameIDs 16 and 17 (Typographic Family name and Typographic Subfamily name). Idk, if his name table will cause any issues though.

As a ref, here's the name table for Montserrat Black:

id	string
(0, 1, 0, 0)	Copyright 2011 The Montserrat Project Authors (https://github.com/JulietaUla/Montserrat)
(1, 1, 0, 0)	Montserrat
(2, 1, 0, 0)	Black
(3, 1, 0, 0)	7.200;ULA ;Montserrat-Black
(4, 1, 0, 0)	Montserrat Black
(5, 1, 0, 0)	Version 7.200
(6, 1, 0, 0)	Montserrat-Black
(8, 1, 0, 0)	Julieta Ulanovsky
(9, 1, 0, 0)	Julieta Ulanovsky
(11, 1, 0, 0)	http://www.zkysky.com.ar/
(12, 1, 0, 0)	http://www.zkysky.com.ar/
(13, 1, 0, 0)	This Font Software is licensed under the SIL Open Font License, Version 1.1. This license is available with a FAQ at: http://scripts.sil.org/OFL
(14, 1, 0, 0)	http://scripts.sil.org/OFL
(0, 3, 1, 1033)	Copyright 2011 The Montserrat Project Authors (https://github.com/JulietaUla/Montserrat)
(1, 3, 1, 1033)	Montserrat Black
(2, 3, 1, 1033)	Regular
(3, 3, 1, 1033)	7.200;ULA ;Montserrat-Black
(4, 3, 1, 1033)	Montserrat Black
(5, 3, 1, 1033)	Version 7.200
(6, 3, 1, 1033)	Montserrat-Black
(8, 3, 1, 1033)	Julieta Ulanovsky
(9, 3, 1, 1033)	Julieta Ulanovsky
(11, 3, 1, 1033)	http://www.zkysky.com.ar/
(12, 3, 1, 1033)	http://www.zkysky.com.ar/
(13, 3, 1, 1033)	This Font Software is licensed under the SIL Open Font License, Version 1.1. This license is available with a FAQ at: http://scripts.sil.org/OFL
(14, 3, 1, 1033)	http://scripts.sil.org/OFL
(16, 3, 1, 1033)	Montserrat
(17, 3, 1, 1033)	Black

m4rc1e commented 5 years ago

I've looked at the Red Hat fonts in both OSX and Win

OSX

Win

Both are behaving as they should. We can see the non RIBBI styles are selectable in Win and all styles are grouped under the same family in OSX.

When I refactor the name checks, I'll take this issue into consideration.

@jeremymickel no need to do anything.

felipesanches commented 5 years ago

well... I think then that this has just become a P0 issue!

arrowtype commented 4 years ago

I’m still confused on this question, and seeing three different methods in three different places that I would expect to be a "source of truth."

For non-RIBBI styles, e.g. Medium:

Regular on name 2 for both platforms (Roboto-Medium.ttf)
Regular on name 2 for platform 3 (Windows), actual style name (e.g. Medium) on name 2 for platform 1 (Mac), (Montserrat-Medium.ttf)
A mixture: Regular for name 2 of Thin, ExtraLight, Medium, SemiBold, but actual style name for name 2 on Light, ExtraBold, Black (in Marc's WIP spec doc)

What is the best way to do this? Why might Monserrat and Roboto differ on this? Should we treat Windows and Mac name fields differently? Is there a reason the spec recommends a hybrid approach?

arrowtype commented 4 years ago

Just to add some detail here for convenience:

Here’s the relevant excerpt of Roboto Medium:

    <namerecord nameID="1" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Roboto Medium
    </namerecord>
    <namerecord nameID="2" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Regular
    </namerecord>
    <namerecord nameID="1" platformID="3" platEncID="1" langID="0x409">
      Roboto Medium
    </namerecord>
    <namerecord nameID="2" platformID="3" platEncID="1" langID="0x409">
      Regular
    </namerecord>

Here’s the relevant excerpt of Monserrat Medium:

    <namerecord nameID="1" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Montserrat
    </namerecord>
    <namerecord nameID="2" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Medium
    </namerecord>
    <namerecord nameID="1" platformID="3" platEncID="1" langID="0x409">
      Montserrat Medium
    </namerecord>
    <namerecord nameID="2" platformID="3" platEncID="1" langID="0x409">
      Regular
    </namerecord>

Here's from Red Hat Display:

    <namerecord nameID="1" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Red Hat Display Medium
    </namerecord>
    <namerecord nameID="2" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Regular
    </namerecord>
    <namerecord nameID="1" platformID="3" platEncID="1" langID="0x409">
      Red Hat Display Medium
    </namerecord>
    <namerecord nameID="2" platformID="3" platEncID="1" langID="0x409">
      Regular
    </namerecord>

Here’s a discussion of this matter from TypeDrawers. It summarizes what we probably already agree on: on non-RIBBI styles, the benefit of style-linking is so that the "Italic" shortcut works. There isn't really a benefit in trying to make "Bold" style-linking for non-RIBBI styles.

Interestingly, in quick tests of Monserrat and Roboto Thin styles in macOS Text Edit, both have strange Italic style-linking issues. With Montserrat Thin, hitting cmmd+i results in ExtraLight Italic. However, with Roboto Thin, cmd+i will go to Thin Italic, but hitting it again goes to Light. So, maybe there are just issues with either strategy.

My guess is that the AFDKO is setting these name IDs as well as possible and that nameID 2 has to be Regular for Italic style-linking to work properly on non-RIBBI styles (e.g. when someone hits the i button in a writing app while using Fontname Black, they will get Fontname Black Italic). But, it would be good to have this firmly established and correctly reporting in FontBakery checks.

I would still be really interested to know if there is a reason for the hybrid approach described in @m4rc1e's spec. Were there tests that led to that conclusion?

fonttools / fontbakery

Family Name error #2446

Observed behaviour

Expected behaviour

Resources and exact process needed to replicate