kenmcd

This appears to be a Windows issue. https://duckduckgo.com/?q="0x800700b7" I looked at many of the search results and did not find a definitive answer. Most of the results are regarding Windows update, not installing applications. Some of the results are regarding the Windows Store. What version did you install, the store version or the EXE/MSI files? If you installed the store version, try installing from the files instead.

Seravek is now one of Apple's "Document-support fonts" so it is blocked by Apple. https://support.apple.com/en-us/103197#document Affinity does not support Apple's font controls. If you search this forum for "Seravek" or "Athelas" etc. - you will find other similar discussions. The work-around is to rename the fonts (properly). Apple apparently keys on the PostScript Name.

From within the font... Versions String: Version 1.024;Fontself Maker 3.5.0 The good thing about Fontself Maker is anybody can make a font. The bad thing about Fontself Maker is anybody can make a font. Multi-mapping is a bad practice that experienced font developers avoid. There is a reason Adobe is against it and Google Fonts does not allow it. You will not find any multi-mapped glyphs in Monotype's Helvetica Now. Because support is spotty in OSs, text shapers, PDF libraries, and applications. Given that the developer used Fontself Maker means they are on a Mac. And that particular combination of OS and text shaper (Coretext) happened to work. Doubtful they tested anywhere else. I did not examine this closely enough to determine exactly what is causing Affinity problems - but my guess is the ridiculous level of multi-mapping, and including ranges, is confusing Affinity. Regardless this font is junk. I have a pet peeve against purposely broken "free" fonts. Think it is a very sleazy practice. All the characters with diacritics which were there are now mapped to just the base. Be honest. Just make a limited version and let users know it is limited. Don't mislead and confuse them by mapping all the characters they actually need for anything other than English to just the plain base character. And the curly left/right single and double quotes are mapped to the plain versions. I assume there were actual left/right versions. Sleazy. If you just gotta have this font, you can edit it and remove all the multi-mapping, and also remove the unneeded old control characters - and then it may work properly in Affinity. So if you only need Basic Latin uppercase, and some of the normal punctuation, that may be a good option. Could also take a shot and buy the commercial version. May work.

@Konrad1 The problem is the Aquire font. Wadda mess. Multi-mapping is when a glyph is mapped to more than one Unicode code point. This can quite often cause problems for applications with those fonts. Adobe strongly recommends against multi-mapping. Google Fonts does not allow multi-mapping at all in their fonts. It is a dumb idea to do it. It appears this free version of the font was created by deleting the extended glyphs, and then multi-mapping the deleted glyphs code points to the base glyph. For example the capital A glyph has 14 code points mapped to it. That is beyond stupid. And it uses ranges of code points in addition to single code points. Many applications will choke on that. This "free" font is basically unusable. It may work in some situations, but not cross-platform, and not in many applications. Could not find the commercial version to take a look at it and see if it too is a mess, but, regardless, I would not trust anything made by this "font designer."

The Typography panel shows you have Swashes enabled. Which I assume you have Enabled because it looks less swashy with it On. This font has some additional Final Forms features (which are On by default in Affinity), ... which do not appear in the Typography panel - so you cannot turn them Off. In the Positional Alternates section of the Typography panel you can only see Initial Forms (init) and Final Forms (fina) - (these) are the OpenType feature codes. And since you can see them, you can turn them Off. This font has two more "final forms" features - fin2 and fin3 - which you cannot see. So there is no way to turn them Off. OpenType specs say these features should be On by default. But, other text shaping engines default to Off for the Latin script. Because many Latin-only fonts use these features (not just Arabic & Indic, etc.). Harfbuzz (LibreOffice, Inkscape), DirectWrite (Windows, Word), Coretext (Apple, Typeface), InDesign shaper, and more - all default to Off for the Unicode Latin script for these OpenType features. Affinity needs to fix this. @DWright Affinity is the only one enabling these by default for the Latin script. They should be Off by default - or this is just going to keep happening. Affinity looks broken to users when they come from InDesign or another applications and suddenly all these odd glyphs start appearing. These should default to Off for Unicode Latin script: fina, fin2, fin3, init, medi This is at a minimum, there may be a couple others. And there needs to be a switch for fin2 and fin3 in the Typography Panel like for fina. @MsMeowy Your only work-around at this point is to use the version from Dafonts or other download sites (which have no OpenType features). Or hack the font you have.

"was typed" LOL - by whom? The Invisible Man? This appears to be exactly opposite from my initial understanding/assumptions. I assumed you, or The Invisible Man, had entered the characters correctly, and the shaper had broken it. But it appears that The Invisible Man (TIM) had entered the wrong characters, and the shapers actually hacked the display to show the intended character. The yi-cyrl (ї) U+0457 character is in Ukrainian, and not in Russian. My guess is that TIM is using an old Russian flavored keyboard layout, and has to use some old trick to enter the character. And the shapers in Word and LibreOffice are aware of this old hack, and they display the correct glyph - but the underlying characters are still wrong. Unfortunately this has the effect of standardizing the hack. When the correct fix is to correct the character input. Windows has three different Russian keyboard layouts available, and also has two Ukrainian keyboard layouts available. And there are apparently some popular 3rd-party Russian keyboard layouts. I assume there are similar keyboard layout choices available for Linux. The best fix is for TIM to use a keyboard layout or tool which enables him to enter the correct character codes, not some hack which the shaper has to hack visually. @Hangman demonstrated one working solution above. Or you could use find-and-replace to correct the characters. I hope Affinity never adds this hack to their shaper as it just perpetuates this. Affinity is just correctly showing what is actually there. What is there should be corrected by the author.

That is a major problem. Above you said: Which to me means you typed it on your keyboard into Word. But instead, you apparently received a defective file. So the source of those odd characters is completely unknown. This has been a giant waste of time.

This could be a keyboard entry issue. When I enter the yi-cyrl (ї) into Word using the Unicode code (0457 + Alt-X), and then paste that into APub it works fine. @anto What keyboard are you using?

No. Word broke it. And Affinity is just displaying what is there. This could be something which could be fixed during the Place processing of the Word file. A new test/fix to look-out-for-dumb-stuff-like-this and replace it with the one correct character. May be difficult to actually implement, but would help users and prevent issues like this in the future. Part of the problem may be in how the font is constructed. Current best practices are to only use combining accents in composite characters, not legacy accents. This could be Word's (DirectWrite's) way of dealing with older fonts which still used legacy accents in composites and did not have a dotless i glyph. Dunno. I can only guess. If we de-compose the font (make all the composites go away), it would probably not be an issue. @anto If I make you a decomposed version of that font, would you test it for us? (would probably not be until tomorrow)

Note to self: you can save a .doc file to a .docx... and then look inside. Duh. The characters for yi-cyrl (ї) in the .docx are what is coming over to APub. ibyelorussianukrainian-cyrl (і) U+0456 and diresiscomb U+0308 Kinda odd.

Yes, I wanted to take a look inside the document. But because it was .doc, and not .docx - cannot look inside. Like to see what actual characters are in there. There could also be an issue with the .doc. When I opened it in LibreOffice Writer the font is shown as: Liberation Serif;Times New Roman Which of course makes no sense. Word just showed: Liberation Serif

A font without any composites would affect this - and probably work. So I doubt it always "does not depend on the font." This appears to be a problem with the Word shaper, the font composites, and the Affinity shaper. When you say it was "entered in the normal mode" do you mean in Word? In Liberation Serif the Ukrainian yi-cyrl (ї) U+0457 is composed of two glyphs. A dotlessi (ı) U+0131 and a diresis (¨) U+00A8. That is the old legacy diresis, not the diresiscomb ( ̈ ) U+0308 which it should be. Word apparently sees this and changes the diresis to the diresiscomb U+0308 but it also changes the dotlessi to a ibyelorussianukrainian-cyrl (і) U+0456. Then apparently the Word shaper removes the dot and applies the diresiscomb. Because of that it appears to be the yi-cyrl (ї) U+0457. But when the text is copied - that is what comes over - those two characters. ibyelorussianukrainian-cyrl (і) U+0456 and diresiscomb U+0308 And that is what you are seeing in APub. In APub when I directly enter the yi-cyrl (ї) U+0457 as Unicode - it works fine. If that correct character was coming over from Word - it would work fine in APub. I am not sure if the Affinity shaper should be "fixing" this mess. That would basically be fixing a Word-created error. But that could be another help-the-users-deal-with-this situation. Word compounded the error when it replaced the dotlessi. If it just replaced the dieresis with dieresiscomb - that should work. Or replace the whole thing with yi-cyrl (ї) U+0457. (which is what I think harfbuzz does).

Looks like the diacritics are either being decomposed, or they were entered separately in the original document. If they are entered separately usually the shaper will/should turn these into the single character. What is the original font? On my phone at the moment, but can look at this on my laptop in about an hour. Note: In your movie the single dot reappears on the decomposed character which could be a font issue, or an issue with the shaper.

Here are a few... these are just a few free or came-with-the-OS fonts. There are also commercial fonts which have playing cards. Noto Sans Symbols 2 Symbola DejaVu Sans Quivira Segoe UI Symbol (Windows) Apple Symbols (macOS)

Note: regarding what I said above about "no way to type them" - you can type Unicode code points directly by switching into Unicode mode. Alt+U on Windows - it may be Control+U on Mac (I think). Since those ink splashes and fingerprints are characters with a code point, you could type them directly like that (if you know their code points).

The Olicana ink splashes and fingerprints are characters - with Unicode code points up in the PUA (Private Use Area). So you can only select them in the Glyph Browser. No OpenType feature to display them, so no way to type them. Must use the Glyph Browser. These characters have zero text width and are centered on the insertion point. They will overlay what ever they are next to. So if you insert them in the middle of a word, it may cover parts of the word. Like any font character you can convert them to shapes (they are vectors).

Affinity Publisher supports all the OpenType features used in these fonts. The only thing not supported is the SBIX font format (used by LiebeHeide). SBIX is a color bitmap font format originally used for the Apple color emoji font. LiebeHeide is now also available as Color-SVG - but that format is also not available in Affinity (yet).

The Typography panel generally is OpenType features. So I assume Titling is to enable that OpenType feature (if the font has it). Basically it replaces the characters with shapes which are better for use in titles. For an example see Adopey Garamond which replaces standard uppercase characters with different uppercase characters. More info on OpenType Titling: https://learn.microsoft.com/en-us/typography/opentype/spec/features_pt#titl What you want is Title Case.

OK. Think I see what is happening. The EPS has it embedded as ArialNarrow - the PostScript Name (like in a PDF). The SVG has it embedded as Arial Narrow Affinity Designer lists the fonts by typographic family. On Mac the typographic family for the narrow fonts is Arial Narrow On Windows the typographic family for the narrow fonts is Arial and then the narrow fonts are additional typographic styles. Highlight the text in the SVG, then Select Arial as the Font Family, and then Narrow as the Font Style. That should work. Affinity font matching could be a lot smarter and avoid stuff like this.

IIRC there are two different versions of Arial Narrow - one which has a separate typographic family and one which is in the same Arial typographic family. Think the first one was on the Mac. This may be causing a font mis-match. On my phone at the moment, but will check your EPS and SVG files in about an hour - along with the different versions of the Arial Narrow fonts.

The spacing "errors" are because space characters are often not included in PDFs, there is just open space, so the editing application has to guess where to put the actual space characters. Some applications are better than others at this guessing. And some applications help this process by including actual space characters (Affinity now does this). OpenSans is the PostScript name of the original Open Sans Regular v1.10. The PostScript Name is used when embedding font into a PDF. Newer versions from Google Fonts have OpenSans-Regular as the PostScript Name. This may have caused a mis-match on the font. The font displayed in your "Publisher - wrong" image is not Open Sans. So you will need to check that and set it correctly. Note: the newer versions of Open Sans have slightly larger vertical metrics, so even if you set the font to Open Sans Regular you will may need to change the leading settings. They probably used a fixed leading in the original PDF source. Your other images also look like different fonts. Regarding the square bullets, sometimes these are from an OS-specific symbol font (and may not even be Unicode). Sometimes they are simply not encoded properly to be displayed as Unicode compliant bullets. We would have to see your original PDF to determine exactly what is going on.

You could simply use those numbers as placeholders for the footnotes. I assume you want to recreate the footnotes. So if you place the cursor next to the "1" and then create the actual footnote the superscript "1" for that footnote will appear - then delete the placeholder "1".

If the font is embedded, yes. The text object includes the shapes and the character IDs (CID). Remember, PDF is really old, pre-Unicode, so text is identified by character ID. Which, without getting caught-up in insane complexity, is basically a glyph number. Old encodings had specific glyph numbers for specific characters - a CID. That got expanded for big CJK character sets, even when fonts were only 256 characters (called character collections). That got tweaked to support today's bigger fonts, etc. Blah, blah, blah... PDFs still use CIDs. PDF viewer applications simply show a shape displayed at specific coordinates. The shape just happens to look like a letter T. That text shape also has some text metadata connected to it. A plain shape object (e.g. an ellipse) does not have this connected text metadata. So converting the text to shapes means just dropping the text metadata. Take the text shape out of the text object and just put it in a plain shape object. And display that shape at the same coordinates. It is now no longer "text" - it has been converted to "shapes." Do not need the embedded font to be installed on the OS to do this. OK, next bit of craziness... Display vs. Edit PDF viewers just display whatever shapes are there - exactly what PDF was designed to do. Editing is where it gets crazy - not what PDF was designed to do. PDFs are supposed to have a ToUnicode table which maps the CIDs to Unicode code points. Not all PDFs have a ToUnicode table, and some that do are wrong. This affects the editing, copy-and-paste, search, screen readers, etc. The applications that do these things are using Unicode code points for the characters. Note: some older applications can use old encoding to do some of these things. But modern applications are using Unicode. We have seen some PDFs here in the forum which were created by some corporate report applications, or by some custom applications which have no ToUnicode table - and when opened in Affinity it is just a complete mess. We have also seen multiple cases where the ligatures are not coded properly in the ToUnicode table - and they do not appear correctly. What the reader or editor applications a capable of doing will affect what appears to happen. Acrobat will not let you edit a PDF if you do not have the font installed (corp. decision). Even if the whole font is embedded, and the font allows editing. Some of my PDF editors will let me edit PDFs even with just a font sub-set embedded. If a character is already embedded, I can use it. The shapes are there. So what you can do depends on the application. PDF viewers just show whatever text shapes are there (regardless of the mess behind them). Affinity always opens the PDFs in edit mode (unless it is placed as pass-thru). So it immediately wants to get the characters' Unicode codes from the PDF's ToUnicode table and then go get the installed font to render those Unicode characters for editing. This is why Affinity needs the font to be installed on the OS. The Affinity applications only work with Unicode. So if the ToUnicode table is not correct or missing - errors appear. Ironically Affinity does not encode the ligatures properly so if you open an Affinity-created PDF for editing there may be errors on the ligatures (note: have not checked this in quite awhile so it could be fixed...dunno). Adopey ID will just display what is there (like a viewer) until you click into the text box to edit the text. So it is basically pass-thru until it is edited. It would be nice if Affinity worked like this. So, yes the text shapes are there if the font is embedded. And the font does not need to be installed on the OS to convert text to shapes.

@sportyguy209 Do you have more than one Gill Sans family installed? The Font Manager shows two family names - GillSans and Gill Sans And the fonts are embedded with odd names - not Gill Sans. Such as: font000000002b052241, etc. I changed that text to the Gill Sans MT font and it exported fine.

The PDF says you are using macOS. Is the GillSans you are using the one from macOS? Going to take a closer look at this...