kenmcd

Had thoughts/explanations in response to your post yesterday, and the new post today - but just don't feel like contributing to the Affinity forum today...for some reason...

Should be grayed-out and do nothing if there are no Character Variants. And as you say, be highlighted when there are.

Some of the "features" are actually OpenType (OT) features and some are constructions by the application. For example there is no All Caps feature in OT. Character Variants (cvNN) is an actual OT feature which Affinity does support when it is actually present. To test take a look at the fonts Charis SIL and Junicode. They both have OT Character Variants. ID does not support cvNN at all (there is an add-on available which does). Affinity only shows the actual OT feature Access All Alternates (aalt) if it actually exists in the font. Adopey apps construct this (whether it actually exists or not in OT) and that is what is displayed in the alternates pop-up. Groovy Script actually has an aalt feature and the font developer actually created it manually (more advanced font editors can create it automatically). Pluses and minuses - Automatically may create duplicates and odd exceptions - Manually may miss alternates but could also be a well thought-out and better. It appears there is a newer version of the font with more features than the version I have (v1.000). Regarding the Stylistic Sets (ssNN) - it appears the newer font may have multiple alternates on the ssNN (like on cvNN). Junicode 2 has started doing this. Because they have more than ss01-ss20 (and do not want to exceed ss20). Some apps will work all the way up to ss99 (APub, ID, LibreOffice), and some fonts will use up to ss99. And some apps will only display up to ss20 (Word). And some do not work with the ssNN variants. Since ID does not support OT Character Variants at all, I assume it also may not support variants in Stylistic Sets. And on and on... Would have to see the newer font to determine exactly what is happening. Additional thoughts... - applying some OT features will block other OT features (depends on the order inside the font) - fonts may have errors/bugs in the OT features. The more complex the font, the more likely there are issues.

And there are free Morse code fonts... which could follow a curve. If you want to actually write something.

If you add any more fonts from that family, check your PDF export again. The BoldItalic will probably be in the same family as the RegularItalic. And the Bold and Italic buttons may not work as expected. So always check your PDF output. They are really nice fonts... except for the name issues. Appears the developer only focuses on ID and Adopey (and only tests there). If I was going to use them in something important, I would fix them first. So just keep an eye on it. Good luck!

The good news is it looks like you have the OpenType feature Scientific Inferiors (sinf) enabled on the Index text. So turn that Off in the Typography Panel and you should be fine. Pensum Pro is an advanced text font - with lots of OpenType features. They linked both Subscripts (subs) and Scientific Inferiors (sinf) to a full set of figures, currency signs, lowercase a-z, punctuation, dashes, etc. (61 glyphs). The bad news is - the names are even more of a mess than I initially thought (looked closer today). And if you are using the OTF fonts, they could be even worse (more name fields). I only installed the Regular, RegularItalic, and Bold. Messed-up names fields can result in the wrong fonts in a PDF. So test Export to PDF now. If you have any issues, please come back.

Send us a test doc. My thing is fonts. @MikeTO is an expert in TOCs. So together we will figure this out somehow.

If you can disable the Italic, you can try that. Shut down Affinity first (so the font cache will be rebuilt when opened). Then disable or un-install the Italic. Then restart Affinity and see if the TOC is OK. If the TOC is OK, then a name conflict is probably the issue. If the TOC is not OK, then my guess was apparently wrong. The Pensum Pro has "Regular Italic" in the Typographic Style name. Usually this is just "Italic". This may be confusing Affinity. And both the Full Font Name and the PostScript Name fields also include "Regular" in them. Also may confuse Affinity. When Affinity gets confused, odd things happen. I could test it locally with the local fonts with a test document. And I could test-modify the Italic and see if the issue goes away.

Which Pensum style did you assign to the TOC styles? And which Pensum Pro styles do you have available? All? A few? (which specifically) Does it show you a version for the fonts? (the Fontstand site shows nothing) The Pensum Pro family (v2.0) has an unusual configuration with the style names which may confuse Affinity. The v1 fonts were also a bit odd, but in a different way. If you have a sample document available, I could test here (have the fonts).

Out of curiosity… what font are you using? And what is different that you like by using three periods instead? In some fonts the spacing of the ellipsis is the same as three periods. In some fonts the spacing of the ellipsis is tighter. In some fonts the spacing of the ellipsis is looser. So I am just wondering what font and what is the desired change.

None of the fonts in that repo will work properly in Affinity or any application which looks at style groups - the Bold and Italic buttons depend on this. They have not been fixed. The other repo I was thinking about called them "for Windows 10," and added TTF versions, but I just checked and he also did not fix the fonts. There are ton of name conflicts. So if you install them all - there will be issues. Such as the wrong font embedded in a PDF, etc. Which font? - do not know any version which has 25 named instances. SF Pro variable from the developer site currently has 36 instances. It has three axes - opsz, wght, wdth The older SF Pro variable with two axes (opsz, wght) had only had 9 instances. SFNS - the macOS system font - currently has 369 named instances. Have not seen any static versions by width. If you need/want various widths - you will have to make those yourself. Text, Display, Compact, etc. are basically optical sizes they made static fonts for. It really does not matter what they did with the named instances (in any VF font). You can make what ever you want, or actually need.

That is not a combining macron (it is the legacy spacing version). The font does not have the combining macron character. That is the problem.

TW Cen MT is "inspired" by Futura. So any more extensive Futura family will have those characters. Also any alternatives to Futura - search for "Futura alternatives"

That is odd. U+0301 is acutecomb - the "correct" glyph to use these days (for combining) But Foundation Mono (that I have, v1.071, TTF) does not have that non-spacing combining character. It only has acute which is U+00B4 - which is spacing (it has a width) And E (U+0045) has no anchors for a non-spacing combining accent to attach to. The font has no combining accents to attach to any anchors. No anchors in the entire font (that I have). Maybe Affinity, or the PDF library is just confused by this. But... it does seem to work on Windows. Dunno what's goin' on. EDIT: maybe that is it - macOS changes the single character to components (for some unknown reason), then the font does not have the combining accent (acutecomb) so Affinity/PDFlib guesses that it should use what it does have (acute) - which being a spacing accent is going to have a width - and be placed after the E - which is what we see. Dunno. Current WAG.

That appears to be a difference between macOS and Windows handling of that character. File name: Single-char-É--Two-chars-E´.afpub

No. In this case... In one font editor I enter either the Unicode code point or the glyph name. Then copy the character from the preview text. Which is what I did because I had Foundation Mono already open in that editor. Or in another editor just select the glyph and then copy the character by code. The Windows Character Map app can also copy by the correct character code. I assume there is a similar app on macOS.

Interesting. Wonder how Windows handles this. I use English so I am normally not typing filenames with accents in them. Sounds like Affinity could help by "normalizing" the file names when input.

That is interesting - I checked and it is Foundation Mono (good call). That font is not installed on my Windows 10 system either. And it is not a default font on either macOS or Windows. Which means that the font is embedded in the Affinity applications. Or maybe in the PDF library. Very interesting.

I think what is happening is your file name actually has two separate characters for É - the E and the acute. This is probably caused by how you type that character (and your keyboard layout). And since the file name does not go through the text shaping engine, those two characters are not combined into the single Unicode character (U+00C9). Normally the text shaping engine combines these two into a single character. But the file name is not processed by the text shaping engine. I tested by putting the actual single character É (U+00C9) in the file name. (copy this text: Étiquette) And it works fine like that. So change the file names to have the single character, not the base + an accent.

Ahhh... another troll to join ranks with the CityRodent.

Sounds like you also installed the variable fonts. Cannot have the variable fonts installed at the same time (with Google Fonts fonts). There are name conflicts between the variable instances and the static fonts. So, no GF variable fonts at the same time as the statics. And Affinity apps cannot use the variable font anyway. Yeah. These are really nice fonts. Definitely one of the better GF text fonts for sure.

SVG files are text file - open it and look. It appears the font family is Open Sans, and it is probably the Regular (so select just that). The original Open Sans Regular font only has "Open Sans" in the PostScript Name. No Regular weight is listed. So perhaps that is where it came from. This happens quite a bit when Affinity opens other documents (no Font Style). So just select the text and apply the Regular weight (Font Style). Note the Regular weight in the original Open Sans does not match the Regular weight in the current Google Fonts version (they adjusted some of the weights when they made the variable font). So your original document may not look the same with the newer fonts. You may want to use the original fonts if you need to replicate something.

Looks like this issue has been resolved... so, some additional info about Literata. Literata is a very nice font family. Well made. Lots of features. The Google Fonts download only includes static fonts in one optical size (12pt Text). The releases in the repository include static fonts in four optical sizes. Includes: 7pt Caption, 12pt Text, 36pt Subhead, and 72pt Display. So a lot more fonts for better typography. Latest official release is v3.103. Download here: https://github.com/googlefonts/literata/releases/tag/3.103 There is a v3.200 in-progress with some fixes, but it may be awhile before that ever sees official release. Google Fonts commissioned a commercial foundry for the fonts, and that foundry also created commercial quality documentation and specimens. So there are some useful PDF documents which you should have. Download here: https://github.com/googlefonts/literata/tree/main/Documentation

That looks like a bitmap (image) format - so it is either SBIX or Color-SVG. Neither format is supported in Affinity right now. Probably Color-SVG if it works in Word.

My main point is that these appear to be real original fonts. Not some hacked versions. Thus proving that the real static fonts do exist, and that it is highly likely that somebody at the company has them - and they should get them to you. Failing that - yes, exporting from the VF is the best option.