Need a way to locate "Unsupported character use"

[sfriedberg]

Ah, now that's promising. I can make a reliable assumption for this particular document that I know what the wrong font is.  In other situations, there might be lots of possible "wrong fonts".  But now I have two strings to my bow for dealing with the current problem child document.  Thank you, @Old Bruce and @LibreTraining.

At this point, I want to return to the original motivation for this thread:  providing feedback on Publisher, identifying a desirable tool:  When Font Manager reports "Unsupported character use", there should be a tool which locates those uses, just as there is a tool which locates uses of missing fonts.

[Old Bruce]

4 minutes ago, sfriedberg said:

When Font Manager reports "Unsupported character use", there should be a tool which locates those uses,

No argument from me about this.

[Alfred]

12 minutes ago, sfriedberg said:

When Font Manager reports "Unsupported character use", there should be a tool which locates those uses, just as there is a tool which locates uses of missing fonts.

 

6 minutes ago, Old Bruce said:

No argument from me about this.

Nor from me!

[sbe]

+1 

[kenmcd]

1 hour ago, sfriedberg said:

Ah, now that's promising. I can make a reliable assumption for this particular document that I know what the wrong font is.

This will also depend on what fonts the user has in their system.
And whether the text is serif vs. sans serif, the actual Unicode codes needed, etc.
The substitute font will change, and there may be more than one substitute font.

The best solution is to be able to highlight the replacements, and let the user decide on how to best deal with it.

[fde101]

While the optimal solution would be to have arrows for "find previous" and "find next" in the preflight panel so that you could simply cycle through occurrences of a given issue, as a workaround, it might be interesting to have a tool in which you could select two fonts and have the tool generate a new font in which code points that the two fonts have in common are represented as spaces and code points that are missing in one of the selected fonts compared to the other are replaced with a bullet or some similar thing which readily stands out.

Then you could temporarily substitute that font and look for the bullets.

[kenmcd]

7 minutes ago, fde101 said:

two fonts and have the tool generate a new font in which code points that the two fonts have in common

This could only work if the user has both fonts.
Assumes they know both the before and after fonts.
Assumes the original font had no substitutes.

And I am sure the font police will have something to say about modifying fonts.

 

[fde101]

1 hour ago, LibreTraining said:

This could only work if the user has both fonts.
Assumes they know both the before and after fonts.

Correct.  On the other hand it has the advantage of being usable with various word processors and other applications which do not have an equivalent to this feature of the "preflight" panel.

 

1 hour ago, LibreTraining said:

And I am sure the font police will have something to say about modifying fonts.

Completely irrelevant as no font is being modified.  A completely new font would be created with zero content from the originals.

[kenmcd]

3 hours ago, LibreTraining said:

Assumes the original font had no substitutes.

@fde101   Think you conveniently forgot this part.

[fde101]

2 minutes ago, LibreTraining said:

@fde101   Think you conveniently forgot this part.

Nope, I left it out because it is irrelevant if the document being worked on was structured correctly.

For the font substitutions to be relevant in this context they should have been applied via character styles, meaning that the substitution for the main font would be an adjustment to that style.  If there were characters substituted from some other font then they are either local style overrides or some other character style, so that modifying the style to change the font for purposes of this testing would have no impact on them.

[Mark Daniel]

I might have missed the point here but Preflight checks for Missing Glyphs and if you double click the error in the preflight window it will select the glyph in question. If it's not doing that then it's probably a bug.

[sbe]

I think it should also be visually indicated while designing if there are problems with missing glyphs / unicode problems. I had also suggested it here under point 2, but unfortunately I haven't received any feedback yet

 

 

[kenmcd]

13 hours ago, fde101 said:

For the font substitutions to be relevant in this context they should have been applied via character styles

Nonsense. The replacements are done automatically and silently. Which is why they are not known. So the comparison of the two fonts is useless.

[sfriedberg]

10 hours ago, Mark Daniel said:

I might have missed the point here but Preflight checks for Missing Glyphs and if you double click the error in the preflight window it will select the glyph in question. If it's not doing that then it's probably a bug.

That is exactly the facility I was requesting.

The only thing you missed is that none of the other participants on this thread were aware of it!  So we can safely say that this is not one of the more obvious "To do X, go to Y" situations.  I'd recommend that a sentence or two be added to the Publisher Help page Text > Editing > Font Manager pointing out that the "Unsupported character use" can be located via Preflight.

If you have a look at my Preflight panel in the attached image, I think you can see the (separate) need for a way for the user to suppress/approve spelling mistakes.  I have pages of preflight "spelling mistakes" which are either technical terms not known to the dictionary or math expressions, the latter typically occurring many times.

[walt.farrell]

4 minutes ago, sfriedberg said:

If you have a look at my Preflight panel in the attached image, I think you can see the (separate) need for a way for the user to suppress/approve spelling mistakes.  I have pages of preflight "spelling mistakes" which are either technical terms not known to the dictionary or math expressions, the latter typically occurring many times.

For that, I would recommend either:

1. Actually running SpellCheck, and selecting either Learn or Ignore, as appropriate for the words. (Learn if you need them in other documents, too. Ignore if they are specific to this document.) or
2. Using a Character style with the Language/Spelling set to None for those terms.

In my opinion, spelling issues are not something you should learn of, and handle, during PreFlight. They should be dealt with during document preparation and then in PreFlight there will be few, if any, spelling issues to handle. That makes PreFlight a kind of backstop, or safety, check, not the primary check.

[walt.farrell]

9 minutes ago, sfriedberg said:

That is exactly the facility I was requesting.

The only thing you missed is that none of the other participants on this thread were aware of it! 

Unless I missed it, you never said you were getting PreFlight errors. You only mentioned issues showing up in the Font Manager.

Double-clicking on the PreFlight error message is the standard way of locating PreFlight errors and dealing with them.

[sfriedberg]

3 minutes ago, walt.farrell said:

Unless I missed it, you never said you were getting PreFlight errors. You only mentioned issues showing up in the Font Manager.

Double-clicking on the PreFlight error message is the standard way of locating PreFlight errors and dealing with them.

I didn't say I was getting (relevant) preflight errors, because the three or four occurrences of relevant messages were buried in pages of irrelevant messages.  Therefore, I was only aware of the "Unsupported character use" message from Font Manager.

Consulting the product Help pages did not yield any suggestions about how to locate these occurrences (noted just above).

[walt.farrell]

8 minutes ago, sfriedberg said:

Consulting the product Help pages did not yield any suggestions about how to locate these occurrences (noted just above).

Help: https://affinity.help/publisher/English.lproj/pages/Publishing/preflight.html

Quote

Double clicking on an issue in the panel will take you to its location in the file. A Fix button beside certain issue types allows you to fix them immediately.

 

[kenmcd]

On 4/28/2021 at 12:52 AM, Mark Daniel said:

I might have missed the point here but Preflight checks for Missing Glyphs and if you double click the error in the preflight window it will select the glyph in question. If it's not doing that then it's probably a bug.

The replacements should be highlighted the moment they are typed (or imported) so the user can deal with them immediately.
Not months later when a "finished" book is run through Preflight before sending it to the printer.

 

[sfriedberg]

23 hours ago, walt.farrell said:

Help: https://affinity.help/publisher/English.lproj/pages/Publishing/preflight.html

 

You misunderstood my point, @walt.farrell.  When presented with "Unsupported character use" in the Font Manager, I consulted the Font Manager help page.  There was nothing there to suggest how to pursue that particular issue.  As noted above, adding a sentence or two to that particular help page, referencing the Preflight tool, would be beneficial.

Futhermore, doing a full text search of the entire help for "Unsupported character use" does not yield the Preflight tool among the results.

So, yes, if I access the Preflight help page, I see it has an entry for "missing glyphs".  The trick is for the user to intuit that "Unsupported character use" is also "missing glyphs".  And to seek help for the Font Manager by asking about the Preflight tool.

[sfriedberg]

1 hour ago, LibreTraining said:

The replacements should be highlighted the moment they are typed (or imported) so the user can deal with them immediately.
Not months later when a "finished" book is run through Preflight before sending it to the printer.

Agreed.  Although that probably would not have dealt with my situation.  I am fairly confident that one or both of two things lead to my situation.  1) Inadvertently selecting one too many or one too few characters when applying a character style. 2) Use of Text > Reapply Text Styles or Reapply Base Styles to the wrong selection.  So, when typed, the glyphs were in the proper font.  It was a subsequent style change which caused the problem.

So, I would generalize the statement to "The replacements should be highlighted the moment they occur."

[loukash]

On 4/27/2021 at 8:58 PM, sfriedberg said:

When Font Manager reports "Unsupported character use", there should be a tool which locates those uses

Works for me:

 

Other than that, there's also Text > Toggle Unicode which can be helpful for Find & Replace if you know the code point you're looking for.

As a side note, temporarily toggling parts of text to Unicode is also an ugly workaround to limit the scope of Find & Replace…

[kenmcd]

1 hour ago, sfriedberg said:

It was a subsequent style change which caused the problem.

But that is the exact situation users are going to encounter when they must change fonts because of missing characters.
Of if they decide to change the fonts(s) for a variety of reasons - coverage, color, publisher does not like it, better options, etc., etc.
This, changing a font, should not be a problem.

The problem is the stealth replacements and lack of an easy visual way to see this while editing.
You should be able to change fonts, styles, or anything, and be able to see the faked characters.
Hiding the problem is not a solution.
Running some report after-the-fact to find potential problems is not a good solution.

No designer concerned about quality work would ever support these unwanted silent replacements.
It is not helpful.
It is exactly the opposite - it is a giant PITA that you have to work around.

Fake bold, and fake italics are not helpful ... and no longer supported ... as I assume a quality issue.
How are faked characters from a wrong font any less of a quality problem?

"Well folks, most of the time we give you the font you specified, but if any characters are missing we pick the font for those."
That's crazy.

What if the selected font only has basic Latin characters and the user is writing in any number of Latin-based languages which have many diacritics/accents not present in the font?  At what point does that get just completely ridiculous?

My preference would be an option to turn-off the stealth replacements, and show the .notdef character - as intended.

[loukash]

2 minutes ago, LibreTraining said:

it is a giant PITA

Hear! Hear!

[walt.farrell]

I agree with @loukash above about Locate in the Font Manager working. When the Font Manager says Unsupported Character Use, I can highlight that font, and click the Locate button. It takes me to the next occurrence of one of those Unsupported characters. Repeated use of Locate walks through the document locating them, and highlighting them.

I agree that they should be highlighted in some way when they are entered (or when the font is changed in a way that causes the problem).

And I wish I understood why the font substitution is occurring. I thought we should get the "undefined character" glyph, not substitution from some other font.