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

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

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

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

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.

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

      <!-- 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>

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>

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

And also nameID 25 in the name table.

@thlinard

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?

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

Awesoooome

@tiroj

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?

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.

@tiroj

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.

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).

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.

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.

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!).

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.

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

But Adobe Technical Note states that:

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.

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.

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.

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?

@punchcutter

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

@davelab6

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

@punchcutter

@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

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

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

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.

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.

Navigation Menu

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

4 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

RosaWagner commented on Jan 22, 2021

m4rc1e commented on Jan 22, 2021

m4rc1e commented on Jan 22, 2021

RosaWagner commented on Jan 22, 2021

RosaWagner commented on Jan 22, 2021

RosaWagner commented on Jan 22, 2021

thlinard commented on Jan 22, 2021

davelab6 commented on Feb 12, 2021

m4rc1e commented on Feb 12, 2021

RosaWagner commented on Feb 12, 2021

vv-monsalve commented on Feb 15, 2021

m4rc1e commented on Feb 15, 2021

thlinard commented on Feb 15, 2021

thlinard commented on Feb 15, 2021

thlinard commented on Feb 17, 2021

4 remaining items

tiroj commented on Feb 17, 2021

thlinard commented on Feb 17, 2021

tiroj commented on Feb 17, 2021

khaledhosny commented on Feb 17, 2021

punchcutter commented on Feb 17, 2021

thlinard commented on Feb 17, 2021

tiroj commented on Mar 22, 2021

davelab6 commented on Aug 10, 2021

punchcutter commented on Aug 11, 2021

tiroj commented on Feb 6, 2022

punchcutter commented on Feb 9, 2022

RosaWagner commented on Feb 18, 2022

yanone commented on Jan 16, 2023

arrowtype commented on May 26, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions