Open Sans, Roboto and Roboto Slab NAME table issues in WinWord #1618

davelab6 · 2018-07-16T15:04:38Z

A user wrote to me privately that Open Sans, Roboto and Roboto Slab all have NAME table issues in Windows Word.

Open Sans when installed looks like this to Word:

So far so good.

However, the SemiBold Italic style does not render, instead the SemiBold is auto-slanted (eg the 'a' is not single story)

Similarly, Roboto Slab has 4 styles (Regular + Bold, then Thin and then Light) but only two appear in the Word picker list:

So when a document is made with them in Google Docs and exported as docx, it appears to fall back to Roboto:

I am very keen to see that Font Bakery is checking this stuff and telling people exactly what to do to fix it, and then we ensure everything in the API is fixed. :)

felipesanches · 2018-07-16T18:09:03Z

OK. I'll investigate this.

laerm0 · 2018-07-17T15:51:53Z

Hi –

I can't reproduce this with Open Sans (using the files currently in the repo, not my new files) or Roboto but I can with Roboto Slab.

I'll fix Roboto Slab. I'm surprised nobody has ever noticed this before!

laerm0 · 2018-07-17T16:07:09Z

It looks like @mjlagattuta has just spiffed up Roboto Slab's masters for VF lifestyle so it looks like getting the slab live on site will fix this (and improve other stuff).

felipesanches · 2018-07-17T17:38:10Z

@laerm0 sent me two sets of good and bad fonts. Here's a visual reference of how the name table entries went bad on Roboto:

Roboto Thin (good) versus Roboto Thin (bad)

Roboto Light (good) versus Roboto Light (bad)

Roboto Regular (good) versus Roboto Regular (bad)

Roboto Bold (good) versus Roboto Bold (bad)

davelab6 · 2018-07-17T18:52:27Z

@laerm0

I can't reproduce this with Open Sans (using the files currently in the repo, not my new files)

Did you mean, "using the files currently in the repo, OR my new files"

Also, what versions of win & word did you test? :)

laerm0 · 2018-07-17T19:09:51Z

Sorry, using the files currently in the repo.

I used Win 10 Pro with Office 365.

davelab6 · 2018-07-17T22:54:42Z

In this repo? Or in the API? Not sure they are in sync...

laerm0 · 2018-07-18T13:39:03Z

The files currently in the repo were what I tested, but I just downloaded what's being served again and it's the same as what I saw before: Open Sans and Roboto fine, Roboto Slab not.

mjlagattuta · 2018-07-23T20:38:23Z

In the Roboto Slab VF (which is still in beta) I resolved this via manual edits to the STAT table, which Windows Word seems to rely on. I believe these values need to correspond to the final scale of an axis whether scaling from source file stem weights to CSS weight values and/or mapping via an avar table. The only style not present is "Roboto Slab Beta Bold" which can be accessed via turning on the bold option on the regular style.

felipesanches · 2018-07-30T21:17:21Z

Do we have a succinct description of the rules for good and bad name table entries relevant to the issues discussed here?

felipesanches · 2018-07-30T21:18:39Z

This is currently blocking a Font Bakery release due to fonttools/fontbakery#1974 which should address these problems, but it is not clear to me right now how to deal with it.

felipesanches · 2018-08-29T06:23:18Z

I'd appreciate some more feedback in here, as mentioned at #1618 (comment) above.

felipesanches · 2018-09-29T03:51:59Z

I need someone to take a look at this issue and provide some further feedback, please.

davelab6 · 2018-09-30T18:45:48Z

Do we have a succinct description of the rules for good and bad name table entries relevant to the issues discussed here?

No. Someone must investigate systematically and write those rules, and then write code that checks them.

We have fonts that work, and fonts that do not work, so using fontdiffenator (or even just comparing the TTX output of the OS/2, name and post tables, by hand) should reveal what is going on.

mjlagattuta · 2018-10-01T15:23:07Z

For the name table there are 2–4 entries that really matter and other entries are variations of this. These are entries 1, 2, 16, and 17. nameID 16 and 17 are only necessary if the style of the font does not fall into a RIBBI model. I see 4 possibilities for a font (though it essentially boils down to RIBBI or non-RIBBI):

Static + RIBBI
Static + non-RIBBI
VF + RIBBI
VF + non-RIBBI

For case 1 nameID 1 is the FontFamilyName and should be the "family name with spaces" and nameID 2 should be the respective RIBBI style.

In case 2 nameID 1 would be "family name with spaces" + the style name (i.e. Thin, Light, Medium) and nameID 2 would be either Regular or Italic. In this case nameID 16 and 17 become necessary and should be "famliy name with spaces" and style name (or style name sans Italic) respectively.

I believe case 3 will be the most common for VFs since I don't currently see much use where a family is spread across multiple VFs and needs to make use of non-RIBBI styleNames. This is handled the same way as case 1, with Regular being the most common style name used for nameID 2, and no need for nameID 16 or 17. The instance names and styles of VFs are then accessed via the STAT table

Case 4 would be handled in the same way that case 2 is handled.

For the name tables (on the Windows platform) FontBakery currently has (in the Google Fonts specification) check 156 for the presence of nameID 16 and nameID 17 if the style name does not conform to RIBBI. Check 157 checks that the family name of the font file matches the string at nameID 1 if it conforms to RIBBI and otherwise checks that nameID 1 is the family name + the style name. Check 158 then makes sure that the entries at nameID 2 can only be RIBBI. Checks 161 and 162 check for proper entries at nameID 16 and 17 respectively.

Unless I am not understanding the issue properly, I believe these checks address the above problems.

m4rc1e · 2018-10-01T15:29:15Z

@mjlagattuta Thanks for the write up. We have this info has a spreadsheet

Has anyone been able to verify what this user has found?

mjlagattuta · 2018-10-01T17:08:20Z

Same as @laerm0 I cannot replicate this for Open Sans and Roboto but I can for Roboto Slab. I just ran the four fonts through FontBakery. Checks 157 and 158 yielded FAIL for both Roboto Slab Light and Roboto Slab Thin and suggested the correct name string that was expected, so it would seem FontBakery is successfully detecting these name table errors

m4rc1e · 2018-10-01T17:26:06Z

Thanks for looking into this.

felipesanches · 2018-10-01T21:00:42Z

The implementation of com.google.fonts/check/156 is correct indeed, but its code-test was not, so I have just fixed it at felipesanches/fontbakery@4fa6cef

davelab6 · 2018-10-02T00:23:59Z

Great! So then the next issue I see on FB relevant to this is that those checks should be given a ultra high priority, as it's really really important to get those right, and for the dashboard to make it clear where we are in getting everything sorted on this regard

felipesanches · 2018-10-02T00:27:07Z

I am reviewing the other checks. They seem to be correctly implemented as well, but lack code-tests, so I am working on it right now.

felipesanches · 2018-10-04T04:00:18Z

felipesanches/fontbakery@22fea7d fixes checks 157 and 158. It also implements code-test for check/157.

felipesanches · 2018-10-24T06:41:03Z

@mjlagattuta, at #1618 (comment) you said:

Check 158 then makes sure that the entries at nameID 2 can only be RIBBI.

But reading the current implementation of check/158 I see:

  for name in ttFont['name'].names:
    if name.nameID == NameID.FONT_SUBFAMILY_NAME:
      if style_with_spaces not in STYLE_NAMES:
        yield FAIL, ("Style name '{}' inferred from filename"
                     " is not canonical."
                     " Valid options are: {}").format(style_with_spaces,
                                                      STYLE_NAMES)
        failed = True
        continue

and at constants.py we have STYLE_NAMES declared as:

STYLE_NAMES = ["Thin",
               "ExtraLight",
               "Light",
               "Regular",
               "Medium",
               "SemiBold",
               "Bold",
               "ExtraBold",
               "Black",
               "Thin Italic",
               "ExtraLight Italic",
               "Light Italic",
               "Italic",
               "Medium Italic",
               "SemiBold Italic",
               "Bold Italic",
               "ExtraBold Italic",
               "Black Italic"]

So that's defnitely not RIBBI-only...

Can you review that comment, please?

mjlagattuta · 2018-10-24T14:52:42Z

That portion of code only checks to make sure that the style name is canonical.

I believe my comment on the check was in reference to this snippet that is just below the one you referenced:

      if name.platformID == PlatformID.MACINTOSH:
        expected_value = style_with_spaces

      elif name.platformID == PlatformID.WINDOWS:
        if style_with_spaces in ["Bold", "Bold Italic"]:
          expected_value = style_with_spaces
        else:
          if "Italic" in style:
            expected_value = "Italic"
          else:
            expected_value = "Regular"
      else:
        yield FAIL, ("Font should not have a "
                     "{} entry!").format(name_entry_id(name))
        failed = True

After checking that the style name is canonical then this checks that anything that is not Bold, Bold Italic, or Italic should be Regular

I think this is correct for checking static fonts, but for Variable fonts, it is not, since we may want to differentiate between the font's default outlines and the regular instance (if those two things are not the same). As an example, Comfortaa VF, has a font subfamily name of "Light" in reference to its default outlines, which ensures that the instances in dropdowns on Mac do not display two "Regulars".

felipesanches · 2018-10-26T15:16:41Z

The test case describes by example the expected behaviour:
https://github.com/felipesanches/fontbakery/blob/1f0c81a4c938ef87045cb5d5aca9c47d9b9a95cd/tests/specifications/googlefonts_test.py#L2080-L2104

Spherikal · 2019-02-20T16:03:34Z

Did this ever get a solution? I still can't use Roboto Slab in Word...

julieyunt · 2019-04-15T18:19:18Z

Also can't use Roboto Slab - regular in Word Office 2016 (on a PC) It reverts to Roboto Slab - Light.
How do we get this fixed.
Staff member said it works fine on their Mac or Word online. Haven't verified.

davelab6 added the Priority 0 - Urgent and Important label Jul 16, 2018

davelab6 added this to the Bugs in Font Files 01 Requires Upstream Resolution milestone Jul 16, 2018

davelab6 assigned m4rc1e and laerm0 Jul 16, 2018

davelab6 mentioned this issue Jul 16, 2018

Double check NAME table checks are working correctly, using Open Sans, Roboto, Roboto Slab fonttools/fontbakery#1974

Closed

davelab6 assigned mjlagattuta Jul 16, 2018

felipesanches mentioned this issue Oct 1, 2018

WIP: reviewing and fixing some pending issues related to the name table rules fonttools/fontbakery#2066

Merged

felipesanches mentioned this issue Oct 26, 2018

implementing code-tests for check/158 (NameID.FONT_SUBFAMILY_NAME) fonttools/fontbakery#2130

Merged

julieyunt unassigned mjlagattuta Apr 15, 2019

RosaWagner added the -- Needs Upstream Resolution Upstream fix required before moving forward label Aug 13, 2021

RosaWagner removed this from the Bugs in Font Files 01 Requires Upstream Resolution milestone Aug 13, 2021

RosaWagner removed the Priority 0 - Urgent and Important label Oct 15, 2021

RosaWagner added the I Font Bug label Nov 18, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Open Sans, Roboto and Roboto Slab NAME table issues in WinWord #1618

Open Sans, Roboto and Roboto Slab NAME table issues in WinWord #1618

davelab6 commented Jul 16, 2018

felipesanches commented Jul 16, 2018

laerm0 commented Jul 17, 2018

laerm0 commented Jul 17, 2018

felipesanches commented Jul 17, 2018

davelab6 commented Jul 17, 2018 •

edited

Loading

laerm0 commented Jul 17, 2018

davelab6 commented Jul 17, 2018 via email

laerm0 commented Jul 18, 2018

mjlagattuta commented Jul 23, 2018 •

edited

Loading

felipesanches commented Jul 30, 2018

felipesanches commented Jul 30, 2018 •

edited

Loading

felipesanches commented Aug 29, 2018

felipesanches commented Sep 29, 2018

davelab6 commented Sep 30, 2018

mjlagattuta commented Oct 1, 2018

m4rc1e commented Oct 1, 2018

mjlagattuta commented Oct 1, 2018

m4rc1e commented Oct 1, 2018

felipesanches commented Oct 1, 2018

davelab6 commented Oct 2, 2018 via email

felipesanches commented Oct 2, 2018 •

edited

Loading

felipesanches commented Oct 4, 2018

felipesanches commented Oct 24, 2018

mjlagattuta commented Oct 24, 2018

felipesanches commented Oct 26, 2018 •

edited

Loading

Spherikal commented Feb 20, 2019

julieyunt commented Apr 15, 2019 •

edited

Loading

Open Sans, Roboto and Roboto Slab NAME table issues in WinWord #1618

Open Sans, Roboto and Roboto Slab NAME table issues in WinWord #1618

Comments

davelab6 commented Jul 16, 2018

felipesanches commented Jul 16, 2018

laerm0 commented Jul 17, 2018

laerm0 commented Jul 17, 2018

felipesanches commented Jul 17, 2018

davelab6 commented Jul 17, 2018 • edited Loading

laerm0 commented Jul 17, 2018

davelab6 commented Jul 17, 2018 via email

laerm0 commented Jul 18, 2018

mjlagattuta commented Jul 23, 2018 • edited Loading

felipesanches commented Jul 30, 2018

felipesanches commented Jul 30, 2018 • edited Loading

felipesanches commented Aug 29, 2018

felipesanches commented Sep 29, 2018

davelab6 commented Sep 30, 2018

mjlagattuta commented Oct 1, 2018

m4rc1e commented Oct 1, 2018

mjlagattuta commented Oct 1, 2018

m4rc1e commented Oct 1, 2018

felipesanches commented Oct 1, 2018

davelab6 commented Oct 2, 2018 via email

felipesanches commented Oct 2, 2018 • edited Loading

felipesanches commented Oct 4, 2018

felipesanches commented Oct 24, 2018

mjlagattuta commented Oct 24, 2018

felipesanches commented Oct 26, 2018 • edited Loading

Spherikal commented Feb 20, 2019

julieyunt commented Apr 15, 2019 • edited Loading

davelab6 commented Jul 17, 2018 •

edited

Loading

mjlagattuta commented Jul 23, 2018 •

edited

Loading

felipesanches commented Jul 30, 2018 •

edited

Loading

felipesanches commented Oct 2, 2018 •

edited

Loading

felipesanches commented Oct 26, 2018 •

edited

Loading

julieyunt commented Apr 15, 2019 •

edited

Loading