kenmcd

There are actually two hyphens in the SVG. One hyphen is the soft hyphen (00AD). The other hyphen is the hyphen-minus (002D). Arial has both of those characters (code-points) mapped to the same glyph. So Word is just showing what is actually there in the SVG. Some fonts have no glyph there for soft hyphen (00AD), so nothing appears. This some-have-it, some-do-not has to be handled by the applications. Some applications display nothing for soft hyphen (00AD), even if there is a glyph in the font. That would explain why QuarkXPress, and Inkscape show only one hyphen. Affinity apps should not be including both of those different hyphens in the SVG. So that is a bug. May be technically "correct", but the result is bad. Which is why other DTP apps, and browsers, do not show the 00AD.

Oh, you are right - was looking too fast - at the smoothing option. But APub does not always display exactly what the "finished product" is going to look like. It is adjusting the display to show you lines which if set to actual scale would be less than a pixel (on that particular display, at that particular zoom level). This is exactly what the PDF editor/viewers are attempting to do with the thin lines setting. This also happens with particular fonts which have very thin points in their contours. The thin spots can be less than a pixel and it just disappears onscreen. The fonts may have built-in hinting which will compensate and widen the stem. And the PDF viewers will also try to compensate (this same issue has come up related to fonts). The only way to get true WYSIWYG is by having enough resolution to show exactly what is there. It is the exact same same situation as the font hinting distortions, and on Windows the ClearType changes in text color, and on Macs the increased text color (darker) text at smaller sizes caused by their built-in hinting algorithms. All are distortions caused by software apps trying to compensate for the mis-match between actual dimensions being forced into a pixel grid. All of these issues go away when there is enough pixel density. If your screen had the same resolution as your printer (or PDF) none of this would happen.

Other PDF Editors/Viewers which enable you to turn-Off the thin line enhancement: - PDF-XChange Editor - Foxit PDF Editor - Foxit PDF Reader - Nitro Pro Basically, any more advanced editor/viewer has this setting. Note: the default setting for this in Acrobat is On, just like the others. There is no setting which can be passed by Affinity apps to the PDF viewer to change this. The reason the "thin line enhancement" setting exists is to help compensate for users not having enough display resolution to display the lines at a given zoom level. On a fairly high-resolution display your sample.pdf looks fine. With a 266ppi display at 300% I can see all the individual lines in the lower building, on a laptop. So the solution is simple - just get a huge high-resolution, high-ppi display. I say that in jest, but given the type of drawings you work with it may be worth it.

Three of the fonts in the Museo family are free. Museo-700 is one of the free ones, and it can be embedded. The free fonts can be downloaded from FontSpring, MyFonts, etc.

Yeah, I tend to focus on which ones give me the most control over font embedding (i.e to force embed everything, etc.) and do not pay much attention to the others. So I was just curious. Some of the ones I have probably work that way. :-)

Which ones only print images? I have a bunch of PDF printers installed and I am not aware of any which only print images.

Segoe UI Emoji is a COLR color font. So when support was added for color emojis it also added support for other COLR fonts. The support is not 100% as you cannot select a palette (if the font has more than the default), and there is no support for changing the colors (even if the font supports it). But COLR color fonts do work in Affinity apps now. For example this was created in the current version of APub:

Can't you just Export-to-PDF that one page from the other application? Even printing to a PDF printer should preserve the text and embed the fonts properly. So, you are right, I do not understand what you are doing, or why. Calibri does have standard ligatures for ti, tt, and ft. Your PDF writing application may or may not be encoding those in a way that can be imported. The only way to tell is by looking at the actual original PDF text to see the codes behind it. Then we can tell if it is a problem with APub or the writing app. Note: one work-around is to disable the standard ligatures in the source app. That way individual characters (not ligatures) get embedded in the PDF. Then when re-opened in the target app those standard ligatures will automatically re-appear in the text.

Nothing to do with the fonts. Your "original" PDF above has no text in it. It is a bunch of oddly spaced drawings. Try to "find" any word; you will get nothing in the search results. Try to highlight text to copy it - nothing. I have no idea how Affinity is getting any text out of that. Also look at the spacing in the first paragraph. It is not left-justified. It is not fully-justified. It has a bunch of weird spaces between the words. So Affinity is guessing how to put it back together into actual text. The issue appears to be with the original source.

Other programs do have issues with these fonts. The fonts may appear to work OK onscreen until certain other actions are performed - such as importing or pasting from another app. The target app is going to be looking at different name fields inside the fonts to determine the correct font. Some apps use the style group Family Name (LibreOffice, Word, Linux apps, etc.), other apps use the Typographic Family Name (Affinity, InDesign, QuarkXPress, etc.). The Typographic Name is wrong in these fonts. Importing from a PDF is going to use the PostScript Name (also wrong in these fonts). Export to PDF is also going to be affected as that embeds fonts based on the PostScript Name - which is Arial MT in the WtlGreek font. To work properly in all situations, and not cause conflicts with other installed fonts due to duplicate names (such as Arial), the fonts need to be fixed.

WtlGreek is a modified version of the old "core" fonts that Microsoft released as free fonts years ago. These are the fonts in the Linux Core Fonts package. The problem is they left the old font names in many of the name fields inside the fonts. This is why it is getting confused with Arial, because many of the name fields still say "Arial MT" - such as the PostScript Name, Unique Font Name, etc. The fonts would need to be fixed to ever work properly.

@Marcos M. It sounds like you have font cache corruption issues. This can be caused by installing bad fonts, installing duplicate fonts, etc. First, un-install the broken Gilroy fonts. That pointing hand icon in the font name means the person who ripped those fonts did not know what they are doing, and they did not bother to fix the broken names. This kind of fonts typically have many duplicates in the font name fields which can cause font cache corruption. Also it may cause the wrong font style to get embedded in PDFs. These fonts will never work properly in any application on any OS. Next, only install fonts in the system fonts folder (not your user fonts folder). When you use the Windows Font Viewer and click on the Install button, it installs the font in your user fonts folder. Always install fonts by selecting the files, right-click, and select Install for All Users - that will install them in the system fonts folder. Next, make sure you do not have any duplicate font files present in the system fonts folder. Look for any font file names which have a number suffix on them (e.g. font_01.ttf). If you find any, un-install the fonts, delete the leftover font files, then re-install.

The "different name" deal is when there is a "reserved font name" (RFN) in the OFL file. The older non-pro version has a RFN, but the newer Pro version does not. Google Fonts no longer accepts reserved font names in the fonts they host. So you will only find it in some really old ones (like this one). Took about a minute to paste the hyphenminus into the hyphen. AndadaPro-Regular-modified-hyphen.zip So give that a try.

Garamond on Windows is installed with MS Office, not with Win10 or Win11. And it has been v2.40 since Office 2007. Still the same version in current Office versions. @erwik Please attach your document so we can take a look. EDIT: Also please export the doc to a PDF from both operating systems. Then we can see what fonts are actually getting embedded.

Yes, this "feature" is quite confusing, and does not seem to make sense in the real world. Example: the auto-replacement is Off for Arial because it includes an OpenType Standard Ligatures feature - even though that feature does not include any Latin characters (no ff). Then when the user disables Standard Ligatures, the auto-replacement then gets turned-On and it takes over and replaces the ff with the ligature character. So ... - Standard Ligatures On - no ff ligature appears - Standard Ligatures Off - ff ligature is applied Gee, how could that possibly be confusing? (which is exactly what happened here) While I agree with you that this whole situation should probably be different, it has become abundantly clear none of this is going to change as far as I can see. This stuff was done this way on purpose, so you will have to convince someone to change it. All Typography and OpenType stuff appears to be under the supervision/control of one person, and that person rarely even comments here (any more) so we are wasting our breath. So far I have seen a nearly zero response to other Typography/OpenType issues and questions I have posted, so I have just stopped posting. There are other OpenType issues with ordinals, discretionary ligatures, style groups, ccmp, etc. - but why bother - if none of it is going to change. If this is an ego driven stubbornness problem the only thing that works is public mocking. So until there is a very high-profile Affinity Annoyances article or book, it is futile. In the mean time I am happy to help users figure-out ways around the crazy stuff.

What language is the text set for? What happens when you change the language to something else?

First, regarding looking at Unicode characters in a hex editor ... Unicode uses hexadecimal (Base16) to designate characters. The hex editor is displaying UTF-8 characters. The ff ligature character in UTF-8 is: ef ac 80 The ff ligature character in UTF-16 is: fb00 No, I still think his issue is mixing encodings. The bottom line regarding ligatures is the user needs to know what is actually in the font (characters and OpenType features), and a clear explanation of what Affinity is doing in each situation.

Not sure what you are looking at for Open Sans, but the font files posted above have OpenType ligatures. I was not paying attention to the version - tomorrow I will post a screenshot of the standard ligatures included and the feature code. Arial ligatures look exactly like the original characters. So you are not going to see the change. And the FB00 ff ligature is only 1 font unit wider than 2 times the single f character. That may just rounding from the original node coordinates being non-integers. Dunno. Have to look tomorrow. But that 1 funit difference would explain the slight change in metrics you are seeing. Arial has the ligature characters (such as FB00), it just does not have the OpenType code to do the replacements. Many apps have mechanisms to replace those individual characters with the ligature character. For example MS Word and LibreOffice both have auto-correct entries which do this (even for fonts with no OpenType features at all such as old TrueType fonts). And ADesigner also has some sort of auto-replacements being done. This is independent of the OpenType replacements, but it does appear to interact with those as I mentioned above.

The character in your posted SVG for the Open Sans ff is: U+FB00 LATIN SMALL LIGATURE FF And the encoding in the SVG is set to: encoding="UTF-8" Whatever "hex editor" you are using is displaying the wrong codes for UTF-8, or it is set to some other encoding. This is the real problem - if you are setting the encoding to something else it is not going to display UTF-8 text correctly. Turning-Off all ligatures may work. OpenType Standard Ligatures are On by default (per the OpenType specs this is correct). Arial does not have the ff ligature in its OpenType Standard Ligatures. So in Arial the f+f is not replaced automatically. Open Sans does have the ff ligature in its OpenType Standard Ligatures. So in Open Sans the f+f is automatically replaced with the ligature (FB00). To prevent this, turn-Off Standard Ligatures in the Typography panel (as suggested above). In addition ADesigner has a "helpful" Ligatures feature - which you can access in the Text menu - which apparently replaces the f+f with the ff ligature character when there is no OpenType ligature feature available (or in this case Standard Ligatures is set to Off). Soooo helpful <roll-eyes>. Set that to "Use None" Text > Ligatures > Use None Then the SVG will actually have no ligatures (no FB00), which may work in your mixed-encoding text situation.

IDML files are ZIP files, so you can open them and take a look. The Spread_42531.xml file shows links to a number of images. Such as: <Image Self="image_84232" ImageTypeName="$ID/JPEG" Visible="true" Name="$ID/IMG_0915_Operations_Supervisor_Lupe_Favela_84232.JPG"> <Link Self="ucc" LinkResourceURI="file://~/Downloads/Images_for_Hollow_Tree_Times_8487_Nov_21_MzZ4/IMG_0915_Operations_Supervisor_Lupe_Favela_84232.JPG"/> </Image> And there are several more similar links. So my guess is the message is related to those missing images.

Gill Sans MT has a LTSH table, and an hdmx table (Gill Sans Nova has neither table). The LTSH table especially can affect the character width and spacing. The hdmx table can also affect the character width and spacing. So any mis-calculation of data from these tables could display what the user is seeing for this font. If you have seen any other older fonts with these tables and odd character shapes, then that would also point to this as possibly being the issue.

When I changed the font to Gill Sans Nova - it worked fine. And it looked the same. Gill Sans Nova is available in the Windows 10 Pan-European Supplemental Fonts package. Free to download and use. And it is a larger family.

@Jennifer23 It is always good to have back-ups. 🙂 But just changing the fonts installed should not damage your documents. I expect the Font Family name to be the same, so that will not change. You may have to re-apply the Font Style for some text depending on which style is applied. It depends on if and/or how the font names were broken in those v1.1 fonts. If you only used the Regular, it may all be OK. Or it may work with Regular and Bold. Dunno. Depends on the fonts and which styles you used. It all may just work fine. You will have to see. But I do expect it to now work correctly and the same on all the computers.

Where did you get v1.1? I would like to take a look at it. I assume it is broken too, but would like to confirm. Also please lets us know if the updated fonts fix your issues. Just like to confirm the correct fix.

Quicksand downloaded from FontSquirrel today - v1.002.(2011) - and definitely broken. Quicksand downloaded from DaFont today - v1.000.(2008) - and definitely broken.