[PDF Import issue]

2 hours ago, Inmates Shelter said:

Attached is a PDF file from HP Smart.

PDF-XChange Editor found problems with that PDF.

PDF Desktop Repair Tool listed the structural issues it found with that PDF.

So the error message in APub is just not very helpful (not correct).

Appears HP Smart is creating bad PDFs that APub is unable to work-around.

Note: just viewing a PDF is easier for applications than editing a PDF.

[InDesign to Affinity 2, spacebar not working between words.]

APub says the font is KeedySansReg - which is a really old conversion from Type 1.
Some of these old conversions have old control characters multi-mapped to the space character.
That could be an issue.
Current versions of the font do not have any of those control characters.
And they do include very basic frac and liga features, and some kerning.

I do not have any problems with the spaces and this font on Win10.

What happens if you change the font - does the problem go away?

[Automatically adjusting kerning?]

Yes, it is a ligature (T_h), and it is encoded as TH (two characters).
Weird.

This looks like another case of Adobe purposely messing it up for other applications.
They keep the correct data in their hidden sections, and put crap in the accessible data.
Like they do with caps etc.

Hmmm... it does have a correct glyph mapping to the ligature name, so a smarter application could perhaps figure it out. Dunno.

Regardless, it should not have two uppercase characters mapped in the ToUnicode.

[Automatically adjusting kerning?]

Usually the Tracking is the issue with imported PDFs, not Kerning.
So you need to set the Tracking back to the default.

I am guessing the TH was probably a Th ligature which somehow got encoded in the PDF as capital letters. ID does include both characters in the ToUnicode table for ligatures.
What font is that?
I assume it has a Th ligature (which may fit the space).

Cannot quite fathom the mechanics for this other than an ID error.
Can you attach the original PDF (or at least a page).

[Regular-Italic toggle issue in Publisher]

1 hour ago, pinemach said:

Is anyone able to point me to what might have gone wrong here, and how to fix it so that I can use this "Sitka Small NoTTC" font face in Affinity, and not have to continue dealing with this styling problem?

The other applications (LibreOffice, Notepad, GIMP) all handle the original fonts style groups correctly. Affinity does not.

What I mean by 

On 1/26/2025 at 10:51 AM, kenmcd said:

rename them in a manner that the apps will not mess-up.

... is to match the Typographic Family to the style groups so all families are RIBBI only.

The family grouping in the other apps will stay the same, but the grouping in Affinity will change to match.

This is actually easier for users when moving between apps and OSs as the font grouping is always similar. Monotype did this with Helvetica Now (which is different from Helvetica Neue, etc.).

I can make you a fixed version about two hours from now. I will make a note here and PM you the fonts.

[Publisher struggling with too many font variants]

You could try converting the document to curves and see if that will export.
So no text, no fonts to embed.

Bizarre font.
Not really a "variable" font - as there is no actual variation of shapes.

It is basically 500 static fonts in one "variable" font file.
Each setting (1-500) is a condition, and each condition swaps all the glyphs (using rlig).
So each setting is a full set of all the characters, or basically a separate font.

Over 50,000 glyphs in the v1 font on the demo website.
If you are using the v2 demo font, or the commercial version - you could have even more.
And Affinity apps have problems with that as they appear to work thru all the glyphs.

If nothing has happened in "an hour or two"...
My guess is your only option is to try converting to curves.

Using the actual separate static fonts would probably work, but obviously that is not going to happen quickly.

[Superscript]

Calibri does have an actual Ordinals feature.
And those glyphs are correctly optical-sized not just scaled.
See example below:

You could make a Character Style and assign a shortcut to it.
Looks better.

[Spaces deleted between words]

4 hours ago, Jim Monson said:

Some how all *spaces* between all names on a large map in aPub v2 were deleted leaving all letters together without spaces (ugh!).

Was this map originally a PDF?

[Regular-Italic toggle issue in Publisher]

14 minutes ago, Oufti said:

Could also be this: https://maulanacreative.net/constanta-typeface/ but it's a single font family, thus also not the same problem as in this topic. 

Looks like that is an SVG font.
So that is not going to work.

And also a different issue than this thread.

[Regular-Italic toggle issue in Publisher]

1 hour ago, Stephen - TGF said:

Constanta still does not work properly on my machine. Windows 11. 

I assume you mean Constantia.

And Constantia is a very common RIBBI four fonts family (that Affinity cannot mess-up).
This thread is about more complex situations.

I suggest you start a new thread and explain exactly what "does not work properly" on your machine.

[Font installed correctly but not shown in document on Mac]

1 hour ago, Ro_n said:

Any ideas?

Choose Love Three Versions

• SVG - this is the core font with alternatives
• Ligature - this contains all the ligatures
• Standard - this is the standard vector font with alternatives and ligatures.

Above is from the Choose Love font developer web site.

SVG - Affinity applications do not support SVG-in-OpenType fonts. And apparently the font does not have a fall-back format (or Affinity is just not handling it correctly).
Would have to see the font.

Ligature - appears to only have un-mapped ligature glyphs - and does not have the usual Unicode characters which would appear in your sample text.
Would have to see the font.

Standard - works because it is a plain OpenType font.

[Regular-Italic toggle issue in Publisher]

3 hours ago, pinemach said:

Here's hoping for official Linux platform support from Affinity before I have to let go of Win10?)

I also use Win10 daily. I have Win11 in VMs for testing, and all the fonts. 

I doubt there will ever be an official Linux version.

Regarding the Win10 Sitka fonts - the only work-around is to extract the fonts from the TTCs and rename them in a manner that the apps will not mess-up.

[Regular-Italic toggle issue in Publisher]

7 hours ago, pinemach said:

I have been experiencing this problem intermittently with 2.5.7. Sometimes adding and removing bold or italic styles works upon startup and loading a document - toggling on and off italics with Ctrl+i behaves as expected, for example - and sometimes it doesn't work - the font style changing to something else besides the initial style after toggling on and then back off italics. Nothing I've tried can make it start working (if broken) or stop working (if working correctly) after initial startup and the first such interaction.

I am experiencing this problem using the Sitka font specifically, using "Small" for regular text and "Small italic" for italic text.

I am not sure if it's random or if there's something I'm doing differently on different startups. But if it's related to my own interactions with the application on startup then it's not anything obvious to me.

Looks like you are using Windows 10.
Because those are the Sitka weights available on Windows 10.
Windows 11 adds SemiBold (and changes to variable).

On Windows 10 Sitka is in four TTC files - organized by R/I/B/BI.
And then the six optical sizes are in each of those four.
So the Bold TTC file has the six Bold optical sizes fonts, etc.

Affinity applications do not currently connect the style-linking correctly.
It appears this particular TTC file structure confuses the apps.

Sitka on Windows 11 is now in two variable font files instead.
The style-linking in those fonts does not work correctly either.

Note: the problem is not in the fonts.

[Custom Ligatures not Working]

Kinda surprised that it does work on Windows as it is now.
But...
Your replacement glyph should be named S_T_A_M not STAM.

So your liga feature code should look like this:

feature liga {
# GSUB feature: Standard Ligatures
# Lookups: 1

  sub S T A M by S_T_A_M;

} liga;

Give this font a try and see if it works on your Mac: KomikaSunsetServeOSAF.zip
The glyph has been renamed, and the feature code adjusted for this.
It is renamed to KomikaSunsetServeOSAF so you can install it at the same time.

Note: you may want to make your text for the replacements harder to type accidentally - e.g. make it [STAM] or whatever.
Otherwise you may have issues with unexpected substitutions.

[Publisher 2 won't open on Mac Pro running Sequoia 15.2]

1 hour ago, ElizaStudios said:

I deactivated the font I was trying to use when the crash happened and now Publisher has opened!!!!  

Which font was this?

[Text Format Problem When Opening PDF in Beta Versions]

5 hours ago, MikeTO said:

I don't know why 2.6.0 wants to replace Arial Bold with Helvetica Bold, and Times Bold with Helvetica Bold since it is replacing the un-styled versions with Arial and Times, respectively.

Affinity still cannot handle the comma in the font name when identifying fonts.
Such as: Arial,Bold or Arial,Italic or Times New Roman,Bold
Awhile back I went to find where these font names with the commas came from.
According the Microsoft .NET API the comma tells the text rasterizer to use the Bold font if available, or to apply the fake Bold if the actual font is not available.
The sample document above was created with Microsoft Word 2007.
When a user prints the doc and they do not have the Bold font, it still looks bold.
So it is a way of MS handling the fake bold and fake italics.

The Affinity font matching code should know that:
- Arial,Bold = Arial-Bold 
- Arial,Italic = Arial-Italic
- etc.

Arial and Times New Roman are kinda funky with the names embedded.
But many other fonts the FontName,Bold = FontName-Bold exactly in the PS Name.
So there is no excuse to not match them correctly.

This has come-up multiple times before in other discussions about matching fonts.

[Text Format Problem When Opening PDF in Beta Versions]

Can you attach the PDF?

[[Publisher 2.5.7][BUG][Searching for "s" and "ſ" (long s)]]

12 minutes ago, MikeW said:

Except it works here using GPPro as seen in my last screen shot. 

If the search has the purpose of seeing the 3 characters in context, one could always use a regex search for s| (pipe character) plus a copy/pasted long s character immediately after the pipe character. 

However, I don't understand why it works for me and not the OP.

There seems to be a trigger to do the character replacements.
Export to PDF definitely triggers the replacements.

So not sure if saving, or closing the file or the app, or reopening the file or app, or something else is the trigger.

[[Publisher 2.5.7][BUG][Searching for "s" and "ſ" (long s)]]

Known bug.
Previous discussion marked as: #APL-1727
From here: https://forum.affinity.serif.com/index.php?/topic/205822-afpub2-v252-can-unicode-characters-be-learned-mapped-for-the-spell-checker/

That discussion was also about long s.
Further down that page I posted tests which included Garamond Premier Pro and Junicode.
https://forum.affinity.serif.com/index.php?/topic/205822-afpub2-v252-can-unicode-characters-be-learned-mapped-for-the-spell-checker/#findComment-1233714

The bug is that Affinity is actually replacing the character - changing the Unicode code point - rather than doing the correct OpenType glyph substitution.

Affinity is doing the something similar with legacy ligatures.
https://forum.affinity.serif.com/index.php?/topic/203218-unwanted-ligature-feature-added-to-fonts-not-good/
(in that case a monospace font with no OpenType ligatures, Affinity is replacing the two "fi" characters with the one legacy ligature character)

This causes problems with search, screen readers, and copy-and-paste.

Peter, the Junicode developer, talks about the issues and how Junicode works here (and in the PDF manual):
Searchable web pages with MUFI and Junicode 2

The fonts are not the problem.
The problem is Affinity.

You cannot use Garamond Premier Pro or Junicode to create searchable historical documents - because Affinity will break the text.

You cannot use a monospace font to create sample programming code documents - because Affinity will break the code.

@Franz Rogar Unfortunately the only work-around is to use a different application.

 

[Thai text will not export/print correctly even if Publisher is display correctly]

6 hours ago, TJH Art Studio said:

A friend of mine sent me a pdf file with Thai fonts but when I opened it on any of the Affinity software it came out gibberish. It didn’t look anything like Thai letters. It seems the only way I can open it is in jpg but I can’t make any changes to the fonts if I open it like that. Does anyone have any ideas on what to do?

What application was used to create PDF?

Can you attach the PDF?

[Bold issues]

The Bold and Bold Italic fonts have no style-link to the Regular and Italic fonts.
And thus should have no connection to them.

The info is there in the fonts - they are just using it wrong.

[Bold issues]

9 hours ago, Hangman said:

This is what I see in the 2.6 Beta...

My OTF versions differ, the Regular is an earlier version... 1.007 and the Bold is 2.115, though I'm surprised this results in differing behaviour in Publisher...

Both the Bold and the Bold Italic are wrong.
I tested with the v1.007 full family of six fonts.
The style-linking in v1.007 is the same as v2.115 (see image above).

Affinity is automatically setting the Bold button for the Bold font - which is wrong.
In the style linking the Bold font is R in its own style group.

You really need all six fonts to see how it is messing-up.
Check your PMs.

[Bold issues]

19 hours ago, MikeTO said:

Using Minion Pro with Regular, Medium, Semibold, and Bold weights:

1. Font Style = Regular
   • 2.5 - the Bold button is enabled - selecting it sets Font Style to Bold and deselecting it sets it to Regular - good
   • 2.6 - ditto
2. Font Style = Medium
   • 2.5 - the Bold button is enabled - selecting it sets Font Style to Bold and deselecting reverts to Regular, not Medium like Apple's apps
   • 2.6 - the Bold button is disabled
3. Font Style = Semibold
   • 2.5 - the Bold button is enabled and selected - deselecting reverts to Regular
   • 2.6 - the Bold button is enabled and selected - clicking it doesn't do anything
4. Font Style = Bold
   • 2.5 - the Bold button is enabled and selected - deselecting reverts to Regular - good
   • 2.6 - ditto

This appears to be working properly in 2.6 - mostly.
Medium - Bold button should not be enabled and should have no effect - looks OK.
Semibold - Bold should not be enabled - not correct. Should have no effect - OK.

Minion Pro (normal only) has a more typical style groups configuration.

But there have been a lot of problems when all of the super-family fonts are installed.
The multiple RIBBI style groups have been an issue.
In Minion Pro all 64 fonts are in the same Typographic Family.
So that would need to be tested again after these changes/fixes in 2.6.

 

[Bold issues]

Adobe Caslon Pro has the same non-typical style groups/style-linking.

[Bold issues]

52 minutes ago, MikeTO said:

That's odd, Bold is definitely disabled for me. We must have different versions of the font installed. My regular and bold OTF files are version 2.115. What are yours?

Mike, do you also have the Semibold fonts installed?

Adobe Garamond Pro v2.115 is not typical in how the style groups are configured.
The Bold font is not in the same style group as the Regular font.
Affinity has problems with not-typical style groups.

Regular and Semibold are in one RIBBI style group (where Semibold is the B).
That style group is named Adobe Garamond Pro.
And the Bold font is actually in its own style group - Adobe Garamond Bold.
And in that style group it is configured as the R of the group.

So when you apply the Bold button to the Regular font you should get the Semibold.

And the Bold button should have no effect on the actual Bold font.

But... Affinity is in the iStupid habit of applying the Bold button to all fonts with a weight above 400.
Until they stop doing this iStupid Mac thing the style linking will never work properly.

The name at the top is the Typographic Family.
The names on the smaller boxes are the style groups.