Missing variable fonts are not requested on macOS

[Floor]

Affinity Designer/Publisher/Photo Beta 2.5.0 (2415)

When opening a document which uses fonts Affinity Designer tries to load the fonts to display them. The fonts may be missing (deactivated), in that case macOS implicitly sends a font request to external applications, such that font managers can automatically provide the missing fonts if they're available. 

This works correctly for static fonts and variable fonts that use one of the named presets. For example when using the variable RobotoFlex-Regular in a document (without changing any variable parameters) Affinity will correctly request RobotoFlex-Regular on reopen.

If any of the parameters of a variable font is changed, such that it doesn't match with any of the named instances, then the Affinity apps do not send a font request. This means that font managers do not have the opportunity to auto activate the missing variable fonts.

For example:

1. Activate variable Roboto Flex in a font manager 
2. Open a blank document in Affinity Designer 2.5.0
3. Add a text block and use Roboto Flex
4. Adjust the weight axis to 415 (this doesn't match with any named instance)
5. Save and close the document
6. Deactivate the variable Roboto Flex in a font manager
7. Reopen the document
8. => Font is missing (expected), but also no font request is sent so the font cannot be auto activated by macOS

It's a bit hard to verify/reproduce this, as the font request happens behind the scenes in macOS and you need a font manager to capture this request. Font requests are typically sent automatically when a font is loaded using an NSFontDescriptor. For example loading a font using a descriptor with a font name NSFontDescriptor(fontAttributes: [ .name: "RobotoFlex-Regular" ]) will look for any available font with that name. It seems like Affinity loads a font differently when axes are adjusted. (Note that this only applies to missing, deactivated fonts. Activated fonts are correctly loaded on document reopen.)

If any additional information is needed I'm happy to help.

[walt.farrell]

It has been reported elsewhere that on Mac, any change to the Variation axes immediately causes the Font Manager to list the font as Missing. Possibly because the font name is changed.

Perhaps what you're reporting is related to this. For example, perhaps the activation request is made, but using that changed font name?

[Floor]

It could be related, but I would indeed expect a font request for the changed font name. Instead no request is received at all.

[walt.farrell]

28 minutes ago, Floor said:

Instead no request is received at all.

Just curious: how have you verified that?

[Floor]

I'm the developer of Typeface app — a font manager for macOS

The app listens for font requests using macOS APIs. Static font requests and variable named instances come through, but when an axis is changed there is no request.

[kenmcd]

14 hours ago, Floor said:

I'm the developer of Typeface app — a font manager for macOS

The app listens for font requests using macOS APIs. Static font requests and variable named instances come through, but when an axis is changed there is no request.

I am curious - what does this request look like in InDesign? How is the variable font identified? By what name?

[Floor]

I believe InDesign uses custom font loading. Fonts are typically identified by their PostScript name. It doesn't really matter how to identify a particular instance of a variable font, as the variable axes are applied after loading the font file.

[kenmcd]

5 hours ago, Floor said:

Fonts are typically identified by their PostScript name.

Thanks.

They have been requiring a unique nameID 25 PostScript Name Prefix be present in variable fonts. All the Source font families are an example. So I am wondering exactly why and how they are using that.

The Google Fonts folks think it (that non-standard requirement) is basically a bug. And they have reservations about requiring it.

But I have seen font developers including it for ID compatibility.

So just wondering if it has any bearing in Affinity variable support.

Thanks again. 

[Floor]

17 minutes ago, kenmcd said:

They have been requiring a unique nameID 25 PostScript Name Prefix be present in variable fonts.

Who's they? Adobe?

I honestly don't know the ins and outs of the spec, but as far as I understand nameID 25 is optional. A type designer can also add a custom PostScript name to each variable instance in fvar. Then nameID 25 isn't used (for those named instances). This is the most straightforward in my opinion, you can directly identify a named instance by its custom PostScript name. Adobe has a spec that defines how a PostScript name should be constructed if there is no custom one (and for custom axes values), but all this doesn't (shouldn't?) really matter for Affinity.

I have no knowledge of the internals of Affinity, but this is how I expect it to work: Affinity loads available fonts on launch. This list is given by macOS. Each font in the list has a PostScript name, as provided by macOS. When a user uses a font its PostScript name is written to the document. When the document is reopened Affinity asks macOS for the font with the saved PostScript name. Variable axes don't matter, because those are applied on top of the loaded font. Affinity doesn't have to construct any PostScript names in this case.

InDesign might store the constructed PostScript name in their document. Such that it can identify the exact var axes, for example: RobotoFlex_20.000slnt_372.000wght.

[kenmcd]

6 hours ago, Floor said:

Who's they? Adobe?

Yes. Adobe for InDesign.

The way they want nameID 25 used for variable fonts does not follow the spec.
Hence the concern by other fonts vendors.

Also, from some of the InDesign PDFs posted here in the forum it appears Adobe does not follow their own guidance regarding embedded font names for variable fonts (from Adobe Technical Note #5902 - Generating PostScript Names for Fonts Using OpenType Font Variations).
And it appears they save the variable font settings in an encrypted "roundtrip" section (which they created and is not a part of the PDF spec).

Anyway. This detour is not helping answer your initial issue. My apologies.

Hope the Affinity folks get back to you soon about your issue.
 

[Floor]

Not sure if this is tracked, but just FYI: the issue is still present in RC1 2.5.0.2463

[walt.farrell]

2 hours ago, Floor said:

Not sure if this is tracked, but just FYI: the issue is still present in RC1 2.5.0.2463

There is certainly no bug tag on this topic yet, so it may not yet be known to Serif.

[Jon P]

Hi @Floor,

I've reproduced this and have logged it for the developers to investigate further.

Thanks for the report

[Affinity Info Bot]

An issue raised in this thread ("Missing variable fonts not requested if font parameters are changed") has now been reported to the developers by the testing team (Ref: AF-3124). Thank you very much for reporting this issue to us.