Bold shortcut doesn't work

[Handyann]

Hi all. Sorry to be asking yet another question.

Is anyone else having issues with a non-working Bold shortcut - ⌘ B - in APub please? I'm on a MacBook running Sonoma and I just get the 'nuh-uh' buzzer sound. Other shortcuts seem to be ok, so I'm wondering if this is a bug or if it's been changed?  

[walt.farrell]

Perhaps the font you're using doesn't support Bold text? Is the B button available (and working) in the Context Toolbar?

[thomaso]

Can you use the 'B' button or the menu command in this situation or is it grayed-out? – Note, the 'bold' option is not available for every font file.

[Brian_J]

If bold is available for the font you're using, do you have a 'Bold' character Text Style defined, and if so, is the keyboard shortcut set to ⌘ B in the Text Style?

[Handyann]

@walt.farrell @thomaso I can make it bold manually with the drop-down next to the font list, so I assumed the ⌘ B would work.

@Brian_J Bold is available, but I haven't defined a style - I didn't realise I needed to just for this.

[kenmcd]

Just now, Handyann said:

assumed the ⌘ B would work.

The Bold and Italic buttons depend on the style-linking inside the fonts. If that is not correct than those buttons may not work properly. 

What is the font?

 

[Handyann]

@kenmcd It's Khmer MN

 

[thomaso]

5 minutes ago, Handyann said:

make it bold

"Making" it bold by selecting an existing font trait / font file is technically not identical with the "B" option.

[kenmcd]

8 minutes ago, Handyann said:

@kenmcd It's Khmer MN

 

The version included with macOS (which version), or downloaded from some website? (where)

 

[Handyann]

@thomaso I agree the option isn't there with the button, but it is on the drop-down next to the font name to the left, along with 'Regular'. Does that not mean it is a trait offered with the font, or is it applying something which is imposed on the font by APub? It all seems crazily complex to do such a simple thing.

@kenmcd It's included with macOS Sonoma

[kenmcd]

6 minutes ago, Handyann said:

It's included with macOS Sonoma

Have Sonoma installed in a VM now, so I can check the fonts later today.

Most likely the style linking is broken.

Apple does that.

[Handyann]

@kenmcd Thank you for going to so much trouble. I know I can do it with the drop-down, but I just don't like things that don't work if they should 🤷‍♀️ 😊

[thomaso]

2 hours ago, Handyann said:

Does that not mean it is a trait offered with the font, or is it applying something which is imposed on the font by APub?

As far I understand the "B" and "I" button try to cause the auto-selection of another, existing font trait without the need to open the font menu. They also may switch to a font's style which is named other than "bold" or "italic" and thus they may mislead or fail. The precision appears to depend on the font file quality, apart from its style names (see above: 'medium' alias 'bold').

Compare "small caps" as character style setting versus as separate font characters, or accordingly "Sub-/Superscript" as app function versus separate font file property.

2 hours ago, Handyann said:

It all seems crazily complex to do such a simple thing.

The complexity is related to font files and their various types, technologies and standards, grown over years for more improvement, e.g. platform compatibility and flexibility. This is no simple thing.

The simple thing is rather an expectation or experience in the user's view – in particular since the "B" and "I" buttons added to possibly make things simpler. – With other words, to keep it simple use the font trait menu only … avoiding the complexity caused by the "B" or "I" button / function 😉

3 hours ago, kenmcd said:

Most likely the style linking is broken.

Apple does that.

macOS Mojave 10.12 with Khmer MN.tcc v.14 (2019):

[kenmcd]

4 hours ago, Handyann said:

@kenmcd Thank you for going to so much trouble. I know I can do it with the drop-down, but I just don't like things that don't work if they should 🤷‍♀️ 😊

Confirmed the fonts are the problem.
The style-linking is not configured properly.
Both the Regular and the Bold are marked as Regular.

I cannot fix them without breaking other things.
The fonts are not standard OpenType, they are Apple AAT fonts.
The features are in tables that are not standard OpenType (e.g. feat, morx, etc.).
My tools will either delete these tables, or try to convert them to standard OpenType.
Which is going to break some functionality.

Note: Affinity does not support fonts like this, so these fonts are probably not going to work as expected.
So you should find another font.

Another thought: does the Affinity shaping engine even support the Khmer script?
And it requires certain OpenType features which may not be supported.
Has anyone here seen a user using Khmer?

[kenmcd]

1 hour ago, thomaso said:

5 hours ago, kenmcd said:

Most likely the style linking is broken.

Apple does that.

macOS Mojave 10.12 with Khmer MN.tcc v.14 (2019):

Not sure what you are trying to show me here.
That is confirmation that it is not working properly.

[thomaso]

44 minutes ago, kenmcd said:

Not sure what you are trying to show me here.
That is confirmation that it is not working properly.

Yes, that is what it was meant to illustrate. (and possibly may have avoided a need to install macOS Sonoma)

[kenmcd]

23 minutes ago, thomaso said:

(and possibly may have avoided a need to install macOS Sonoma)

Oh, thanks.
I installed Sonoma in a VM a couple weeks ago, but have not yet downloaded all the supplemental fonts, etc., etc. Been putting it off. In a lot of the fonts all they do is change the version number (which just appears to be a way to track back to the OS version). And apparently I missed downloading all the Ventura supplemental fonts (missed that one). So I just checked the ones from Big Sur which I did already have.

[lacerto]

Emboldening and italicizing (done either via the shortcut Ctrl/Cmd+B or Ctrl/Cmd+I, or a toolbar button), is broken in Affinity apps anyway and only works in simple cases (like families that only have four styles). Even if the font has proper style linking defined, like Myriad Pro (a pretty complex style linking across 40 styles in the family -- the font is by Adobe so style linking is impeccable):

A typical issue is that emboldening and/or italicizing might work, but it is not a proper toggle because turning off bold or italics activates a different styling from what was the initially used. Or, that emboldening and/or italicizing fails in the first place and are linked to wrong fonts. Sometimes key shortcuts work correctly but the buttons do not. 

Style linking does work properly e.g. in Adobe apps, CorelDRAW and Microsoft apps (and LibreOffice apps of which I have only checked Windows versions), also on macOS where such style linking is not that common.

But in Affinity apps, this is what happens, on either platform (the recording is on Windows):

As mentioned, sometimes keyboard shortcuts and styling buttons give different results in Affinity apps (but in case of Myriad Pro Light, the results are identical). This issue has been demonstrated years ago but I am not sure if it has been reported; if not considered "by design", it is probably one of the last ones in the list of issues to be fixed, especially if it is true that Affinity apps are "macs first", as has been suggested. Just for a reference: in Pages the Bold button also switches Light style to Bold (not Semibold as it should), but when toggled, the correct initial style (Light) is reverted. I am 100% sure that this is the way Apple thinks the "Bold" button or shortcut Cmd+B) should work (ignoring style linking which is likely to be considered a legacy Windows feature from the times Windows had inadequate methods for font enumeration in menus and presenting different styles under a common family name; traces of this can still be seen e.g. Microsoft Word, which does not even try to use common family names but nevertheless maps styling links correctly).

[kenmcd]

On 4/2/2024 at 12:38 PM, kenmcd said:

Another thought: does the Affinity shaping engine even support the Khmer script?
And it requires certain OpenType features which may not be supported.
Has anyone here seen a user using Khmer?

To answer my own question...
Khmer script appears to be working in APub.
I tested the Noto Sans Khmer Regular font with some GF demo text.
It appeared to be shaped correctly.
Not an extensive test, so there may be issues, but a Khmer expert is needed.
 

[lacerto]

Khmer Bold does not have Bold style link, but Regular, and both fonts also use the same regular weight class (400) so Affinity apps basically behave as expected of an app that reads style links (even if in many cases incorrectly).

On Apple, however, many apps seek bold version of the font by using the Style name, some possibly even Full name (or PostScript name), when Cmd+B or Bold button is used, even without style and weight class linking. This happens e.g. in Word and Pages (which basically does not even list the font, but recognizes it if pasted via Clipboard).

I corrected the errors in the font styles and generated new ones, but could not get them display right in Affinity apps (probably because of issues with the Khmer script); the fonts behave correctly in InDesign (including styling link behavior) but none of the glyphs show in Publisher. This is in many ways a "typical" macOS supplemental font, with non-standard font meta data.

[Alfred]

44 minutes ago, lacerto said:

This is in many ways a "typical" macOS supplemental font, with non-standard font meta data.

I think the word you’re looking for is ‘incorrect’! The weight class Regular/400 is inconsistent with the Bold descriptor.

[Handyann]

Threads here do get complicated! I’m afraid a lot of this discussion is over my head, but I appreciate the time and effort. The Khmer font does work in APub and it also will provide a Bold version if the drop-down at the top left of the page is used. I guess I’ll just stick with that 🙂

[lacerto]

1 hour ago, Alfred said:

I think the word you’re looking for is ‘incorrect’! The weight class Regular/400 is inconsistent with the Bold descriptor.

Basically yes. But as far as I know Apple deliberately messes up with especially supplemental fonts, possibly against misuse (illegal copying). Who knows...

E.g., as mentioned, when I initially extracted style corrected versions of Khmer MN using FontForge, and tried them on Windows, the fonts did not work on Windows version of Affinity apps (but did work in InDesign). When I later regenerated these fonts using FontLab 8.3. (and on macOS), these versions worked otherwise fine in Affinity macOS apps (including styling links), but nothing at all is shown in the Glyphs panel. I think these oddities are related to crippled meta data in these fonts.

UPDATE: This demonstrates what is mentioned above:

The issue with the Glyphs panel could probably be fixed by adding Unicode ranges and Codepages in font metadata, but then it is a pretty much a mystery why the FontLab created versions will not install on Windows platform at all (but FontForge extracted versions did, and also worked without issues in InDesign).

UPDATE2: I only just noticed comments by @kenmcd above as for the Apple AAT fonts and non-standard tables. This obviously explains the issues with Windows installation and the Glyphs panel.

[lacerto]

I now created versions using Glyphs 3, and these show basically correctly in macOS versions of Affinity apps (even if show bigger leading than defined), including showing correct style link behavior. The Glyphs 3 versions also install on Windows and behave more or less correctly in InDesign. But then show badly corrupted in Affinity apps!