Variabe Font issue in Indesign 2020

Rafał Buchner

Hi.
I hope it is the right place to ask for help in this matter:

I have this typeface, that has separate variable font files for Romans and Italics. Both fonts have corresponding named instances and one axis (weight axis).
I installed this font in my adobe font folder to test it in different adobe apps.
Illustrator works smoothly.
But in InDesign I have a problem.

This is what happens:
If I select, for example, "Bold" from the style dropdown and I want to see how the letter shape behaves by dragging the axis slider my font jumps immediately to the italic style.

Does anyone know what to do with this?

I tried to set STAT table, I set default masters' font info from the scratch, I recreated design space files several times. I exported font with makeotf and fontmake separately. With different apps. I still have no clue how does it work for example in SourceSans. I believe that I omitted some important stuff in the spec. I just don't know what exactly.

Here <https://www.dropbox.com/s/2jiznwvr6ucd3r2/TestFont.zip?dl=0&gt; I'm attaching source files and ttf files of my test font that behaves the same. There is also a small video illustrating what is happening.

I lost all my hope,

Thanks in advance

Peter Constable

If it works in Illustrator but not in InDesign, I suspect it's an InDesign bug. You can also try it in Photoshop (supported VFs in the same release as Illustrator); and you could also try using arbitrary instances in a browser. Checkout Axis-Praxis as a way to test it in browsers, and also checkout Samsa to see in detail how the variation delta data in the fonts is behaving.

Rafał Buchner

But how is it possible that, for example, whole Source families are working properly while mine doesn't? It has the same setuf for upright/italic files.
I believe that indesign's VF implementation is "a bit" buggy, but I really want to figure out how other fonts are working and mine is 


Yeah, I tested it all also including FontGoggles, and everything works fine but InDesign.

I also thought that maybe InDesign somehow uses the NAME table in order to address some particular parts of the variable font family. I compared mine NAME table to SourceSans and everything looks similar. I tested small differences in my font and nothing happened.  

Rafał Buchner

Somehow I believe that InDesign could be very conservative in its implementation (more than illustrator and other apps) and maybe it is using some ideas from OpenTypeVF spec that I haven't implemented. Have anyone clue what it might be?

Laurence Penney

Thanks for posting this, Rafał.

One thing I have been recommending is to set postscriptNameID for all fvar Named Instances (along with entries in the name table of course). Your fonts do not have these names, but all the Adobe Source fonts do. I don’t have evidence that this in itself cures the InDesign issues, but I would still recommend it.

Is there anyone from Adobe who can advise on this? It is urgent that all font engineers understand how to get variable font families working in InDesign.

Rafał Buchner

Yeah, I should have added postscriptNameID to my testFont VF linked in previous message. Normally I have postscriptNameID added to the VF

Rafał Buchner

https://www.dropbox.com/s/fwc56u4n9laodcr/version with postscriptNameIDs.zip?dl=0
here is testFont version with postscriptNameIDs. Still doesn't work as expected.

The interesting thing is: I found that this font is working as expected: https://fontsarena.com/fraunces-by-undercase-type/ in InDesign and IBM plex Sans, which is in general well-known font, commissioned by significant tech company doesn't. I posted the issue on IBM Plex's github repo.

https://github.com/IBM/plex/issues/337

Stephen Nixon

Not sure if this would impact InDesign, but it has given me issues in Windows:

Have you checked fsSelection, macStyle, and Panose settings? Maybe also italicAngle?

https://github.com/arrowtype/recursive/issues/373#issuecomment-670071028

Rafał Buchner

I believe it is something connected to the STAT table. I've been experimenting with build.sh for Fraunces. (https://github.com/undercasetype/Fraunces/blob/master/sources/build.sh) and until I left part described as "Fix STAT", everything worked. Now I need to figure out what was wrong with my original STAT table (TestFont doesn't contain it yet, but I will try to make it work).

DanRhatigan

We've got a bug filed against behavior like this, which appears to be connected to InDesign's looking for info in STAT when there are two related fonts in the family. I've asked the engineers to clarify exactly which info they're expecting to see in STAT, since it's happening with other fonts as well.

DanRhatigan

OK, a little more info. There is not a big in InDesign, so much that InDesign is being strict about information needed in the STAT table, very much like we've been discovering with VFs in Windows.

(Rafał, I'm paraphrasing some info that my colleague Zachary just sent you. Please let us know if this worked.)

One requirement is named 25, 

Variations PostScript Name Prefix.

 If you make sure that each font has a unique nameid 25 then that solves one part of the problem. For example:

nameid 25 "MyRoman"; 

and

nameid 25 "MyItalic";

There’s some information in https://wwwimages2.adobe.com/content/dam/acom/en/devnet/font/pdfs/5902.AdobePSNameGeneration.pdfabout this. The code actually does what it says here which is to look for nameid 25 first and then if it doesn’t exist check nameid 16 and then nameid 1. In most cases id 1 will be the same for Roman and Italic so that will cause the conflict you see. It should work if you make sure nameid 16 exists and is unique, but using 25 is the best way to do it and one of the reasons nameid 25 was created.

A list of axis value records in your STAT table is also required, particularly ones that correspond with each font in the family. This is the requirement for things to go smoothly in Windows, too.

Laurence Penney

Thanks a lot for this, Dan.

Thomas Linard

Hi @Rafał Buchner

You can check the discussion I had with Google here:
https://github.com/google/fonts/pull/2550

Roboto 3.002 is made according to my advice.

In short: nameID 25 + postscriptNameID in fvar + AxisValue format 2.

I filled this bug also:
https://indesign.uservoice.com/forums/601021-adobe-indesign-feature-requests/suggestions/40950229-support-variable-fonts-without-stat-axisvalue-form

(the information given in this bug is a bit out of date: since then, FontBakey's gftools-fix-vf-meta.py script creates AxisValue format 2, so new fonts passed through this script like Roboto works in InDesign)

Rafał Buchner

Thanks, Dan. Thanks, Thomas.
Yeah, I applied the unique nameID 25 accordingly to Zachary's directions. That was the cause of the issue in this case. I already had applied postscriptNameIDs to my VF before and  STAT table in format 2. I found it on my own that STAT records in format 1 are crashing slider action.

Thank you again for the swift response.

Thomas Linard

Good. Also, Photoshop 2020 has a similar bug (not Illustrator): nameID 25 + postscriptNameID in fvar is enough to fix it. Only InDesign additionally requires AxisValue format 2.

Thomas Linard

I just received InDesign update 15.1.2: “Font Specific: Variable font does not work properly in InDesign.” https://helpx.adobe.com/indesign/kb/fixed-issues.html

From my first tests nameID 25 + postscriptNameID in fvar is still needed, but AxisValue format 2 is no longer needed.