[builder] Roman/Italic variation issue in Indesign when stat in config.yaml

[RosaWagner]

The italic is going back to roman when using the weight slider in Indesign — but only when there is the stat in the config.yaml.

texturina-italicissue.mov

These are my different test:

• When exported as we use too ie. with gen-stat.py + build.sh : no issue
  See: https://github.com/RosaWagner/Texturina/tree/master/fonts/variable
• When exported with builder + stat entry in config.yaml : issue
  See: https://github.com/RosaWagner/Texturina/tree/master/fonts-builder/variable
• When standard font exported with builder without stat entry in config.yaml: no issue
  See: https://github.com/RosaWagner/Archivo/tree/master/fonts/variable

[RosaWagner]

This is the config.yaml, maybe I am missing something:

    sources:
      - Texturina.glyphs
      - Texturina-Italic.glyphs
    axisOrder:
      - opsz
      - wght
    outputDir: "../fonts-builder"
    familyName: Texturina
    buildStatic: false
    stat:
      Texturina[opsz,wght].ttf:
      - name: Optical size
        tag: opsz
        values:
        - name: 12pt
          value: 12
          flags: 2
        - name: 72pt
          value: 72
      - name: Weight
        tag: wght
        values:
        - name: Thin
          value: 100
        - name: ExtraLight
          value: 200
        - name: Light
          value: 300
        - name: Regular
          value: 400
          linkedValue: 700
          flags: 2
        - name: Medium
          value: 500
        - name: SemiBold
          value: 600
        - name: Bold
          value: 700
        - name: ExtraBold
          value: 800
        - name: Black
          value: 900
      - name: Italic
        tag: ital
        values:
        - name: Roman
          value: 0
          linkedValue: 1
          flags: 2
      Texturina-Italic[opsz,wght].ttf:
      - name: Optical size
        tag: opsz
        values:
        - name: 12pt
          value: 12
          flags: 2
        - name: 72pt
          value: 72
      - name: Weight
        tag: wght
        values:
        - name: Thin
          value: 100
        - name: ExtraLight
          value: 200
        - name: Light
          value: 300
        - name: Regular
          value: 400
          linkedValue: 700
          flags: 2
        - name: Medium
          value: 500
        - name: SemiBold
          value: 600
        - name: Bold
          value: 700
        - name: ExtraBold
          value: 800
        - name: Black
          value: 900
      - name: Italic
        tag: ital
        values:
        - name: Italic
          value: 1

[m4rc1e]

Thanks for the detailed issue.

What happens if you ttx the stat tables then diff them?

ttx -t 'STAT' path/to/good_font.ttf
ttx -t 'STAT' path/to/bad_font.ttf

vimdiff path/to/good_font.ttx path/to/bad_font.ttx // use whatever differ you like

[m4rc1e]

Perhaps the issue doesn't involve the STAT, maybe it's the fvar instances. Both the auto stat and your gen-stat script will update the fvar instances so they include postscript names, https://github.com/RosaWagner/Texturina/blob/master/sources/gen_stat.py#L81-L95

Instead of just dumping the 'STAT' also do the 'fvar' so, ttx -t "'STAT" -t "fvar" font.ttf then diff.

[RosaWagner]

in fvar table, in each instances, there is no Postscript name line in the bad file

[RosaWagner]

      <!-- SemiBold Italic -->          |      <!-- SemiBold Italic -->                                              
      <!-- PostScript: TexturinaItalic-S|      <NamedInstance flags="0x0" subfamilyNameID="263">                     
      <NamedInstance flags="0x0" postscr|  --------------------------------------------------------------------------
        <coord axis="wght" value="600.0"|        <coord axis="wght" value="600.0"/>                                  
        <coord axis="opsz" value="12.0"/|        <coord axis="opsz" value="12.0"/>                                   
      </NamedInstance>                  |      </NamedInstance>

[RosaWagner]

With better view of 1st column

      <!-- Thin -->                                                                     |      <!-- Thin -->                                                                    
      <!-- PostScript: TexturinaRoman-Thin -->                                          |      <NamedInstance flags="0x0" subfamilyNameID="258">                                
      <NamedInstance flags="0x0" postscriptNameID="271" subfamilyNameID="258">          |  -------------------------------------------------------------------------------------
        <coord axis="wght" value="100.0"/>                                              |        <coord axis="wght" value="100.0"/>                                             
        <coord axis="opsz" value="12.0"/>                                               |        <coord axis="opsz" value="12.0"/>                                              
      </NamedInstance>                                                                  |      </NamedInstance>  

[thlinard]

Last time I checked, InDesign still needed postscriptNameID (and Photoshop too) (cf. google/fonts#2391 (comment)).

And also nameID 25 in the name table.

[davelab6]

Thanks @thlinard. So, @m4rc1e, can you update the builder to ensure those 2 pieces of data are always included, and @felipesanches please can you add a fontbakery FAIL check if they aren't found?

[m4rc1e]

Fine by me, I'll add it next week.

[RosaWagner]

Awesoooome

[vv-monsalve]

In conversation in a still private project, @tiroj commented:

Zachary Scheuren at Adobe took a look at the v2.10 STIX variable fonts, and thinks the InDesign issue with the italic font is probably due to the absence of a name table ID 25 in the font. It turns out InDesign’s algorithm expects the name ID 25, based on their (mis)interpretation of Adobe Technical Note #5902. This is a known issue at Adobe, and there’s an open bug issue against InDesign’s algorithm.

We could work around the issue by adding a name ID 25 entry to the STIX variable fonts, but I get the impression that Zachary would prefer us not to, and when the v2.12 fonts go public he would log them as additional evidence of InDesign getting it wrong.

I see the point in providing cases to support the resolution of this at Adobe's applications level, nevertheless, this would imply to publish fonts that would bug in Indesign and therefore in the meanwhile probably to receive many complaints about it.
What would you say @davelab6?

[m4rc1e]

Personally, I would like Indesign to work without the need for us to add fvar postscript instance names and nameID 25. However, our module stat.py can already generate these names, https://github.com/googlefonts/gftools/blob/main/Lib/gftools/stat.py#L260-L290 so adding it isn't such a big deal, just requires some rewiring.

[thlinard]

In conversation in a still private project, @tiroj commented:

Zachary Scheuren at Adobe took a look at the v2.10 STIX variable fonts, and thinks the InDesign issue with the italic font is probably due to the absence of a name table ID 25 in the font. It turns out InDesign’s algorithm expects the name ID 25, based on their (mis)interpretation of Adobe Technical Note #5902. This is a known issue at Adobe, and there’s an open bug issue against InDesign’s algorithm.
We could work around the issue by adding a name ID 25 entry to the STIX variable fonts, but I get the impression that Zachary would prefer us not to, and when the v2.12 fonts go public he would log them as additional evidence of InDesign getting it wrong.

I see the point in providing cases to support the resolution of this at Adobe's applications level, nevertheless, this would imply to publish fonts that would bug in Indesign and therefore in the meanwhile probably to receive many complaints about it.
What would you say @davelab6?

The nameID 25 issue in InDesign is not new, I doubt that more proof is needed. I'd drawn Marc's attention to this problem in June 2020 (moreover, the description of the problem is incomplete, adding nameID will not be enough, you also need postscriptNameID to the NamedInstance of the fvar table).

I would add that, although I can understand someone wanting to do without this complication by Adobe (which is not necessary for Illustrator, for example, but it seems the development teams don't speak to each other at Adobe), but in view of the speed at which Adobe fixes its bugs in InDesign, it's better to continue to implement it. Anyway, it looks like @davelab6 agrees.

[thlinard]

BTW, FYI, Cascadia Code release 2102.03 implemented a workaround for Word for Mac:

• nameID1: unchanged ("Cascadia Code"")
• nameID2: unchanged ("Regular"")
• nameID4: changed (from "Cascadia Code Regular" to "Cascadia Code")
• nameID6: changed (from "CascadiaCode-Regular" to "CascadiaCode-Roman")
• nameID16: none
• nameID17: added ("Roman")
• nameID25: added ("CascadiaCodeRoman")

With this change, nameID 4 + 17 = nameID 6 = nameID 25 (in the variation of a space or a hyphen).

It doesn't seem enough, but after discussing it with Aaron Bell, he thinks this is the right thing to do to prepare for the Word for Mac fix that should arrive this month (which should allow using VFs in Word for Mac, which isn't possible currently).

[thlinard]

Hi,

I tested Office for Mac version 16.46 (February 2021 update) today (not sure if there is the same patch for Office for Windows). According to my tests (dummy fonts with fake nameID), the implementation is a mix between the fvar and STAT tables: the named instances are the fvar.NamedInstance but their names are not extracted from their subfamilyNameID, but are built from the ValueNameID attached to the STAT.AxisValue.

The results are quite… surprising, and sometimes gives the same result as the subfamilyNameIDs, but sometimes not…

For example, Word lists the following styles for Literata:

• 12 pt Light
• 12 pt Light Italic
• 12 pt
• 12 pt Italic
• 12 pt Medium
• 12 pt Medium Italic
• 12 pt Bold
• 12 pt Bold Italic
• 12 pt Bold
• 12 pt Bold Italic
• 12 pt ExtraBold
• 12 pt ExtraBold Italic

(I believe the double Bold entries are caused by the lack of STAT.AxisValue corresponding to the fvar.NamedInstance of the SemiBold.)

For older VFs (first VFs released by Google Fonts, with buggy STAT table), the fonts are completely unusable (text and font name completly garbled).

TL;DR: nameID 25 isn't necessary for the new VF implementation by Office for Mac.

[tiroj]

What we’re finding is that the format of fvar postScriptNameID that resolves the confusion of variable family handling in InDesign is actually contrary to normal PS name conventions, in that it requires making each variable font its own family, so e.g.

STIXTwoText-MediumItalic

(which follows the spec for name ID 6 and corresponds directly to the name ID 6 in the static font family) does not affect the InDesign behaviour, but

STIXTWOTextItalic-Medium

does. This means that InDesign not only requires fvar postScriptNameID entries, but requires them to be malformed.

@khaledhosny and I suspect that what it actually happening is that InDesign does not actually require the fvar postScriptNameID entries to be present, and probably is following Adobe’s tech note on name generation, but the names that process produces are causing a problem because of an underlying bug in InDesign’s code that conflates Family and Font and is unable to distinguish between different variable fonts being part of the same family: hence the behaviour in which the italic variable font falls back to the regular variable font when an intermediate instance is selected via the UI slider.

So this seems not simply a matter of an incorrect assumption about the needed presence of what the OT spec identifies as optional data, that we may decide as an industry to work around by providing the data, but an actual bug in InDesign’s underlying code that we would be foolish to work around since the data that would require breaks the normal rules for constructing PS font names, makes fvar postScriptNameID entries incompatible with the static font PS name ID 6 entries that they are supposed to mirror, and which could have unforeseen consequences in other environments.

[thlinard]

What we’re finding is that the format of fvar postScriptNameID that resolves the confusion of variable family handling in InDesign is actually contrary to normal PS name conventions, in that it requires making each variable font its own family, so e.g.

STIXTwoText-MediumItalic

(which follows the spec for name ID 6 and corresponds directly to the name ID 6 in the static font family) does not affect the InDesign behaviour, but

STIXTWOTextItalic-Medium

does. This means that InDesign not only requires fvar postScriptNameID entries, but requires them to be malformed.

Yes, the part before the hyphen must be equal to nameID 25, and, we agree on that, this is not the normal rules for constructing PS font names.

@khaledhosny and I suspect that what it actually happening is that InDesign does not actually require the fvar postScriptNameID entries to be present, and probably is following Adobe’s tech note on name generation, but the names that process produces are causing a problem because of an underlying bug in InDesign’s code that conflates Family and Font and is unable to distinguish between different variable fonts being part of the same family: hence the behaviour in which the italic variable font falls back to the regular variable font when an intermediate instance is selected via the UI slider.

So this seems not simply a matter of an incorrect assumption about the needed presence of that the OT spec identifies as optional data, that we may decide as an industry to work around by providing the data, but an actual bug in InDesign’s underlying code that we would be foolish to work around since the data that would require breaks the normal rules for constructing PS font names, makes fvar postScriptNameID entries incompatible with the static font PS name ID 6 entries that they are supposed to mirror, and which could have unforeseen consequences in other environments.

Of course InDesign is bugged! Illustrator works correctly without that! But the workaround is not "foolish": without it, the fonts don't work. So you can get into a show of strength with Adobe and wait and see who gives in first, but in the meantime, it's the users who suffer.

[tiroj]

Yes, users suffer because of bugs, and the way to stop their suffering is to fix the bugs. Sorry, but I have a long experience of the unintended consequences of font makers working around bugs and of bugs hence become de facto undocumented standards that then can never be fixed.

[thlinard]

Yes, users suffer because of bugs, and the way to stop their suffering is to fix the bugs. Sorry, but I have a long experience of the unintended consequences of font makers working around bugs and of bugs hence become de facto undocumented standards that then can never be fixed.

This story is well known. But has the show of "strength" by font designers ever changed software vendors' minds?

[tiroj]

I don’t think it is a matter of a contest of strength. Adobe have always needed help implementing OpenType: I and others have had to explain a lot of things to various product groups at Adobe over the years, very often with the encouragement of Adobe’s own type group. It has never been helped by font makers rushing to work around the bugs. InDesign CC now pushes updates so frequently, that there isn’t the old excuse that bug fixes will take too long to propagate.

[thlinard]

I also think that if you can communicate with the InDesign development team, that's what will give the best results (and if, at the same time, you could point out to them that the interface of OpenType features in the Character panel tab, which has not changed for 20 years, is a bit dated, and that they could usefully take inspiration from which was made for a product named Photoshop – maybe they heard about it –, that will be good!).

[tiroj]

I am in touch with an InDesign product manager about this issue. The InDesign developers obviously understand font families when it comes to static fonts, so I am not unhopeful that that they will be able to understand families when it comes to variable fonts.

[khaledhosny]

Yes, the part before the hyphen must be equal to nameID 25

But Adobe Technical Note states that:

2. Otherwise create the family prefix as follows:
   a. Start with the US English string for typographic family name (name ID 16).
   b. Remove any characters other than ASCII-range uppercase Latin letters, lowercase Latin letters, and digits.

Since this is the name ID 25 replacement, it follows that name ID 25 should be the same as the family name, i.e. STIXTwoText for both Roman and Italic fonts, not STIXTwoTextRoman and STIXTwoTextItalic.

[punchcutter]

We (Adobe) have an open issue about this about making InDesign act like Illustrator. I'll add a link to this thread and all the others I can find since this seems to keep coming up over and over.

[thlinard]

We (Adobe) have an open issue about this about making InDesign act like Illustrator. I'll add a link to this thread and all the others I can find since this seems to keep coming up over and over.

Photoshop should be included as well. Before version 15.1.2, InDesign also requested AxisValue in format 2 only, but it has been fixed since then. According to my last tests, Photoshop and InDesign now have roughly the same behavior (need nameID 25 and postScriptNameID if we want things to go pretty well).

So if you could inform the Photoshop development team as well, that would be great.

[tiroj]

In the STIX Two Text variable fonts (v2.12 going live probably some time today), we found we could obtain correct behaviour in InDesign by only providing name ID25 entries: we didn’t need to also add the fvar postScriptNameID. I am wondering if this is because these fonts have only a single, weight axis?

[davelab6]

@punchcutter I'm curious if you have any updates on this :)

[punchcutter]

@davelab6 Nothing to report, but it hasn't been forgotten. I pinged the team again on your behalf.

[tiroj]

@punchcutter Any update on this Zachary? I am wondering if this or similar name issue might also be playing a role in this InDesign variable font printing issue reported by Kris Sowersby that only affects some fonts:
https://typedrawers.com/discussion/4330/indesign-prints-courier-instead-of-vf

[punchcutter]

Nothing meaningful to report right now, but we are engaged with the InDesign team about all of this.

[RosaWagner]

As Khaled mentioned in #297 (comment), a nameID25 with the font name only should be sufficient.

But last testing was not conclusive, nameID25 of the Roman and the Italic still need to be different. But the good news that we didn't know is that the case of having "FontName" and "FontNameItalic" works. We could upgrade gftools to stop generating a "Roman" particule to the upright's nameID25.

I just tested this and attach the test case here.
nameID25-test.zip

[yanone]

I just checked with the zip file posted above in the latest Indesign (18.1):

Roman and Italic with identical name ID 25: Italic doesn't even show up (Font2).
Roman and Italic with different name ID 25: It works (Font).

So, nothing changed.

[arrowtype]

Just commenting to say this is still a problem, and it is also a related problem in Illustrator.

https://typo.social/@arrowtype/110430680157544757

Luckily, the workaround seems to fix the font in both apps.