Serif Font Persona Non Grata

[Kelly Bellis]

Searching the FAQs, and elsewhere on forum.affinity using terms like wrong font I was unable to find an answer for new users trying out about the software as to why Affinity Photo (1.10.5.1342) on Windows 10 Pro is displaying the wrong serif font. For example, below is how Affinity Photo (Trial) is rendering the exact same serif fonts shown above.  The two example sans serif fonts compare fine in this morning's initial test.

https://www.360cities.net/image/union-river-bay-to-graham-lake

 

Edited August 8, 2022 by Kelly Bellis

[walt.farrell]

For a guess: the fonts you have installed are Variable fonts. As the Affinity applications only support Static fonts, you just see the basic version of the font when the Variable fonts are used.

[kenmcd]

Because of the somewhat odd font names, my first WAG is these are old conversions - so the encoding may be the issue.

Please provide more specific info on the two fonts - vendor, version number, file format, etc. Really need to test the fonts to see what is going on.

[Kelly Bellis]

Thanks Walt. I'm not clear on how these are variable fonts, to begin with, there are no variants; e.g., light, condensed, regular, etc.

[Kelly Bellis]

@LibreTraining Thanks for chiming in. Did my reply to Walt answer your question sufficiently? My collection of fonts are from the early 1990s and later.  All fonts have been rendered properly by all other graphic softwares except for Affinity.

Edited August 8, 2022 by Kelly Bellis

[kenmcd]

Bodoni ... makes more sense than Bodini.

Those do look like old conversions from old Type 1 fonts. Those old conversions often have conflicting or bad encoding. Many older applications can understand this old encoding. Affinity applications only support modern Unicode encoding. 

Those fonts probably have Microsoft Symbol encoding specified for the Windows platform and code points up in the PUA - so when you type normal Unicode from your keyboard, there is actually nothing there, so a fallback font is used.

Need to see the fonts.

[Pšenda]

6 minutes ago, LibreTraining said:

Bodoni ... makes more sense than Bodini.

... or Bondini 🙂

[Kelly Bellis]

11 minutes ago, LibreTraining said:

Bodoni ... makes more sense than Bodini.

Hahaha - my mind slips and my misspellings are chronic!

 

As for the the encoding, how can this be determined?

P.S. I apparently am unable to post further having reached my daily limit. Will respond further tomorrow if permitted.

 

Edited August 8, 2022 by Kelly Bellis

[kenmcd]

17 minutes ago, Kelly Bellis said:

As for the the encoding, how can this be determined?

On my way to morning workout now ... will post a few different ways later today.

[kenmcd]

@Kelly Bellis
I took a look at both fonts - both are encoded as Microsoft Symbol (on Windows platform) as suspected.

Regarding looking at encoding - I usually first look at suspect fonts in FontCreator because you can see immediately if it is a "symbol font" - but that is a bit complex for the casual user.
I also use the free DTL OTMaster Lite which allows digging around inside the fonts where you can check the encoding in the cmap table. But that is really a font-geek type of tool.

The easiest way to see font encoding is using an old free tool called FontReport Lite. Because it is so old it shows all the old encodings.
It is a portable application which requires no installation (just run it).
Download here: https://www.acutesystems.com/free/dl_afrl.htm
Here is a partial sample for BodoniExtraBold:

 

Both of these fonts could be "fixed" but you would end up with a very limited 20-year-old font, with minimal kerning, and no OpenType features.
While there are many free OFL Bodoni and Garamond full-featured fonts as alternatives.

[Kelly Bellis]

@LibreTraining - Thanks, this is great information.

So, was there a deliberate choice made by Serif to not support (symbol) fonts that don't use modern Unicode encoding?

Or maybe a better question, does Serif publish which Character Encoding is supported by Affinity applications?

[kenmcd]

2 hours ago, Kelly Bellis said:

So, was there a deliberate choice made by Serif to not support (symbol) fonts that don't use modern Unicode encoding?

Or maybe a better question, does Serif publish which Character Encoding is supported by Affinity applications?

Affinity supports modern Unicode encoding - which virtually all applications do now. And you can use correctly constructed symbol fonts (i.e. Symbol on Windows).

But those fonts are actually broken. Text fonts should not be encoded as a symbol font. Also back then different platforms had different encoding (Unicode fixed this crazyness).

Macintosh Roman is the most common old encoding for Mac text. So these fonts were encoded properly for that platform back then.

Windows ANSI (or 1252) would be the most common old text encoding for Windows back then. And that is what these fonts should have for the Windows platform, not Windows Symbol.

So when these fonts were converted from old Type 1 to TrueType they were not converted properly.

Many older applications are better at dealing with old broken fonts as they had to deal with them all the time back then. You can use these in Word or LibreOffice and what you type looks OK, but the codes behind those characters are often wrong - so for example search may not work, screen readers may not work, and editing in Affinity applications does not work - as these all require proper Unicode encoding.

If you paste some text using these fonts from another application, which looks OK in that application, into Affinity, then highlight that text in Affinity and hit Alt+U to display the Unicode codes behind that text - the codes are not correct for the characters displayed. 

These font families are really common so there are a ton of modern, up-to-date, properly Unicode encoded, fully kerned, with lots of OpenType features - free and commercial alternatives.

Some free fonts that come to mind...

Bodoni* on GitHub (in 8 optical sizes IIRC), Bodoni Moda and Libra Bodoni on Google Fonts.

EBGaramond12 on GitHub (a fork). EB Garamond and Cormorant Garamond on both GitHub and Google fonts.

And quite a few others (Gara, etc.) ... on my phone at the moment, would have to find the links later.

These fonts could be quickly fixed so they do work, but what you end up with is still bad. Good quality free alternatives are available.

[Old Bruce]

7 minutes ago, LibreTraining said:

... highlight that text in Affinity and hit Alt+U to display the Unicode codes behind that text ...

On Mac OS it is Control + U to toggle between Unicode and the glyphs.

[kenmcd]

8 minutes ago, Old Bruce said:

On Mac OS it is Control + U to toggle between Unicode and the glyphs

Could be the same on Windows and I just had a brain fart. 😀

Have check later when not on my phone.

[walt.farrell]

9 minutes ago, LibreTraining said:

Could be the same on Windows and I just had a brain fart. 😀

No, you were correct with Alt+U for Windows.

[kenmcd]

Just now, walt.farrell said:

No, you were correct with Alt+U for Windows.

LOL. When @Old Bruceposted that I immediately thought to myself "I need Walt here." Thanks. 🙂

[Kelly Bellis]

This has been an interesting discussion and perhaps a wee bit nostalgic for me with a genesis story of some ancient fonts. The one on the left from World Art date from about 1994 and can be blamed for this thread's origin. The one on the right dates back to 1990 up until Atech's death in about 1993. There have been other fonts added since, but these are the oldest in my Windows font collection.

Quote

If you paste some text using these fonts from another application which looks OK in that application into Affinity, then highlight that text in Affinity and hit Alt+U to display the Unicode codes behind that text - the codes are not correct for the characters displayed.

My (bad) incorrectly converted [BodoniExtraBold] text copied from the (correctly) displayed in PS CS6 .psd then pasted into a new Affinity Photo document becomes:

U+0042U+006FU+0064U+006FU+006EU+0069U+0045U+0078U+0074U+0072U+0061U+0042U+006FU+006CU+0064

Compare this to the same text; i.e., [BodoniExtraBold] entered in and originating in Affinity Photo that used Helvetica Bold

U+0042U+006FU+0064U+006FU+006EU+0069U+0045U+0078U+0074U+0072U+0061U+0042U+006FU+006CU+0064

So this looks like Helvetica Bold had somehow been chosen by Affinity to become the substitute font - is this correct?

 

 

 

 

[kenmcd]

2 hours ago, Kelly Bellis said:

So this looks like Helvetica Bold had somehow been chosen by Affinity to become the substitute font - is this correct?

Interesting. Not sure how that happened, but those are the correct Unicode codes for the text "BodoniExtraBold" ... but, those codes do not exist in the BodoniExtraBold font. All of the codes actually used in that font are up in what is called the Private Use Area (PUA). The PUA is where anyone can assign any code to any glyph. So nothing is standard up there (with a few exceptions).
All the correct codes such as for the letter B etc. are simply not there in the font. So like any missing character, they are replaced with a fallback font. In this case I guess that fallback font is Helvetica.

A long, long time ago waaaaay back in the Type 1 era, and then TrueType era, before Unicode ... the encoding was small groups of characters (less than 256 per font) also known as code pages. Glyph order was important. Glyph names were important. Specific characters had to be a specific glyph number and usually a specific name. Older applications recognize, for example, Macintosh Roman encoding and can insert the characters in the document by this glyph number. Now your particular fonts did also have some Unicode codes in the character maps inside the fonts, but they are not correct, they are in the PUA.

Font editors such as FontCreator and FontLab can convert these fonts to Unicode by using the glyph names, and then assigning the correct Unicode codes based on those names. So that is the quick fix I mentioned. But, these old conversions will often have bad glyph names, or duplicate glyph names, or missing glyph names - all of which make this a much more manual process.
I have seen fonts where none of the glyph names are correct for the glyphs they are assigned to (it looked totally random) - that would take quite awhile to manually sort, and to guess, which should be which. Generally, unless the font is some completely unique font that you just cannot live without, this is not worth the time and effort. And some characters you may need are usually missing. One I saw recently was missing one side of the curly quotes.

Thanks for the picture of the sources - I was curious where these came from.

[kenmcd]

@Kelly Bellis Just fir the halibut. Quickie conversions below.

fixed-fonts.zip

[Kelly Bellis]

@LibreTraining Brilliant! Thanks so much for this entire illustrated discussion lesson and for sharing the post FontCreator conversion of the (2) circa 1994 fonts.

Looking at the metadata for my old fonts, with the help of Phil Harvey's amazing ExifTool; something I've used forever with images, but never thought that it would work with fonts, the spreadsheet was produced via the command line:

exiftool -csv -r "c:/Windows/Fonts" > "L:/Serif Software/font related/fonts.csv"

Out of the 1600+ files, there are 250 files copyright tagged FontBank, Inc. ROE which include the GaramondAmerica and BodoniExtraBold examples. But what isn't revealed by ExifTool are the bits about the character encoding; i.e., Unicode 1.0 (0,0), Windows Symbols (3,0), etc., presumably hidden in the Private Use Area (PUA). I'm guessing that none of them can be correctly rendered by Affinity applications without first doing the quick font fix you spoke of using font editors such as FontCreator and FontLab to convert these fonts to Unicode by using the glyph names, and then assigning the correct Unicode codes based on those names like your examples in fixed-fonts. For now, and probably forever, there's no burning need to consider doing this quick fix, even for the nerdy fun of trying. I probably should instead focus on the greater parts of Affinity Photo during this trial period in the 7 days that remain.

So back to the general issue of Affinity non-supported fonts, including what Walt first introduced, Variable fonts, which I have not played with yet. Font substitution allows for some means of still being able to make sense out of a character string when the application; e.g., Affinity Photo, can't otherwise display the string. That's nice, but there ought to be something communicated to the user detailing 1) why the intended font was unable to be correctly rendered by Affinity Photo, 2) why font substituere was chosen, 3) maybe suggested methods to remedy the situation, and 4) maybe allowing the user to choose the default substitution font. The latter would readily facilitate /communicate /flag the issue to the user once the popup notice had been dismissed.