When Windows is upgraded from older versions of Windows to currently supported versions of Windows, previously available fonts might no longer be available post-upgrade. Many of the fonts that were previously shipped with Windows were moved to the optional features of Windows to:
optional fonts aren't enabled by default. As a result, these fonts are missing from the system. If documents were created using the missing fonts, these documents might display differently in the updated version of Windows.
If these fonts are needed, you can add them back to your system via optional features. The removal of these fonts is a permanent change in behavior for Windows, and it will remain this way in future releases.
To add the fonts associated with a language and then switch to that language, first open the Language & region pane in the Settings app by selecting the following link:
The desired language should now be available in the drop-down menu next to Windows display language. Drop down the Windows display language menu and select the desired language.
Below Windows display language the message Windows needs to sign you out in order to apply your new display language. is displayed. Select the Sign out button to finish applying the language including the additional language fonts.
The desired language should now be available in the drop-down menu below Windows display language. Drop down the Windows display language menu and select the desired language.
If fonts associated with a language are needed but aren't needed across the entire system, then that language should be added to the user profile as a supplemental font. Adding a font as a supplemental font doesn't require the user switch to that language. Adding a font as a supplemental font can be done via the Settings app.
The navigation steps, UI elements, and UI text in this section are based on the latest version of Windows 11 with the latest cumulative update installed. For other versions of Windows 11 that are currently supported or don't have the latest cumulative update, some of the navigation steps, UI elements, and UI text might be different. For example, the Optional features pane might be located under Settings > Apps.
The navigation steps, UI elements, and UI text in this section are based on Windows 10 22H2 with the latest cumulative update installed. For other versions of Windows 10 that are currently supported or don't have the latest cumulative update, some of the navigation steps, UI elements, and UI text might be different. For example, the Optional features pane might be located under Settings > Apps > Apps & features.
@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
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').
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.
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.
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?
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.
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.
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).
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.
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.
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.
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).
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!
Font Book Preferences have the Default Install Location as "User" but if you have local admin rights you can use "Computer". You can setup Font Collections in Font Book and enable and disable all the fonts in a collection as well as individually enabling / disabling fonts.
I normally don't use auto activation since there's too much money at stake in prepress to end up unintentionally using the wrong font(s) for a project. You normally never know if the client supplied modified fonts, and rarely tell you if they did.
Otherwise, I've had a couple of long email conversations with prepress folks who say the auto activation in Typeface works very well. It also works without having to wait for plug-in updates, as you do with FEX. And last time I looked, Monotype still hadn't released updated plug-ins for the 2022 CC apps.
4a15465005