kenmcd
-
Posts
1,773 -
Joined
-
Last visited
Posts posted by kenmcd
-
-
What font are you using?
Some fonts have ligatures like this.
-
Pretty easy to find alternatives for Zapf Dingbats which will work in Affinity Glyph Browser.
ITC Zapf Dingbats Std - Adobe (2007) (AFF11) - OpenType-PS - (Unicode)
(from Adobe Font Folio 11.1)Zapf Dingbats BQ - Berthold (2004) - OpenType-TT
(three fonts - Zapf Dingbats 100, 200, and 300)Zapf Dingbats BT - Bitstream (1993) - TTF - (Unicode PUA)
(in the old BitStream 500 Fonts CD) -
On 11/2/2023 at 5:36 PM, MikeTO said:
On macOS Affinity uses hhea line gap as a percentage of em size to determine default leading. The value for hhea line gap in the Arial included with macOS matches Affinity's defaults - line gap of 67 with em of 2048 is 3.271% and 12 pt type multiplied by 1.3271 is 12.393 pt default leading which is what Affinity uses. I don't know if the Windows version uses the line gap value in hhea, too, or if it uses the typo line gap value, but it would be nice to know. Arial is a good test case because there's such a difference between the hhea and typo line gaps. Its typo line gap is 307 which would yield 13.799 pt default leading. Verdana is another good test case - hhea line gap is 0 while typo line gap is 202 with an em size of 2048. So with 12 pt type, default leading would be 12 with hhea line gap and 13.184 if typo line gap was used.
Thanks for the info.
That is insane.
Still trying to wrap my head around the consequences of that.
Line gap is all over the place in terms of font settings.
And how it is handled in various applications is also all over the place.
Which is why the current "best practices" is to set it to zero, and match the Typo and hhea.
And set the Win metrics simply for no-clipping.
And Use Typo Metrics is On.
That is the default for Google Fonts.
And what is also now in a lot of newer commercial fonts for the same reasons.Note: some MS Office fonts have different metrics on Mac vs. Windows.
I mean the settings inside the font are different.
In one version the Typo matches the Win, and the hhea is different.
In the other the hhea matches the Win, and the Typo is different.
IIRC one is Palatino.
That could make a difference on cross-platform reflow issues.This is also affected by the Use Typo Metrics setting inside the fonts.
Most of the old MS fonts like Arial and TNR have this set to Off.
So is assume there will be differences between Mac and Windows with the same fonts.
But, it appears that Arial has the same Affinity default leading on my Win10.
So I wonder if it is using the hhea, or the typo on Windows when Use Typo Metrics is Off.Gotta make some test fonts so we can finally confirm all this one way or the other.
All of this just confirms (again) that the best practice is to set a fixed leading.
And avoid all this craziness.- Oufti, Martyn Folkes, lacerto and 1 other
-
4
-
3 hours ago, lacerto said:
This specific version is taken from Apple-provided supplemental fonts, and might be in some ways defective, or crippled in purpose. ...
I have no idea why Units Per eM value is 400 in this font
That UPM setting makes it appear way too large on Windows (and in some other applications).
Apple defaults to UPM 1000 and ignores the setting.
The vertical metrics settings in the font are the same in the 1000 UPM Monotype OpenType versions.
But that version looks correct on Windows.
So, yes, more Apple sabotage.Note: some fonts actually have a smaller UPM to make the file size smaller (e.g. FontAwsome).
3 hours ago, lacerto said:Interestingly, the stylistic sets (and swashes) are not exposed in the macOS version of this font, but e.g. Pages can use them pretty cleverly.
This is another Apple font which is not standard OpenType.
The features are in a morx table (and others), which Affinity applications to not support.
Pages supports the non-standard Apple features, so you can use them there. -
Most fonts these days the vertical metrics defaults are not 100% (commonly 120-130%).
And the vertical metrics are going to vary based on the OS, and some settings in the fonts.
For example:
You are using macOS so I am guessing the "Helvetica" you show as 100% is the one from the Mac.
The Mac vertical metrics in that font are set to 100%.
The Windows vertical metrics in that font are set to ~118%.
The Typo vertical metrics are ~95% (which is really odd).
And since "Use Typo metrics" is set to Off, the Mac and Windows metrics are supposed to be used.
Really old fonts, and OS supplied fonts are not good indicators of "most" fonts.
Google Fonts requires the Typo vertical metrics be set between 120-130% (and Use Typo metrics On).
And that is also typically what you will find in modern commercial fonts.
But it varies by the type of font.
Text fonts are pretty predictable.
In Helvetica Neue LT W1G the Typo metrics are set to 120%.
But display fonts can be all over the place.
For example in Gabriola the Typo metrics are set to 170%.Most modern fonts have "Use Typo metrics" set to On.
So those fonts should have the same "default" vertical metrics on both Mac and Windows.
But for fonts which have "Use Typo metrics" set to Off, so then the "default" can vary by OS.When Use Typo metrics set to On, APub default leading appears to be exactly what is in the font.
But when Use Typo metrics set to Off, I am not sure what they are doing.
The "default" is not the settings I see inside the font (e.g. Arial).Affinity appears to respect the "Use Typo metrics" setting in the font (unless that has changed).
InDesign ignores the font setting and always uses the Typo metrics.
That helps to avoid cross-platform re-flow issues.
Affinity should do this too. -
Libertinus v7.4.0 does still have an error in the SemiBold Italic font.
So I fixed that and exported the fonts to TTF with hinting (for screen display).
Libertinus.v7.040.TTF-Fixed.Names.zipLinux Libertine (family) has been fixed for LibreOffice.
(I guess they finally got tired of shipping broken fonts.)
Linux.Libertine.Family.v5.3.0-Fixed.Names.zipThe Linux Libertine fonts were not fixed due to some licensing issues.
They could not get all of the original contributors to sign-off on the license update.
You can see old discussions about this in the LibreOffice bug tracker.
This is also why they are not updated and included in Google Fonts.
Again, you can see related discussions in the Google Fonts Issues tracker.This is also why the family was forked and renamed to Libertinus.
Unfortunately Libertinus also suffers from some neglect.
Libertinus also removed some features (e.g. nalt).All of these fonts are very old.
The G fonts are the original Graphite fonts.
The O fonts were conversions to OpenType-PS.There are far more capable free OFL fonts available.
Fixed fonts are not going to fix the errors in existing PDFs.
But, it can prevent errors in the future.
So you may still have import issues.Make sure to shut all applications down when un-installing the old fonts and then installing the new fixed fonts - you want all the font caches to update properly.
Not sure why you have odd PostScript Names embedded for Libertinus.
Nothing in the fonts would explain that.
Have to see the original docs and PDFs.Note: I have no problem exporting your ODT file above from LibreOffice.
The correct fonts PostScript Names are embedded.
(unlike the odd names in your PDF above)
Affinity-Test.KM.exported.from.LO.pdfIt may be that you have too many different versions installed.
Also check that you do not have duplicate font files in your Windows Fonts folder and your User Fonts folder (look for duplicate files with a filename suffix like _0, _1, etc.).
That can confuse the Affinity font caching. -
I tested these old Linux Libertine fonts in LibreOffice a couple years ago - and they do not work properly. And you can probably find old bug reports in LibreOffice bug tracker. When the family is opened in TransType the errors are pretty obvious.
Libertinus did have some errors in it, but I thought those had all been fixed. I will take a look at the current versions later today to see if there are any problems. And check if there are any issues with the PostScript Name which would cause the odd PDF embedded name.
-
Those old fonts from SourceForge have errors in the name fields.
That is what is most likely causing your errors.The Linux Libertine fonts included with LibreOffice have been fixed.
So you could use those versions.The Libertinus font family is an updated/bug-fixed version of those fonts.
Download here: https://github.com/alerque/libertinus
This is probably the best option.The "G" fonts include the old Graphite smart font technology (and are also broken IIRC).
I would un-install all the G fonts. -
7 hours ago, Mr Lucky said:On 10/27/2023 at 3:16 PM, kenmcd said:
Those actually look like a different font.
Part of that issue may be that they opened at different sizes in each version. The font says it is the same Helvetica CY, but the b symbol is way bigger (not part of the font I can't remember how I did it originally.
It is doubtful that symbol is even in that font.
The fonts from back then are typically conversions from the Type1 fonts which had very limited character sets - which did not include flat (U+266D).
The 1997 TTF versions I have do not have that symbol.
But I do not have the old Apple TTF versions (4.xxx), but still, unlikely they have the flat symbol.You need to look at the PDF output to see what is actually being substituted and embedded.
Even if the font has the character, errors in the fonts may cause it to embed the wrong font.
For example some of the old Helvetica CY fonts have the regular font style set to "Plain".
That has been the cause of a PDF font embedding error in another thread in this forum.Make sure the font has the symbol you used.
Make sure that font is embedded in the PDF. -
Those actually look like a different font.
The shape and the stem length are not the same.
One way to check is to look at the PDF output for both.Can you share the Designer document?
And the two PDFs?And when you say you opened it in Designer 2 you mean you opened the original document, not open a PDF?
-
Was thinking about this and was going to test with an un-hinted font...
and started to edit your PDF to use it as a test doc...
and noticed that the blue "text" in your first section (Font text:) is actually just shapes, not text.I tested Poppins text in both black and your blue - and it looks fine.
I see no distortion as I zoom-in and out.
Poppins-Test.pdfSo this is looking more like it may be anti-aliasing issue as @MikeTO discussed above,
or something else entirely.
Regardless, it does not appear to be a font hinting issue. -
Affinity applications will sometimes show nothing when duplicate font files are installed.
So check both the Windows Fonts folder and your User Fonts folder for any duplicate font files - they will have a number suffix such as _0, _1, etc.
-
I see no issue with the ... replacement with the ellipsis using your Karla font (v2.002, 2020).
Same in your document. It appears to work fine.
It only replaced it with Arial when the Karla font was not available.I noticed you included the Karla variable fonts above.
You cannot have the variable fonts installed at the same time as the static fonts.
Google Fonts configures the variable fonts instance names to be same as the static fonts style names - so they conflict if both are installed at the same time.This could be your problem if you have both installed.
Affinity applications can get confused by the duplicate names - with unexpected results.
Such as treating a font as missing and thus replacing with another font.
So if you have the variable fonts installed, un-install them.The underline is changing with the replacement font change.
Fix the replacement font issue and that should fix itself.49 minutes ago, Klaus Wolter said:Where do I find the switch "Use typo metrics"?
That is inside the font.
The point is that how the font designer has set this may affect the vertical metrics.51 minutes ago, Klaus Wolter said:Where do I find "fixed leading"? --- on the other side it is on you to have the same "auto" function on all platforms. It is not to be loaded to the user.
Wow. Basic desktop publishing knowledge appears to be lacking here.
Check the docs and other DTP info sources about "leading".
Affinity does not have control over the "auto" - only you and the font designer do.
There are multiple settings within the fonts and they are used differently by different operating systems (and by different applications).
That was the point I tried to make above.
"auto" takes the default leading set by the font designer.
The problem is that "default" is often calculated differently by different operating systems.
So the solution is to use a fixed leading measurement which is the same no matter the OS.Your Karla font (v2.002, 2020) does have "Use typo metrics" set to On.
Which means that measurement should be used on both OSs.
What could be happening is that since you have "auto" set for leading when the font is replaced it is picking-up the leading from the replacement font (which is obviously different).
Using a fixed leading would also fix that.So first, do not have the variable fonts installed - that may be the main problem.
If that is not the issue, I am out of ideas.Note: there is a Karla v2.004, 2023 available now (but that should not affect this).
-
1 hour ago, Klaus Wolter said:
We use the true type “Karla”; the sentence might be: So far, the analysis…
Which version of Karla are you using?
And where did get it?
Do all systems have the exact same fonts installed?The fonts may have different vertical metrics and other settings.
For example the older version from Font Squirrel has smaller vertical metrics and "Use typo metrics" is Off. The newer version from Google Fonts has different vertical metrics and "Use typo metrics" is On.
These will affect the vertical metrics differently on the different operating systems.
Always use the exact same fonts on all systems.
And always set a fixed leading (not auto).
That should prevent cross-platform reflow issues.The Karla fonts from Font Squirrel do not have an ellipsis character (U+2026).
Which is probably why you are seeing the replacement font on that character.
The Karla fonts from Google Fonts do have an ellipsis character (U+2026).
So make sure everyone is using those same fonts. -
-
You cannot just rename the files. You need to use a tool which will properly change all the internal name fields inside the font.
Based on some discussions I have seen regarding this issue, it appears that Apple keys on the internal PostScript Name field.
Yes, TransType will work, if used properly. After you change the Family Name - change the Style Group to match. Then tab through the fields and make sure the PostScript Name displayed changes to match.
I usually change the name to show where it was discussed - such as Marion AF. That way months from now you know this font was modified, and why, and how.
When done change the file names to match the PostScript Names (which is SOP today).
-
This looks like a hinting issue.
What version of the Poppins fonts are you using - version number and format?
And when and where did you get them?I assume you are using a TTF version.
The TTF fonts from Google Fonts (GF) and the TTF fonts directly from Indian Type Foundry (ITF) have different hinting settings.
And ITF provides OTF versions (without PS hinting I think).Open Sans...
The current version of Open Sans from GF includes extensive manual hinting.
There are some older versions which have less hinting, and some which have none.
So depends on the version you have.Noto Sans is based on the same "bones" and has multiple versions you could use to test.
Full OTF or TTF, GF version, hinted TTF, unhinted OTF and TTF.
Download the latest monthly release and you will get all of them.
https://github.com/notofonts/notofonts.github.io
Testing with those could confirm that it is a hinting issue.- Mel Owski and walt.farrell
-
2
-
Marion is an Apple "Document-support font" on Ventura (13).
https://support.apple.com/en-us/HT213266#documentQuoteThese fonts are available only to documents that already use the font, or to apps that request the font by name. Some are older fonts that were included with earlier versions of macOS or Apple apps.
Affinity does not support the new Apple font controls.
The only work-around is to rename the fonts (properly, including the PostScript Name).
-
3 hours ago, Marathon1908 said:
Affinity's guide on fonts is all very technical but I was able to work out from it how to import Calibri, Cambria (etc) from the Word font library into the Mac font library, and I now have it in Apub. I should not have had to do this!
That is caused by Microsoft, not Affinity.
Note: you can do the same thing for O365 Cloud Fonts (on both Windows and Mac).
On Windows you highlight the fonts, and select Install for all users, and then delete them from the cloud fonts location. This will install the fonts in the main Windows Fonts folder, and make them available to all programs, including Affinity.
For Mac, do the same as you did above. -
4 hours ago, Steven_22 said:
So the problem is on the Affinity side
No, appears to be an issue with the fonts in this case. Well, both the fonts and APub.
(so @walt.farrell's assessments are right on the mark)
The fonts appear to have an odd way of configuring the name fields in the Regular and Italic.
This appears to have confused APub (which is easy to do).
APub should be able to figure this out correctly, but it can be a bit dense with matching font names.The Regular and Italic (just the two fonts) free-for-personal-use OTF versions that they have made available on multiple font sites display this odd naming.
I have a TTF version of the whole family which also displays the odd naming.
So I suspect that if you have the original full OTF family it also has the same odd naming.One work-around is to only install the fonts you are actually using (not the whole family).
So if you are only using the Medium, only install that font.
Then APub may not get confused, and may match it correctly.The way these fonts are configured is "wrong" and may not work properly in many applications.
If the fonts were fixed (to current best practices), they will probably work properly in APub.
If you would like to try that, send me a PM. -
I think there are multiple issues - both font issues and formatting issues.
And you need to deal with the font issues first.Times is an Apple "Document-support font" - so it is only supported in existing documents, and only in applications which support Apple's font controls. Apparently Word 365 does support Apple's font controls, so the font is available in your existing Word document. Affinity applications do not support Apple's font controls, so fonts which Apple has now deemed a "Document-support font" do not appear in APub. Which is why Times got converted to a fall-back font - Times New Roman - which is still supported both by Apple, and Office 365.
I think Microsoft has now started restricting the fonts installed with Office 365 on Mac to use only in Office 365. So Calibri is normally not going to be available to APub now. That may only be on the Mac. Do not know for sure.
Calibri is installed with Office 365 for Mac.
Office 365 Cloud Fonts are not available to APub on Mac or Windows.So the first thing to do is convert to fonts which do not have any restrictions.
There are lots of free OFL licensed high-quality text fonts with none of these OS font issues.
There are lots of commercial high-quality text fonts with none of these OS font issues.
Once you have fonts which will transfer properly then you can deal with the format issues.Some of the format issues may be because of different character widths in the fall-back fonts.
Having fonts which transfer properly would eliminate that as a potential issue. -
Check the Paragraph > Flow Options -
Keep paragraph together and Keep with previous paragraph can cause some bizarre format issues.
-
Myanmar MN and Myanmar Sangam MN will never work in Affinity applications because they are Apple fonts which use Apple's non-standard font tables instead of standard OpenType tables. Affinity applications only support standard OpenType.
You could try Noto Sans Myanmar and Noto Serif Myanmar (which use standard OpenType tables).
But, I doubt they will work because they rely on three OpenType features which may or may not be supported in Affinity (I do not know for sure; I have not checked).If the Noto fonts do not work, then Myanmar is simply not supported yet.
Update: I did not notice at first you also tested Padauk.
That font uses OpenType and Graphite tables.
It also use a few more different OpenType features than the Noto fonts.
So still try the Noto fonts. -
Lithos does not have italics available.
And Affinity does not have fake italics.
But it does have Shear (slant) in the character panel.
I would check that.If that is not the issue, please attach that page of the document so people can take a look.
Output as pdf from Publisher Incorrect
in Affinity on Desktop Questions (macOS and Windows)
Posted
Looks like the PDF font sub-setting is not working correctly.
Try turning-off Subset fonts in the PDF settings.
When you output to JPG it goes straight to the rasterizer and it does not go thru the PDF library