kenmcd

This one, IcedEarth, is so bad it is almost funny. It was based on Arial v2.45 (probably around 1990). The names for the Mac platform ID are all still Arial. The Family Name for the Windows platform ID is IcedEarth, but then they localized just the Font Subfamily Name for about 25 different languages. Which is nuts. The English - United States subfamily name is: rtising (I guess this is what you saw) What that is supposed to mean... I have no idea. Others are Normal, Standaard (sic), and various other spellings and translations. Crazy. Pudmonkey has similar issues. It was based on Times New Roman v2.00 (~1997) The names for the Mac platform ID are all still Times New Roman. Wadda mess. Applejuiced has "Original" as the Font Subfamily Name. That can confuse applications which expect standard names such as "Regular." There is a lot of other junk in these fonts like un-mapped glyphs, and empty glyphs. Just junk that should not be there. Sure there are other issues too. @AP Ltd Studio Not a good idea to install loads of online junk fonts, because it causes problems like this. There is no easy way to review a bunch of fonts and see these issues. Font editors will usually only show part of the problem, because they try to fix it. Font managers also show only part of what is there (which is causing the conflicts). I use tools which allow me to see what is there (e.g. OT Master Lite, or fonttools ttx). Older fonts from font websites should immediately be suspect. There are no quality checks at all. And many very broken fonts have been available for years, and years. I check fonts thoroughly before installing anything. Do not install a ton of unknown-quality fonts. I use a font manager to temporarily activate questionable fonts. If you really need one, install just that one (after checking it). If you just gotta have some of these fonts, you should get yourself a font editor and learn how to fix them. So if a client requires a bad font, you can fix it. As I said above... not a good idea to install loads of online junk fonts, because it causes problems like this. Yes, some applications are better than others in working around old broken fonts. But, no application can work-around all of these issues.

Those are the old original fonts - and they have different names. The names include optical sizes such as EB Garamond 12 and EB Garamond 08. And they have different OpenType features. These fonts will not fix the issue. This should work if you were using the static fonts previously. Just un-install the variable fonts and re-install the static fonts. If you were previously using the variable fonts - try the find-and-replace as mentioned above. But, IIRC, you may have a problem selecting the From font style (which is blank). Note: with the Google Fonts versions you cannot have the variable fonts and the static fonts installed at the same time.

A few questions... What version of Windows are you using? Aptos is only available via the M365 Cloud Fonts (as far as I know). And cloud fonts are not available to Affinity (or any other non-M365 applications). They can be installed for all users to work around this limitation. Have you tested exporting to PDF to see that the correct fonts are included? The six Microsoft JhengHei fonts are inside three TTC files. And Affinity applications can have issues with TTC files. So that may be an issue. You should make yourself a test doc which uses all six styles and see if the correct fonts end up in an Export to PDF. The fonts may not be working properly in Affinity. The Microsoft JhengHei fonts have localized font names. They include: - English - United States - Chinese - Hong Kong S.A.R. - Chinese - Taiwan So the localized font names may be confusing APub depending on the Word source. The language you have set in Word may affect this. You can un-zip the Word doc and take a look inside to see how the font names are included in the file - to see if this is an issue. (there was a similar name localization issue when importing an Excel doc with a Chinese font which had the localized Chinese name inside the doc - Affinity fixed this for that situation)

The fonts are embedded with the old MacRoman encoding - which is pre-Unicode. Affinity applications only understand Unicode, not this old MacRoman encoding. So it prompts to replace the un-recognized fonts. You really need an application which supports both the old encoding and the Unicode encoding to possibly convert the document to Unicode. One of my PDF editors enables you to rather easily replace fonts. I have been wondering if it would convert to Unicode at the same time (like ID does). Maybe I will try that just for the halibut. Your PDF shows it was created on macOS just yesterday using Preview app. Do you have access to the original doc? Applications on Mac tend to export PDFs using MacRoman encoding - even when modern more compatible cross-platform Unicode encodings are available (which is iStupid Mac nonsense). We could delete the MacRoman encoding (code page) from the fonts to attempt to force it to use more compatible encoding - if you have access to the doc source. I could modify the fonts. Might work.

There has been a history of errors in the developer fonts which primarily affect anyone trying to use the fonts on Windows. But it also affects many other applications which use parts of the fonts which macOS may not use. I first noticed it in the static San Francisco fonts a few years ago. The errors in the fonts were ridiculous - basically just intentional garbage. Not a configuration difference, or a platform difference - just erroneous junk. And it was there for years. So either the Apple font engineers are complete lazy morons, or they sabotaged the fonts on purpose. And there were checksum errors in the fonts so Windows would see them as corrupt, and not install them. Re-saving them from FontCreator would fix the checksums, and a round-trip through fonttools ttx would also fix the checksums. Then they will install in Windows. Many years later those fonts have since been replaced different developer fonts with different issues. I have not looked closely at the static fonts in quite awhile. But now that there is a variable version I have looked at that a bit. Because of the previous post last month I did test the variable version. It does not work properly in LibreOffice (or Word). So I looked closer and the STAT table is broken (and how makes no sense). But it does makes sure it will not work properly in any application using the STAT table. And I noticed the Weight axis is set to hidden - on what planet would that ever make sense? So there could be more problems buried in there. Have not dug into why they have 30 masters for basically three axes. Regarding the speed... or lack thereof... As I mentioned above, Affinity appears to be "doing the math" for all 30 masters and all 27,262 glyphs - that takes a long time. But that is just a guess. Other applications figure-out what is actually needed and just calculate for that. So the slowness is definitely an Affinity issue. Google Fonts' fonttools is used to create their static fonts from variable instances, and create all the various language sub-sets - and I have seen discussions there about how they have structured it to only process what actually needs to be processed. From time-to-time they discuss why something is taking so long, and fix it. Perhaps the Affinity folks should take a look at their code for ideas. The font is made to actually interact with the Apple developer API, not graphic design applications. So that API talks to or interacts with the font in a particular way. I am not a programmer but I do remember looking at some of that API stuff, back when it was only static fonts, where the programmer was really not talking to the font, but the API handled everything. If the developer specified some specific user interface element, such as a screen heading, then the API knew to select the Heading font (designed with the 28pt optical size). That is now a bit different with the variable font. It does have 36 named instances, but they are all 28pt optical size. So the API must be doing something directly for the smaller sizes. Suppose that is all in the developer docs somewhere. The new actual macOS interface font is really crazy. System Font (SFNS.ttf) which does not show in Font Book (hidden). Four axes, 75 masters, and 396 named instances, but it only has 2,935 glyphs. The latest incarnation of the SF interface fonts. Hmmmm... have not tried that in APub. I assume it would also be kinda slow. Dunno.

Are you using the variable fonts or the static fonts? I think this slow export to PDF is only for the variable fonts. Affinity v2.0.4 did not support variable fonts. And tracking issues is a common problem when using anything other than the default master (which is what you would get from v2.0.4) in an application which does not properly support variable fonts. Point being that there would be differences in tracking when the correct tracking is applied when variable fonts are supported properly. Note: there is another thread regarding APub not properly interpolating the kerning - which would also affect "tracking." The test page below was created last month (2024-06-24) after this font was discussed in another thread. The test page includes all 45 named instances (styles). It took about 15 minutes to export. Part of the problem is the complexity of the font (and possible bugs/sabotage). And part of the problem may be Affinity. My guess is Affinity is processing all the glyphs and all the masters. When they only need to process what is actually being used. This appears to be a problem with other complex variable fonts as well. The same test in LibreOffice took less than a minute to export to PDF. But the test in LibreOffice did not include all the named instances - because Apple purposely sabotaged the stat table in the font. Apple has a history of purposely sabotaging the developer fonts. But even then, the export to PDF took seconds, not minutes. Suppose we could delete a bunch of crap from the font to test. Delete about half the masters, and delete the 10,000+ symbols. And delete the two non-standard tables in the font. But not telling what else they broke (on purpose). And we may figure-out what is going on, but you still cannot use the fonts. But why do people want to use this font? There are alternative interface fonts. (such as Inter, free and open source, and you are reading it right now). And you cannot use it in any publication (the license prohibits it). Why is anyone using this font?

Sometimes it is possible to work around some of these "confusion" issues by only having the few fonts actually being used installed. Un-install the rest.

Appears to be combination of bad fonts and bad Affinity. Those fonts from that old Linotype collection 1.7 are just quickie conversions from old Type 1 fonts into TrueType fonts (because we need to support TrueType now in 2002). These are actual old TrueType, not OpenType-TT. Original TrueType. Which means no OpenType features at all. And they use the old legacy kern table for kerning data. Affinity does not support the old legacy kern table. Which means no kerning at all. Antique fonts simply do not work well. There are some non-vanilla style groups - which confuses Affinity. There are also some errors in the fonts - which further confuses Affinity. Also note how some of the font family names have spaces and some do not, and that some of the say "Sans" and some say "San" in the family name. This is because some of those fonts came from ITC and some came from Linotype. They are just a quickie "we need to offer some TrueType fonts" mess. Note how some of the PostScript Names in the PDF show "TT" - this what they did when they started converting Type 1 fonts to TrueType. And you can also see the "OS" for Old Style figures, and the "SC" for Small Caps - like they did in the old separate Type 1 fonts - because these are just quickie conversions. Not worth the time to fix those fonts to work correctly. You would end up with a very limited fonts with limited kerning. Around 2004 they did come out with ITC Officina Sans ITC Std - which is now an actual OpenType font where the oldstyle figures, and the small caps, and the kerning are now incorporated directly into the fonts. But these still have some of the name and weight bugs, and the multiple style groups which Affinity cannot handle correctly from those antique fonts. So they would have to be fixed to work correctly. And I do not think this version is for sale anymore anyway. The Pro version from 2006 (the v1.000 I have) fixed the name and weights bugs, and now has only one RIBBI style group, so it should probably work correctly in Affinity. The current Pro version in MyFonts is v2.000. Do not have that one so I do not know what else they have done. I do not know your end-use for these fonts. Maybe fixing the fonts you have in FontCreator (or FontLab) may be enough for you. Either will convert the old legacy kern table to the OpenType gpos table. But still, the ~1,000 kerning pairs in those old fonts vs. ~20,000 pairs in the Pro fonts. If you have an important, complex, long-term project, where quality is important, I suggest updating the fonts to a modern version.

Not sure exactly what you mean. I always rename fonts I have modified/fixed so they are not confused with the original broken fonts. And so they can be installed at the same time as the old broken fonts for comparison. The font could be renamed back to the original name, BUT... If you are hoping that will fix the older PDFs created with the original broken font, that will not work. The characters embedded in the old PDFs are encoded in a manner that the new font will not be able to connect with and display properly. So if that is what you wanted to try - it is not going to work. Or do you have a different question? Glad to hear it does work now. You may want to try some more up-to-date fonts. Architects Daughter comes to mind (there are others similar). https://fonts.google.com/specimen/Architects+Daughter Similar style, but it has a full character set (351 characters vs. 214 characters). There are a few other up-to-date handwriting fonts with a similar style in GF.

Try these: CityBlueprintAF.zip Includes both OTF and TTF. Do not install both at the same time. As mentioned above - missing characters, no kerning, no OpenType features. But no longer a Franken-font. Now a proper Unicode font. So they should work, and should import from a PDF properly.

Older applications which have been around much longer had to support fonts with the old Mac-Roman encoding - so they understand it. Keep in mind this is pre-Unicode. The characters are identified by a standard glyph ID (GID), standard glyph names, and a standard glyph order, not by a Unicode code point. When a font is embedded in a PDF using this ancient Mac-Roman encoding, Affinity applications cannot read it because they do not understand this old encoding. Many applications (i.e. ID) read this old encoding and automatically convert it to Unicode. Affinity should be doing this. It is not hard to do. This is why you can take an old PDF document with text that has Mac-Roman encoding, copy the text, and paste it into Apple Pages - it is automatically converted and it is now Unicode. Which you can then paste into Affinity, and it now works. This is a no-brainer that Affinity should be doing to help users. The font also has Microsoft Symbol encoding - which is why it does not work properly. A note from the FontLab docs may help... Windows normally handles "symbol fonts" in a special way. But TTF Franken-fonts still kinda work. But OTF Franken-fonts do not work. Try the OTF Franken-font from your azfonts link above. Will not work at all (you will probably see garbage, or a fall-back font). This Microsoft Symbol encoding is completely wrong in this font. If this font had been converted correctly, the Windows platform encoding would also be a text encoding, not marked as a symbol font. This font is very broken. AutoCad has been around a long time and apparently understands the old Mac-Roman encoding. So it could make a PDF with text embedded with that encoding. But Affinity cannot read the Mac-Roman encoded text from the PDF. ID could open this PDF and read the text correctly (and convert it to Unicode). Maybe I'll take a look at fixing the font... FontLab is pretty good at converting to Unicode based on glyph names. But there are errors in the glyph names that would have to be fixed manually. And usually you end up with a font that is missing many required characters. And no kerning, and no OpenType features. Maybe not.

OK, have checked the versions I found on free font sites, and all are Franken-fonts. Never going to work correctly unless fixed. Not that I am aware of - @Alfred what makes you think this?

@afmonroyf Please attach the font.

I love a good font mystery... Based on the many versions I found online - my guess is this is a Franken-font. Where the Mac encoding is Mac-Roman text and the Windows encoding is as a Symbol font. This was caused by bad conversion software back then (1996) when converting old Type 1 fonts. On my phone at the moment so I cannot look at the fonts closely - will be at my laptop in about an hour and a half. @afmonroyf Need to see your exact version of the font. Please just attach it here. (It is on every free fonts site and has been for years).

Adobe Garamond Pro has a Th ligature in the Standard Ligatures. So a line starting with "The" will have an OpenType substitution at the beginning. Since Standard Ligatures are On by default it will affect the sample text. Default figures are Tabular Lining.