Floor

@dcarvalho84 Thanks for the kind words and helping with support 😆 much appreciated! @deepblue If you have any questions about Typeface app just let me know. But let's not get off-topic too much here, the original post is about fonts on Windows

Thanks! Confirmed working in beta 2.6.0.2805

Ahh thanks for the info! Wasn't aware of the different default gamma values, unexpected but interesting. Cheers!

Not sure if I'm doing something wrong here, but it looks like text color is rendered incorrectly when setting opacity < 100% on a text layer. Opacity seems to be calculated correctly when making a parent group transparent. Attached a simple test case: no background - layers 50% opacity - ok no background - group 50% opacity - ok white background - layers 50% opacity - incorrect? white background - group 50% opacity - ok All fill colors are set to black so I expect 50% opacity to become rgb(128,128,128). However the color of the text becomes rgb(161,161,161) when using 50% opacity. Affinity Designer 2.5.3 - macOS Sonoma 14.5 text-opacity.afdesign

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

Both XOPQ and CTST axes are not hidden in the trial font Pappardelle-VF.ttf

SF Pro from Apple is a variable font with a hidden Width (wdth) axis. https://developer.apple.com/fonts/ It shows up correctly in 2.5.0 (2449) (macOS) and enabling 'Show Hidden Axes' reveals the Width axis.

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.

Fonts may define their own display name for variable axes. They're included in the Name table. But the list from Google should be a good general fallback. Note that only lowercase axis ids are official according to the spec. The uppercase ids are vendor specific, so in theory a particular axis could have a different name/meaning depending on the font.

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.

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.

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

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: Activate variable Roboto Flex in a font manager Open a blank document in Affinity Designer 2.5.0 Add a text block and use Roboto Flex Adjust the weight axis to 415 (this doesn't match with any named instance) Save and close the document Deactivate the variable Roboto Flex in a font manager Reopen the document => 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.

Those axes are marked as hidden in Roboto Flex. According to the spec: "If this flag is set, the axis should not be exposed to users in application user interfaces except in specialized scenarios, such as a font inspection utility." Although it's a bit strange that Google does show all axes on their own type tester page: https://fonts.google.com/specimen/Roboto+Flex/tester?query=roboto+flex edit: see above posts

Fix confirmed on Beta 2.4.2-2356 — thanks!