Rendering issues of variable fonts in Affinity Publisher

[Colin-Fredericks]

Hello! I ran into an issue with Newsreader recently. I'm not sure what the issue is, precisely, but I can show you what the effects are.

https://pbs.twimg.com/media/FEz4-0QWYAgG4bQ?format=png&name=small

That's a set of screenshots from Word, TextEdit, and Affinity Publisher, overlaid with some transparency. It's literally the text:

Newsreader Times

in those fonts, 72-point, with one carriage return between them. The vertical offset issue is real and not an artifact of my image editing. Affinity Publisher is the farthest off, but even Word and TextEdit don't agree.

Like I said, I don't know what the technical issues are behind the scenes, but it makes the font practically unusable in Publisher.

[productiontype]

Hi! This is due to varying settings of vertical metrics across the various optical sizes. Unlike Times New Roman, Newsreader has different designs gathered as sub-families. Normalizing those values is not possible atm, and possibly counter-effective.

[Colin-Fredericks]

I get what you're saying, but counter-effective is not how I'd put it.

Here's a side-by-side comparison of how Newsreader looks when it's displayed in-app, and how it looks when you render to PDF. The way it look in-app is so bad that I would consider it unusable as a font. I find it difficult to even work with on-screen.

The kerning doesn't match, and even the shapes of some of the letters don't match. I don't think this is how you want your font to work.

[productiontype]

Interesting. The app is apparently displaying the outlines of a given optical size with the metrics of another size. Not sure this can be fixed at the font level though, looks like an app support issue to me. Have you considered reporting there?

[verdy-p]

The line-spacing may depend on other styles rather than being a font issue: a carriage return alone may add a visual paragraph container with extra margins, instead of being a line-break. For proper settings, you should better enable automatic linewrap, not use any carriage return or linefeed, and then set the two horitontal margins for the actual display width (as well beware of optional features that may be enabled or not in the application or renderer, like kerning, or about alignment styles like justification (left/right/center positioning should be fine, but center allows easier tests to compare how glyphs in the same word are aligned), which may change the distance between glyphs, instead of just using their default left and right bearings. Some apps also adjust inline whitespaces (so you should test with text containing no whitespaces at all).

Also if you can, properly set the line-height (its default may vary across applications) and the block margins, and avoid mixing fonts and styles in the same block of text (also because of adjustment of baselines and other vertical metrics), even if all the embedded content is inline text.

[kenmcd]

Interesting. The app is apparently displaying the outlines of a given optical size with the metrics of another size. Not sure this can be fixed at the font level though, looks like an app support issue to me. Have you considered reporting there?

This can be closed. The issue was resolved in the Affinity forum. User was using the variable fonts. Affinity applications do not yet support variable fonts. The issue was resolved by using the static fonts instead.

[verdy-p]

Note however that if you have ever installed any "variable" fonts from Noto in Windows, you may have issues with these variable fonts being used to replace static fonts. When you uninstall these varaible fonts, Windows still maintains a cache with the mapping from the static font names, and it won't use the static fonts even if they are installed. This is a bug inside Windows (including latest version of Windows 11 and in the Dev channel).

I found no way to flush these incorrect font mappings, whose origin comes from incorrect metadata in Noto Variable fonts (causing other issues, including displaying Italic instead of Regular), or incorrect implementaiton or undocumented assumptions made by Windows (a bug that is not really a "feature" because it is very unstable, and Microsoft has to fix it). This means that, for now, you should never install Noto Variable fonts (either for the current user or all users), but you can use them for specific apps in the app's font resources of the app, or you can use a font server delivering them on demand as webfonts (this on-demand font cache is easily purgeable).

Variable fonts in Noto should still be considered in beta stage, and not for general use, as long as there are no major updates in OSes, browsers, and apps for creating documents. However these fonts are safe for embedding in standalone documents (like PDFs) or in webpages (using webfonts), provided that the document creating app is properly isolating them and does not request them from the global OS or from the user's font collection.

As well Variable fonts are not suitable for use on low-resolution devices, where hinted static fonts are preferable. Variable fonts are fine only for HiDPI displays (including most recent mobile phones; but not most desktop screens and TVs, and not for printing with most common printers where font hinting is really needed) or for rendering at large font sizes for titling or presentations (not for the common font sizes at or 16 points used in most text documents).