Font Substitutions for "Unsupported Character Use"

[waltonmendelson]

I am using Affiity Publisher, ver. 1.10.5.1342 on a Windows 10 system.

I have a document where some text has a substituted font. The Font Manager says, for example, “CALVIN  Unsupported characters use”.  I am actually showing this one example, but I have several dozen such failures.

This is not a true error.

The text in question is only the letters of the alphabet, numbers 1 through 0, and standard punctuation.  There is no hidden text, formatting, etc.  It appears that, like Fonts not loading, if I restart AP, some of those fonts load correctly wand work, but again, different ones do not.

Without changing the text, where there has been a font substitution because of "______ Unsupported characters use” (i.e. a failure), it works. Sometimes other text in different fonts that had worked, do not work. Showing that there are no unsupported characters in the text.   

Is there any way to more effectively load fonts than simply restarting AP? Or is there a different solution, other than reloading AP a thousand times until I get lucky?

* * *

In the example below: 

A The font that has failed is correctly set to CALVIN . . . this is not in brackets.

B The font Manager shows it as: "CALVIN Unsupported characters use"

C This is the font display for CALVIN: i.e. what the text should look like.

D This is the AP page, with the highlighted text shows the font substitution 

Thank you, in advance for your help.

Walton

[Alfred]

4 minutes ago, waltonmendelson said:

The text in question is only the letters of the alphabet, numbers 1 through 0, and standard punctuation.

If the “standard punctuation” includes apostrophes or quotation marks, you’ll get that message about unsupported characters when the original text includes typographic/‘curly’ versions of those characters but they are unavailable in the substituted font.

[waltonmendelson]

Thank you, but this is not the case because: 

• This is the text that failed: "ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz 1234567890 .,/!&%$#( )[ ]"
• Sometimes that text does print in CALVIN etc., but not in other fonts

The problem seems to be that fonts sometimes fail to load correctly (they load because they are not Missing).

Walton

[walt.farrell]

Can you share your document with us?

Can you share the font file, or tell us where to find it online?

[Old Bruce]

I notice you have Photoshop and Indesign. Are the problem fonts part of an adobe cloud subscription? Or are the fonts actually downloaded and on your computer's hard drive in the proper font folder?

[waltonmendelson]

I have attached the packaged APub file. There are:

• two fonts that are not embedded: CALVIN and Warnock because "Unsupported Characters Use"
• five fonts that are not embedded because they are "missing": Courier, Drakon, Rose, Times, and Times Bold.
• 22 fonts that are missing because of "restricted use": however, this is false.  These fonts have embedding rights that permit embedding and printing and they have worked in PDF/X-1a files.

Walton

Packaged T&T.zip

[waltonmendelson]

@ Old Bruce

These are all fonts on my computer. I not use cloud subscription fonts.  I would not use any cloud subscription programs (Adobe) except for professional reasons. Other then that, I do not use cloud anything! 

Walton

[waltonmendelson]

@walt.farrell

I "misspoke" about the two fonts, CALVIN and Warnock.  They are embedded, they simply were substituted because "Unsupported Characters Use."

Walton

[lacerto]

Some of the fonts included were quite old and did not have proper Unicode codepoints and Unicode names. The glyphs can be accessed from within the Glyphs panel of Affinity apps but would not be mapped correctly when typed from the keyboard. Different apps have different kind of support for legacy fonts, but it does not seem that these kinds of fonts could be made working with Affinity apps well without fixing/updating them with some font tool.

Perhaps there is a utility that could fix these problems in a batch.

[kenmcd]

I was just fixing the Calvin when you posted - it is a pre-Unicode font.
Thus the code points are different than what is expected (all up in the PUA).
Below is a quickie conversion to Unicode.
It installs, the text appears. Did not test extensively. It should work.

 

Now I am going to look at the other issues.

[waltonmendelson]

Thanks for the reply, but I am not sure I understand it. 

Some of the fonts that have failed erratically--that is they work one day, but not the next--include Courier, Warnock, Optima, Bodoni, Requiem Roman . . . I would not consider all of these legacy fonts if I understand what you mean by that.

That they work one day but not the next, suggests to me a different problem, but, again, because I do not understand legacy fonts, unicode codepoints, and unicode names, you may be 100% correct.

Walton

 

[waltonmendelson]

@ Libre Training

Thank you for the answer.  

Perhaps I should have used Warnock as the example, or Courier, etc.  CALVIN appears to be a red herring.  It has loaded and worked correctly in the past, both in Affinity Publisher and InDesign.

If Warnock or Courier, which have been substituted in this file, are legacy fonts or are either pre-Unicode or lack a Unicode codepoint, etc. and if they work today and not tomorrow, but the day after, then either I am doing something wrong or there is a different problem.

Also, in this file there are 22 fonts that did not embed because they were "Restricted Use."  They are not. Their embedding rights are not restricted and they have worked in PDF/X-1a files.  

Walton

 

 

 

 

[kenmcd]

Affinity apps only support Unicode encoding.
The CALVIN font is an old (1997) conversion from an old Type 1 font.
The encoding is the old Mac-Roman.
Some older applications which had to do deal with this back-in-the-day understand this encoding - modern Affinity applications do not.

Nothing wrong that I can see with the Warnock fonts other than being a bit old - v1.009 from 2000 vs. v2.000 now.

I searched for the Warnock fonts in the doc to see if I could spot anything obvious, but the document is such a mess it is hard to see anything.
Looks like all manual formatting.
And there does not appear to be any rhyme or reason as to when some text is Warnock or Times New Roman.
You really need to use some proper styles.

So your original question appears to be answered.
And the rest appears to be document clean-up.

[waltonmendelson]

@ Libre Training

Thank you for the time and the effort to solve my problem!  What a relief.

Because I was not clear in my original post, and I neglected to say, mea culp,  I am actually showing this one example, but I have several dozen such failures, I guess I have a second question:  While CALVIN failed because the font is pre-Unicode, the following fonts from the same pages--in the file you examined--were also substituted for:

• RequiemFineHTFRoman(does not appear to be pre-unicode)
• Bodoni (does not appear to be pre-unicode)
• Old London (does not appear to be pre-unicode)
• Old Script (does not appear to be pre-unicode)
• Landsdowne (does not appear to be pre-unicode)
• Courier (I am not sure what version . . . has ?Courier as the font)
• Optim (does not appear to be pre-unicode)
• Feltpen (does not appear to be pre-unicode)
• CALVIN pre-unicode
• Marathon (does not appear to be pre-unicode)
• Smartie CAPS (does not appear to be pre-unicode)

I am attaching PDF pages 6 & 7 which show how these fonts were substituted when I worked on the file a week ago. Also attached is a scan of Calvin, when I guess it was unicode perfect, in an earlier incarnation of this project. 

Having styles or not, in no way should effect how these fonts were embedded and how they display.  I appreciate, too, your advice on styles and formatting.  The comment "the document is such a mess it is hard to see anything" is particularly apt. 

Thank you, 

Walton

 

 

 

[waltonmendelson]

I do not understand the somewhat adversarial attitude here. I apologize for not understanding this forum's etiquette.  And I apologize if I over reacted.

So I'll start over:

In an Affinity Publisher file,

1. Sometimes fonts embed and sometimes they do not. This is not the problem I am posting about, although not embedding is a problem.
2. Some fonts do not work, i.e. they are embedded but they are substituted as if they have not been embedded
   1. The Font Manager says "Unsupported characters use": however, there are no hidden character, and I used the alphabet, the numerals 1-0, and punctuation, as noted above. Many of these fonts that do not work today, have worked in the past, this seems to be an erratic problem.
   2. In my ignorance, I gave an example: CALVIN, which was pre-Unicode (although it has worked! example posted above); however,
   3. I listed 10 additional fonts that failed to work:  all of which appear to be post-Unicode (or whatever the appropriate qualifier would be). Pages 6 & 7 above, show this failure.
3. I was questioned about Warnock because it is apparently working for some people. Below are 3 examples showing:
   1. Warnock not working: screen shot of AffinityPublisher file (from the uploaded file above), page 11
   2. Warnock not working on Page 182 0.28.22 file
   3. Warnock working on Page 182 07.20.22 file

Questions:

• If I am not mistaken, Warnock Pro is not a legacy font, and it is not pre-Unicode. My version of Warnock is "a bit old - v1.009 from 2000 vs. v2.000 now."  Is it Affinity Publisher's position that fonts should be re-purchased or downloaded again and again so as to make sure they are up-to-date?
• Sometimes fonts embed but do not work.  What can be done about this?
• Is the proper embedding and functioning of fonts dependent on using Paragraph Styles?

On my system, the file I uploaded above opens erratically.  Sometime there are no missing fonts and no fonts that do not work.  Sometimes fonts are missing and sometimes fonts do not work.  I admit I could be doing something, in fact, many things, wrong.  What I am looking for is some sound advice. 

Walton

 

 

 

[lacerto]

I think that there are too many variables involved to be able to troubleshoot this properly. In my experience both the font mapping feature, as presented when opening an Affinity document or a PDF with fonts not installed on the system, and the packaging feature that determines the status of fonts may work erratically. I have found errors also in Font Manager, sometimes reporting fonts as missing while they are installed, and sometimes not being able to replace correctly missing fonts with user-defined replacement fonts.

Testing one problem or feature at a time seems to be a sound way to proceed, and using simpler documents. E.g., Calvin was a clear case where missing Unicode information caused failure to type text with this font (as assign the font to existing text), while the glyphs were correctly shown in the Glyphs panel and could be picked there and copied on canvas. This problem can be properly fixed only by taking the font in font editor and adding for each glyph a Unicode name and standard number, as follows:

Letter "A" from the original font and fixed font (the first one is "Glyph name" and they were correct ("friendly names") in the original font, based on which the Unicode codes and names, needed by Affinity apps to be able correctly use the fonts, can be generated):

     

I do not know whether @LibreTraining could use a routine that can do this in a batch but in my fixed version I had to go through each glyph one by one. After the fix (and adding old Mac Roman as the supported codepage), I could produce a version that works correctly in Affinity apps. Why it occasionally was rendered correctly for you when opened from a package, I do not know -- perhaps this happens, if the font is already installed so the packaged font is not used, or vice versa. But even if the font is displayed correctly, I suppose the problems related to Unicode would happen whenever the font would be tried to be assigned to text using another font, or when typing text using the font.

On the other hand, I did not experience any problems with Warnock (using the versions in the package).

The problems you have experienced with rendering may well be a result of Affinity Publisher failing to correctly determine the installation status of specific fonts in context of opening a package with included fonts, resulting in double installation and a name conflict, which shows when trying to access these fonts. One possible explanation (which I have not tested) for embedding failures could be that if the fonts were installed from a package (for temporary and private use), they possible cannot be embedded for further use. [EDIT: No, this does not seem to happen so temporarily installed fonts do embed; however if there is name conflict / double installation the font might render correctly but fail to embed.]

Note too that Adobe apps are able to resolve name conflicts better than Affinity apps (and at least enumerate installed fonts a bit differently) so whenever there are problems with names, you might see that the same fonts work properly in context of Adobe apps but fail in context of Affinity apps. 

 

[waltonmendelson]

@ Lacerto

Lacerto, thank you.  I am impressed (I am not being facetious).  I am very active on the KDP (Kindle Direct Publishing) forum. And what you've shown me is the sort of thing I do for other members there.  I recognize the time and effort. 

I have somewhere around 5,000+ fonts in this project.  So you can imagine that were diving into CALVIN typical of these problems, things would be impossible.  I think, however, that CALVIN is a true outlier in my project, and a bad example to have started off with.

As this project has developed over the last 16+ years, I have taken an empirical approach: if a font does not work, I do not use it.  Figuring out the who, what, why, when, and how of failed fonts is a rabbit hole I don't need to go down.  Although you did not bring this up, this is one of those projects where Styles are totally impractical.

I am also guided by what Amazon can print.  In an early incarnation, I had many pages set in Times New Roman. On three pages, a third of the text printed with boxes, as if the character mapping was bad.  TNR was on their system.  The book passed every text related Preflight in Acrobat, and was PDF/X-1a compliant. Adobe suggested I try PDF/X-4 but at that time Amazon rejected PDF/X-4 files (this had nothing to do with transparency, and the book had no transparency).  The solution then was converting text to outline, but I had to get all the fonts into the PDF first.

There are two sides to this: getting the desktop publishing program to faithfully produce a good print-ready PDF, and determining what features create a good print-ready PDF for Amazon.  

You said that both the packaging feature and the Font Manager might be erratic. Certainly loading fonts is erratic: but I have been able to reboot and startup Affinity Publisher and had no missing fonts. It may be hit and miss, but I have been able to get a good PDF from it.  (A problem I had last year was that Affinity Publisher PDFs can double or almost triple in size from time to time, and I could not find, nor could anyone here find, a way to get the smaller size, accept by luck.  KDP has a maximum file size, which they adhere to absolutely. Converting to outline in Affinity Publisher is very near the limit.)

The fonts I showed above, were not missing, and that was today's problem.  I can isolate the fonts that are pre-Unicode, and remove them, that is easy (CALVIN may literally be the only one).  I can reboot a dozen times to get all the fonts to load. But the "Unsupported Characters Use" problem . . . if I cannot, for example, get Warnock to work . . .  and if I can't find a work-around, puts Affinity Publisher totally out of the running, and a good 1000_hours down the toilet.  I migrated a lot over from InDesign, but goin back . . . .

Again, thank you for your time, your posts represent Affinity well. 

Walton

 

 

 

 

 

[lacerto]

17 hours ago, waltonmendelson said:

Again, thank you for your time, your posts represent Affinity well.

You're welcome. I think this could be "one of those things", comparable to mysterious increase (and decrease) of document file size. I opened the Publisher file you posted and exported pages 6 and 7 and it seems all fonts were rendered correctly and embedded. Most fonts (except the ones like Arial, etc.) were installed from the package, and I already had a fixed version of Calvin installed so I have not checked whether that, too might have worked if installed from the package (if not touched).

Here's the file, you can probably see at a glance if it has any problems with fonts or individual glyphs:

fonts_6-7.pdf

I am not sure but I think that there were some problems with typesetting examples later on in the document but not e.g. with Warnock Pro. So this might be a problem related to (Affinity) font cache, a problem with app memory management, etc. I have an impression that the problems I mentioned above that I have experienced with routines that try to determine whether a specific font is installed have been such that they cannot be consistently reproduced, so even if there were problems with the code mapping the fonts, some problems with fonts my be caused by other and not directly font-related issues.

Do you have any font manager installed on the system (I do not have, so I do not have personal experience of possible problems they could cause in context of using Affinity apps, but remember to have read some posts reporting such problems)?

[waltonmendelson]

Short answer: no, I do not use or have a font manager on my system.  Many years and several computers ago, I tried a font manager that was supposed to make selecting and using fonts an experience without rival, better than a free trip to Disneyland, better than sliced bread, etc. etc. etc. It lasted less than a day and it was gone.

"I am not sure but I think that there were some problems with typesetting examples later on in the document" . . . yes, in large part due to migrating InDesign files to Affinity Publisher, a lot got scrambled.  Because we read better from paper than monitor and I know there can be issues at the RIP (etc.) end of this, I am having each book printed, then assessing the issues from print.  

". . . app memory management," normally, when I have problems with fonts not loading (not this problem), I will reboot using Power > Restart several times (I'm using Windows 10 with a large SSD and 32 GB of RAM), then I load Affinity publisher.  Seems to work, but not for the "Unsupported Characters Use" issue.

I have three books, all in Affinity Publisher (about 900 pages in total), but started in InDesign.  All involving typography, printing, etc.  They are all at the same stage where I have to do a final edit of the files, push images around, and create finished, print-ready PDFs. As a practical matter, if I cannot find a work-around to this, I cannot use Affinity. 

These are my books, not clients' books.  I do not use Affinity professionally, primarily because of the epub issue; also, some printers want the source files and the PDFs.  That means InDesign. 

I have been proactively recommending Affinity over Adobe (with two exceptions: no automatic footnote feature and no epub conversion). Now, I am quite concerned, not just for me but for recommending Affinity.  The PDF bloat issue does not appear to effect printing--I did around 60+ test books last summer/fall using Affinity Publisher and had no problems.  But if fonts won't print, that is a game changer. 

I do recognize that most people only use 2-6 fonts in a book, so they might not have this problem, or changing fonts isn't a serious problem.

Your PDF of pages 6 & 7 looks great.  I remember seeing it like that once before . . . a while ago! 

Again, thank you.

Walton

[lacerto]

I had a closer look on the "unsupported character use" problem related to Warnock Pro, and it appears to be related to use of character ǁ on page 92 (you can use the Locate button to have the issue in focus). If I remove the character, the error message disappears but it then appears in context of Times New Roman! When pressing Locate in context of Times New Roman, empty space on page 100 is highlighted and if I remove that, the error message is no longer shown.

Before that I tried to isolate the problem by installing all 32 Warnock OTFs from Adobe FontFolio 11.1 but that did not make any difference. The versions in this collection are newer than ones in the package but this basically rules out the possibility of this having anything to do with the fonts themselves.

I suppose that this resolves the "unsupported character" problem (at least makes it go away), so the rendering problems (e.g. not being able to show Warnock Pro) seem to be a separate issue.

[waltonmendelson]

Ironically, I just opened the file, and Warnock Pro was working throughout, but just as you noticed, and Times New Roman was now "bad", removed the space on pg 101, and voila . . .   A number of the missing fonts (only 5 right now, not the 22 of yesterday) are manageable.  There are a few oddities, I think a result of the InDesign to Affinity Publisher conversion, for example, Nueva Std Bold & Nueva Std Bold Italic look fine on page 19, but in the Font Manager they are listed as Times/Missing.  Despite the Font Manager, the page look okay and they are embedded in the PDF.  

Anyway, I think I may be able to manage keeping this section of the book in Affinity Publisher, and retracing your steps, I may have the tools to fix things.

Thank you!  If you're ever out is Prescott, AZ (can't imagine why, unless maybe the World's Oldest Rodeo), I owe you beer!

Walton

 

 

[kenmcd]

@waltonmendelson

If you created the CALVIN text in another application which understands that old encoding, such as Word or LibreOffice, it will appear to be OK when imported or pasted into APub - because the those applications will connect what was typed to the characters in the font, and characters are what you paste.
But those characters do not have correct Unicode codes behind them.
Try searching for the text in APub and it will not be found.
Also the minute you start to type something new or to correct something you are typing in Unicode so the new/corrected text will be in a fallback font, because CALVIN does not have the character codes you are typing.

No Affinity does not require you to buy newer fonts.
The Warnock fonts are fine.
I just mentioned the age only because fonts do sometime have bugs fixed.

@lacerto
FontCreator has a Convert to Unicode Font feature.
Works OK for old converted T1 fonts - usually.
Have to be on the look-out for duplicate names.
And it does not seem to fix characters beyond the 233 symbol font limit.
Anything beyond that and you need to do manual fixes (up to the 255).

FontLab has Generate Unicodes feature which works much better.
It has a file which contains all the "standard" glyph names and their codes.
So it uses those to the assign the Unicode codes to the characters.

You can also do it with fonttools (on GitHub) using Python.
Never tried that so I am not sure what it would do with duplicates, etc.
Because the original conversions are often not the best, you kinda need to be able to see what you are doing (to fix the duplicates and other character name errors).

[waltonmendelson]

@ Libre Training

Thank you for the clarification.  As I suspected after the first or second replies above, CALVIN was an unintentional red herring. I am not wedded to it, only to an example of a Brush style font.

Clearly, a complex 16-year project starting with InDesign CS4, and finally, this year, converting from legacy versions to Indd to Idml to afpub is not simply an easy-peasy transition.

Walton