Character, line, paragraph spacing // unconditional font change (and a small graphical challenge on both macOS and Windows)

[Klaus Wolter]

Framings:

!!! Our “Affinity publisher software” is always up-to-date !!! (now: 2.2.1)

We are working across the world (Mexico / Germany) and act on two platforms: Mexico= Mac / Germany: Windows 10. All OS-systems are up-to-date!!!

Reproducible problems encountered:

For the moment it seems to be that the version running on macOS is quite okay.

BUT: the Windows version differs “drastically” from that. We found that the calculation of space between characters and/or lines and/or paragraphs is not the same on both systems, so that we had to reduce our interchange and the load for the working place with the macOS version had to be increased. (==> example appended take a look to "Woher kommt unserer Wasser 13-10-2023.afpub", the page break from 3 to 4. again windows version to macOS).

A second and also very big bug is the handling of special characters like “…” in a sentence.

Example: We use the true type “Karla”; the sentence might be: So far, the analysis… The moment you finish writing the “…” the font changes to ARIAL (you see it because the dots are now square shaped) and if you underline the whole sentence, then the underline also changes its thickness to be ARIAL type. This of course happens with a lot of fonts, but even one is too much. (I found a workaround… If I change the font type for the “…” only to “Symbol” nothing happens…)

This bug does not happen on macOS!

Conclusion:

With such big bugs we are not really able to work fluently. We hope that such incompatibilities will be erased very soon!!! Calculations and so the result should be very equal across the platforms.

I hope you are able to reprodue what we face in our daily work...

We love your program!!!

_____

Please go to the "Master EN" page in which appended file ever.  Overthere take a look to the lower left corner of the blue head (see appended screen shot). as you can see we had to place the square object a little bit outside because the moment we align it to the corner we will see a colored artefact borderline from the blue background. The white corner is not covering what is below. That is not what we can give to a printer. If we choose to have our corner at x=0.0, y=36.0 and the dimensions of the square equal w=4.0, h=4.0 we are not happy!)

Die Quellen 19-10-2023.afpub Woher kommt unserer Wasser 13-10-2023.afpub

[kenmcd]

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.

[walt.farrell]

The handling of the ellipsis character (...) may also depend on the application Settings. In particular, the Settings for Publisher have an Auto-Correct section, and one of the default corrections if Replace Text While Typing is enabled will replace ... (3 dots) by an ellipsis character.

You would need to make sure that your applications Settings are also consistent across the machines.

[Klaus Wolter]

Thank you for this first quick response!

 

We use on both platforms exactly then same true type source Karla and Chakra Petch. This Karla has as it shows in all static and variable an ellipsis charakter U+2026; I checked out with FontForge (fonts attached). So again the question: why does Affinity change the font to ARIAL only in the windows version? And: why does Affinity change the underline?

Where do I find the switch  "Use typo metrics"?

On the other side it is on you the programmer to solve differences on platform changes. A source file, as I sent to you must be  directly interchanable between the platforms. Your files should be totally platform independend. There checks should be implemented.

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.

You can explain this to me using the document files I attached before.

ChakraPetch-Bold.ttf ChakraPetch-BoldItalic.ttf ChakraPetch-Italic.ttf ChakraPetch-Light.ttf ChakraPetch-LightItalic.ttf ChakraPetch-Medium.ttf ChakraPetch-MediumItalic.ttf ChakraPetch-Regular.ttf ChakraPetch-SemiBold.ttf ChakraPetch-SemiBoldItalic.ttf OFL.txt Karla-Italic-VariableFont_wght.ttf Karla-VariableFont_wght.ttf OFL.txt README.txt Karla-Bold.ttf Karla-BoldItalic.ttf Karla-ExtraBold.ttf Karla-ExtraBoldItalic.ttf Karla-ExtraLight.ttf Karla-ExtraLightItalic.ttf Karla-Italic.ttf Karla-Light.ttf Karla-LightItalic.ttf Karla-Medium.ttf Karla-MediumItalic.ttf Karla-Regular.ttf Karla-SemiBold.ttf Karla-SemiBoldItalic.ttf

[Klaus Wolter]

Hi walt.farrell!

Yes; the AutoCorrect exchanges but never replaces one font with another Karla to ARIAL and never changes the underline. Take a look to my source file and make you own experiment (on windows and on macOS).

[kenmcd]

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).

[Klaus Wolter]

Hi kenmcd,

yes, no one knows all! --- So, it is fine, that you are available!

Font-problem is solved!!!

Your hint to check the Karla-font-installation was the solution. No, it was not that there have been variable fonts installed, but while installing Karla not all static variations have been copied, so that variation requested was not available. Your idea that there might have been a conflict was a very good hint !!!  --- And I learned some backgrounds about fonts.I'm a user only and wish to work with a DTP tool that's perfect. If I stumble then guys like you are very helpful - thanks!

Now I like to know about the second problem, that graphic artefact... --- Any idea?

[Klaus Wolter]

Hi to all!
I'm back again and I like to add some thoughts to this experience:

Firstly, let's recapitulate those missing fonts have been the problem. My font installation on windows did not - even I called for - install all static fonts of Karla I marked. (my fault?). But in AFFINITY I defined in my text, that I liked to have Karla, bold and underlined. This request should have been denied and a warning should have been launched instead of falling back to a standard font and changing all the underline for the whole sentence according to that font.

As I said: I'm a user and a professional program should give hints as best as possible. And now, since you know about that you should be able to solve it.

Secondly, my request describing (take a look to the begin of my report) the problem with the artefact is not jet considered...

The first image

shows the workaround and the second picture shows what happens if no workaround is active.

Thanks for your patience !!! --- I hope to hear from you soon.

 

 

[walt.farrell]

Publisher provides a function designed to avoid most of this problem: 

https://affinity.help/publisher2/en-US.lproj/pages/Publishing/aboutPackaging.html

That will ensure your collaborators have the exact fonts needed. It will even protect you from the possibility that sometime in the future the fonts on your system will have changed. However, as mentioned earlier, you still should ensure you specify a fixed Leading rather than (Auto) as macOS and Windows can perform the calculation of Auto differently.

[Klaus Wolter]

Thanks walt.farrell ! --- very good to know! 😎 --- I follow this hint directly.

(Any comment about the second topic?)

[walt.farrell]

1 hour ago, Klaus Wolter said:

(Any comment about the second topic?)

Sorry, but no, other than to comment that it is better to discuss one issue per topic, as it keeps the discussion more focused and helps avoid both confusion and having an issue overlooked

[Klaus Wolter]

Thanks again walt.farrell !

So I will open another topic...

Your hint to take a look to aboutPackaging was really good. Over there the check I suggested is done. But during the workflow I was'nt pushed to the lack of font I was intended to use. And that is what I pointed too. Affinity already has the function to check if all is included, so why not to give hints due to checking directly while working on the file? --- Consider if might be comfortable to a user...

Tanks again !!!

[walt.farrell]

46 minutes ago, Klaus Wolter said:

Affinity already has the function to check if all is included, so why not to give hints due to checking directly while working on the file? --- Consider if might be comfortable to a user...

If you Open a file that uses a font you don't have, you are warned. But there is no way to detect or warn of incompatible fonts, that I know of.

If you are using a font, and enter a character that is not in the font, and you're using Publisher, PreFlight should warn you. If I understand this topic it seems that the font might have switched to a different one that does have the character. If that happened I don't understand why. But perhaps I just don't understand that part of the topic completely.

[Klaus Wolter]

Hi walt.farrell !

Look, the font Karla was existent at all, and the character was also available, but the font part bold+italic (Karla-BoldItalic.ttf) was not available becasue of an installation bug cause by windows. That very special case seem to be not checked correctly as you assume... --- might be checked.

😊

[walt.farrell]

54 minutes ago, Klaus Wolter said:

the font Karla was existent at all, ... 

but the font part bold+italic (Karla-BoldItalic.ttf) 

Karla-BoldItalic is not a "font part", it is a font. And when you Opened the file that used it, you would have gotten a warning from Publisher. It only shows up for a little while before the warning goes away, but it would be there (in my experience).

The Font Manager would also show it to you if you looked, and the Context Toolbar should have shown a warning.

[Klaus Wolter]

No, sorry there was no warning... (might be in some more hidden reports, but not popping up  like "Hi user there is a major problem we miss a font you try use!" --- That is what I say.

In the packed -- I learned now -- the font part for BoldItalic I requested for use is seperately mentioned over there. But I am able to request that font part choosing in the character setup during my workflow -- what I did -- checking the bold and the italic and the underline box. That should have been grayed out because not availabe, but it was'nt. I was able to use it and so I thought all was okay. Otherwise you had never seen me complaining.

[kenmcd]

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. 

[Klaus Wolter]

Thanks kenmcd !!! -- I will check! --- great to work with you! ☺️