kenmcd

I set FontLab to change the glyph names to "friendly names" on import (opening) of the font. Then I changed the font name and had FL recalculate all the name fields properly. These alone are not going to "fix" anything. The default settings on export are to set the glyph names to "production names." This also means FL is going to rebuild all the character maps (in cmap table). And FL is going to delete things and fix things automatically to improve the font. I do not know which exact "fix" enables APub to work correctly. So open the font, change the name, and re-export the font - should work with the FL defaults. FontCreator has similar defaults. So you should be able to do the same thing. Just a little more complicated to change the font name correctly. Note: again, the problem is not the font. The problem is APub not handling some CID fonts correctly. This is not the only CID font which does not export to PDF properly. Other text engines have no problem with this font.

@gatesphere Font is not the problem - it is Affinity not handling it correctly. Modifying the font to change the glyph names to "production names" worked. But FontLab "fixes" or changes other stuff so not sure exactly what helped. FL deleted the old EBDT table (with old bitmap characters). And it deleted the old legacy kern table. And rebuilt the cmaps. So not sure exactly what the problem is that this fixed for Affinity to work properly. It is still a CID font. In another issue Affinity was using glyph names as a sort of shortcut in another OpenType problem with ligatures which were not working properly. Maybe the glyph names confused APub. Or it just does not understand CID fonts 100%. Dunno. I will send you the test font via PM so you can test yourself. Works for me. The name is changed so you can install it at the same time as the original. Note: This works, but APub still does not work correctly. If you copy "Mineral" from the document (with the small caps), you should get "Mineral" - with upper and lower case. But you instead get "MINERAL" - which is wrong. This is something APub annoyingly does with various OpenType features - it actually replaces the underlying characters rather than just the glyph displayed.

@gatesphere What version of Cambria Bold are you using? This probably another case of APub not handling CID fonts correctly. The cmap is correct but the ToUnicode is not. There was another issue with CID font in the last week or two where it appeared we may have identified why some CID fonts work and some do not. Have to find that post. On my phone at the gym right now so I will not be able to look closely at this for few hours. Also I can convert this from a CID font to a name font to test. Think that will make it work. Will try this later.

Merriweather Light is not spaced like that. Is that the original PDF opened in APub? The tracking is way off - which happens when the original has excessive tracking or loose justification. Check the Paragraph panel and reset the tracking. The editor has to guess what is an actual space character and just white space. There is no text flow in a PDF. The app has to guess when reconstructing it for editing. And the way the PDF was originally created will affect this. Including justification and tracking. And if actual space characters are used or just extra white space. Some PDF editors are better than others in reconstructing the actual text flow. So try different editors. Some PDF editors will export just the text - which may be better than cut-and-paste. Note: If you what to remove all formatting and special characters, paste it into a plain text editor, not a browser or other app. Having the original PDF would help.

@thepaperwings Your screenshots show the font selected is Arial - and Arial does not have Korean characters (or any other CJK). So there are some substitutions happening. Please attach your test document and a PDF of that document. Then we will have a better idea of what is happening. If the language selected for the text is Korean there may be a substituted space character, which could be causing justification and hyphenation issues (because of an Affinity bug).

That is a bit odd. I have this extension in both Firefox and Vivaldi (chromium). As I mentioned above... You just select the text, right-click, select Font Finder, and Analyze Selection. Here it is being used on your post above: Ahh... I think I know what happened. Make sure you have "Font Finder (revived)" (which is updated) https://addons.mozilla.org/en-US/firefox/addon/font-inspect/

I use a browser extension called Font Finder. You just select the text, right-click, select Font Finder, and Analyze Selection. Shows you the font(s) specified, the actual font used, if the font used is the web font or your locally installed version, etc. For example, I selected the "Font Finder" text above and got this:

Hmm... I did not have any duplicates installed and was seeing the same issue. So I assumed something else was happening. Did not see anything odd with the fonts. (otherwise these are really nice fonts) The fonts have unusually long names - especially the Extra Condensed. This can happen with Extra Condensed and Semi Condensed, or Compressed, etc. The font names are much longer than the typical "best practices" length. (kinda surprised Google Fonts let this by as it does not meet their guidelines) So... I shortened the font names and tested again. That works with your test document. All I did was change the font from Sofia Sans Extra Condensed SemiBold Italic to Sofia Sans ExtCond SemiBold Italic and exported the PDF. And this is the result: Here are the ExtCond fonts to try it yourself: Sofia.Sans.ExtCond.renamed.shorter.zip So it appears the long font names were confusing Affinity.

I looked a little closer at your Word docx and the text has superscript enabled in the Font tab. So apparently Affinity picked that up and enabled Superscript. That particular font does not have an OpenType Superscript feature, but it does have the Unicode superscript n character. Which Affinity annoyingly substitutes.

Looks like you have Superscript enabled. Select the text and then check the Typography panel.

Just an FYI. The "Source" font families are OFL - I know the "Pro" is a bit misleading. When they updated the fonts awhile back the "Pro" was deleted. Because the fonts were far beyond in features what Adobe typically called "Pro." Source Sans Pro (v2) became Source Sans 3 (v3). https://github.com/adobe-fonts/source-sans/releases Source Serif Pro (v3) became Source Serif 4 (v4). https://github.com/adobe-fonts/source-serif/releases So to get the same "Pro" fonts - get the earlier versions on the Releases pages. LibreOffice used to include the "Pro" versions, so lots of people still have them. They have now stopped including the Source families. Note: I use Source Serif 4 as my daily default text font in most docs. So I watch them closely. Nice fonts. Take a look when you have the time.

Variable font named instances should act the same as static font styles. They don't in Affinity - which is a bug. And they should be interchangeable between static and variable (when the family name is the same like in GF variable fonts). They are not in Affinity - which is a bug.

MainType shows that you have the font installed in both the Windows Fonts folder and in your User Fonts folder. This will cause issues in Affinity applications. So delete the fonts from your User Fonts folder.

This should work. Please post this in the appropriate bugs forum. With more information - including the font, the OSs on each system, etc. Include Affinity application and version numbers on each system. A sample doc would be helpful.

Are you using a VPN? The Affinity activation service may block VPN access (IIRC).