Jump to content
You must now use your email address to sign in [click for more info] ×

Glyph substitutions must be highlighted


Recommended Posts

Hi there,

I believe there is a bug that must be ironed out before Publisher is released to the public. When a glyph is missing from a font, but the respective character is inserted in a text frame, Publisher will perform a font substitution. And glyphs will be substituted from a variety of different fonts, most notably

  • Lucida Grande,
  • Apple Symbols,
  • Geeza Pro,
  • Hiragino Mincho Pro.

While I am already very sceptical about automatic glyph substitution (I don’t want the application to do my work in this case), I think it is even more problematic that substituted glyphs aren’t highlighted in a text frame. Given the current implementation, it is all too easy to end up with a document that contains unwanted glyphs. The little exclamation mark preceding the font name in the font dropdown menu cannot really count as a sufficient indicator for a missing glyph, for you will have to select the glyph in order to see it.

In short, I would strongly suggest that you either stop doing glyph substitutions (use the .notdef glyph instead) or highlight a substituted glyph in a text frame.

Thanks for your consideration,
Alex :)

Substitution.thumb.png.a3617487f0f37c097c452634171f771a.png

Link to comment
Share on other sites

1 hour ago, A_B_C said:

The little exclamation mark preceding the font name in the font dropdown menu cannot really count as a sufficient indicator for a missing glyph, for you will have to select the glyph in order to see it.

Just a comment: Using the Document > Font Manager or using Text > Find... you can easily locate the spots that use the missing font.

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

I think I'm a bit concerned about highlighting, in that if a font is substituted and it's one that's used frequently in a document, most of the document could end up highlighted. 

That is, the highlighting might be useful if applied to only a few special glyphs from a font such as Wingdings, but much less useful for the more general case of font substitution.

And if enabled, the highlighting might be most useful if you could enable it for specific fonts within the document.

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

I don’t even understand the mechanics of glyph substitution. It seems Publisher is just browsing the default fonts that come with the operating system and inserts glyphs from one of these fonts when they are missing in the intended font.

But that will lead to the weirdness that documents look different on macOS and Windows … and possibly iOS as well. I don’t believe that Apple Symbols, for instance, is shipped with Windows systems. So some of the missing glyphs in a document that is shared with me will be substituted by glyphs from Apple Symbols on a Mac, and when I (or any other individual) open(s) the same document on a Windows computer, these glyphs will be substituted by a completely different font … and possibly exported to PDF for printing!

I don’t believe that is a neat situation. I’d rather have no glyph substitution at all. :(

Link to comment
Share on other sites

8 hours ago, MikeW said:

Font substitution is of the devil without warning and/or a visual indicator...it simply should not happen.

I agree about highlighting not only font substitution but also ligatures, anything that is a variable, etc. Kinda just like in ID. And it should be able to easily be on/off.

We already have Text > Show Fields that will highlight anything that is a variable. We'll consider adding a way to highlight missing fonts and characters.

The fallback fonts are mainly so that you can read the text and see what the missing characters are. You aren't really expected to continue working with fonts that aren't installed, or with characters that aren't supported by their font. We will actually use the replacements set for PDF Import, but there isn't currently a good way to edit them without opening a PDF that tries to use the same font. On Mac we then try to use the same replacements as Mac OS; I think Windows uses a different set of fonts but both are trying mainly to have a broad coverage of Unicode. We make some attempt to match the basic style - serif versus sans serif etc - but often if we don't have the font we don't even know that.

Incidentally, another way to check on a specific character in the text is to select it and use Alt+U. That will toggle between it and the Unicode representation. You can also use that as a way of entering characters by Unicode, or as font glyph indexes using G+XXXX.

Link to comment
Share on other sites

58 minutes ago, Dave Harris said:

another way to check on a specific character in the text is to select it and use Alt+U.

Huh? all I get is an ¨ .

Mac Pro (Late 2013) Mac OS 12.7.4 
Affinity Designer 2.4.0 | Affinity Photo 2.4.0 | Affinity Publisher 2.4.0 | Beta versions as they appear.

I have never mastered color management, period, so I cannot help with that.

Link to comment
Share on other sites

3 minutes ago, Old Bruce said:

Huh? all I get is an ¨ .

For me, alt+u turns the selected character (or string of characters into the form U+nnnn where nnnn is the UTF-8 representation of the selected character(s).

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

Thank you for this explanation, Dave. It certainly makes sense. All that I would ask for is a highlight in the text that shows you that a glyph substitution has taken place. This is truly important when working even with modest amounts of text that are shared by other people. :)

Link to comment
Share on other sites

On the Mac, it doesn’t seem to work this way. The only method I am aware of is the following:

  • Go to Apple Menu > System Preferences > Keyboard > Input Sources
  • Click the Plus button to add a new input source
  • In the list that appears on the left, scroll down to the bottom and select Others
  • In the panel to the right of the list, select Unicode Hex Input
  • Make sure to have engaged Show Input menu in menu bar

Now suppose you want to enter a Unicode character from the Basic Multilingual Pane. In this case, the Unicode code point has four hexadecimal digits, and the UTF-16 encoding is numerically equal to this code point. So the character ¼ (Vulgar Fraction One Quarter) has the code point U+00BC which is encoded as 00 BC in UTF-16.

  • If you want to enter this character, select Unicode Hex Input from the menu bar as your input source
  • Hold down the Alt (Option) key and type the UTF-16 encoding of your character’s code point: 0 0 B C

Unicode characters beyond the Basic Multilingual Pane are encoded as two 16-bit code units. Such characters do not seem to be supported by Unicode Hex Input in the apps of the Affinity suite. They can be entered in other apps, for instance in TextEdit, but you will have to know the UTF-16 hex encoding of their Unicode code point. So in order to insert the character U+1D11E (Treble Clef), you would have to use D8 34 DD 1E.

I don’t know if there is another way to do all this on the Mac. :35_thinking:

Link to comment
Share on other sites

  • 5 years later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.