big smile

I think this is what must have happened. I must have had the old V1 version installed. And then after I reformatted my system, I must have installed V3.
 
That's just a custom font file I made, when I was testing out font creation software. But it's identical to the main font. 

You may have created the document with an earlier version of Open Sans.
The v1 originals and the v3 from Google Fonts have different names internally.
The Full Font Name and the PostScript Name are different - and these are often used to identify a font.
The font name you see in the Affinity font menu is the Font Family Name (for these fonts), and it is the same in both versions.
So it could be confused by the different internal names.
(note: the Affinity font matching is rather dim and should be able figure-out these things).
You could try the v1 original fonts and see how that works.
Download here: http://www.opensans.com/download/open-sans.zip
 
p.s. What is "Open Sans Bold Number Lines" and may I please have a copy of it?

So it might be a glitch in this specific document (or a different font file used initially).
Workaround:
1. Deactivate Open Sans from your system. (to get it listed in the 'missing fonts')
2. In APub use Find & Replace to temporarily replace it with any other (unique) font.
3. Activate Open Sans.
4. Use F&R to replace the temporary font with the wanted Open Sans.

Safe Mode resets it during the boot process, yes, and it also may reset the Affinity font cache (quit Affinity before rebooting) – but I don't know if the "Affinity Fonts Replacements" is sufficiently affected by a macOS font cache reset, I guess that is rather stored in an app preference file and thus maybe worth a try.
As Walt already mentioned: Was this document created or worked before without issues on this computer & with the same fonts installed/activated? Or are/were various versions of this font activated on this or an involved computer?
Can you use Open Sans in a new document?

Hi @big smile,
Have you installed the variable font version at some point? Affinity apps currently don't support them.

That's odd. It works properly for me, on both Windows and macOS. What release of Publisher are you using?
It's also odd, of course, that it says Open Sans is missing, and offers it as a substitution. That could indicate you have some mistakes in your installed fonts, either issues in a specific font or that you have a conflicting set of fonts installed. What version of Open Sans do you have installed on that machine, and on the machine that created the file?
 

Are possibly two different versions of the font file involved, e.g. from different computers or de-/activated by a separate font manager app?
If not, you could try to reset fonts for Affinity:
• Preferences > Miscellaneous > "Reset Fonts".
• Close APub + launch it with the CTRL key pressed to cause a reset dialog window > there is an option "Reset Font Replacements".
If this doesn't help you could reset the font cache in macOS by booting the mac in "Safe Mode". https://support.apple.com/guide/mac-help/mh21245/mac

Thanks for your help. I tried all these steps but it didn’t work. I assume once I go into Safe Mode, the font cache is automatically cleared, and I don’t need to do anything?
 
Thanks for your help. I am using Publisher 2.3.1 on MacOs 12.7.2
I am using Open Sans Version 3.000. I'm pretty sure this document has only been ever created and used on this machine. I know a few months back I did a clean reinstall. I am not sure if this document was created before or after the clean reinstall. 

In Affinity Publisher, you can have a text frame split across a spread (i.e. so there's a text frame on the left side page that is linked to the right side page). Is there any way to insert a table in the text frame, so it will be split across the spread.
Or any other way to make a table split across a spread?
I've got a table that won't fit on one page, so it needs to go across the two pages of the spread. But I don’t want to create two separate tables, because if I make changes on the first table, then the excess rows on the first page won't automatically transfer to the first. 
 

Issue:
In my Affinity Publisher documents, I tend to use the same text styles. When copying and pasting text between the documents, the styles get duplicated with a number added at the end. This happens even if the styles are identical. Example:

^ These are all the same style which have been duplicated when copy & pasting between documents. 
Solution:
When copying and pasting between a document, Affinity should ask the user how handle duplicate styles rather than just numbering them.
 
Here is an example of how it could work:

This dialogue box would pop up whenever copying and pasting text in situations where Affinity would currently just duplicate the style.
This dialogue box would be optional, activated first via an option in preferences, so users who like the current handling of style can choose not to activate the option. 

Explanation of options:
Merge Styles - Keep incoming definition This option will cause the two styles to be merged. All values will follow the source document.  Merge Styles - Keep local definition This option will cause the two styles to be merged. All values will follow the local document.  Create new style - This will create a new style (which is how Affinity currently handles it by duplicating the style and adding a number to the name). Additional options:
Clear Overrides - Any differences between the local and incoming style will be discarded.  Keep Overrides - Any differences between the local and incoming style will be kept as overrides.  Save Overrides as character style - The differences can be saved as a character style.  Example:
I have  "Document A" which has  text that has a style called "English translation". This is just Helvetica, bold text 12pt. 
I copy and paste this text into "Document B" that already has a style called "English translation". If I select "Merge Styles/incoming" then the style from Document A will be used. If I click clear overrides, then any differences between the text in document A&B will be lost. 
Who would this be useful for:
This would be useful for users who regularly copy and paste text between Publisher documents. 
History
This feature request is actually something I requested back in 2019 for Affinity 1. I am making a new request, because the issue still plagues Affinity 2 and it's super, super annoying. It still happens even when the source and destination have the same style sheet with the same style definitions. 
I literally spend 20% of my time using Affinity wrangling with styles. Grr!
As a workaround, you can copy and paste into a new document, go to the text styles menu and then select "Detach and Delete all styles". And then, from there, you can copy and paste into the destination document. You can then re-apply the styles in the destination document. (If you are on a Mac, you can use Keyboard Maestro to copy and paste your text without formatting, thus saving the step of pasting into a new document). But even with this work around, it's a still a time waste!
I appreciate that development of new features is complicated, so I just hope things work out to make having a solution viable one day, hopefully sooner than later. 

Issue:
In my Affinity Publisher documents, I tend to use the same text styles. When copying and pasting text between the documents, the styles get duplicated with a number added at the end. This happens even if the styles are identical. Example:

^ These are all the same style which have been duplicated when copy & pasting between documents. 
Solution:
When copying and pasting between a document, Affinity should ask the user how handle duplicate styles rather than just numbering them.
 
Here is an example of how it could work:

This dialogue box would pop up whenever copying and pasting text in situations where Affinity would currently just duplicate the style.
This dialogue box would be optional, activated first via an option in preferences, so users who like the current handling of style can choose not to activate the option. 

Explanation of options:
Merge Styles - Keep incoming definition This option will cause the two styles to be merged. All values will follow the source document.  Merge Styles - Keep local definition This option will cause the two styles to be merged. All values will follow the local document.  Create new style - This will create a new style (which is how Affinity currently handles it by duplicating the style and adding a number to the name). Additional options:
Clear Overrides - Any differences between the local and incoming style will be discarded.  Keep Overrides - Any differences between the local and incoming style will be kept as overrides.  Save Overrides as character style - The differences can be saved as a character style.  Example:
I have  "Document A" which has  text that has a style called "English translation". This is just Helvetica, bold text 12pt. 
I copy and paste this text into "Document B" that already has a style called "English translation". If I select "Merge Styles/incoming" then the style from Document A will be used. If I click clear overrides, then any differences between the text in document A&B will be lost. 
Who would this be useful for:
This would be useful for users who regularly copy and paste text between Publisher documents. 
History
This feature request is actually something I requested back in 2019 for Affinity 1. I am making a new request, because the issue still plagues Affinity 2 and it's super, super annoying. It still happens even when the source and destination have the same style sheet with the same style definitions. 
I literally spend 20% of my time using Affinity wrangling with styles. Grr!
As a workaround, you can copy and paste into a new document, go to the text styles menu and then select "Detach and Delete all styles". And then, from there, you can copy and paste into the destination document. You can then re-apply the styles in the destination document. (If you are on a Mac, you can use Keyboard Maestro to copy and paste your text without formatting, thus saving the step of pasting into a new document). But even with this work around, it's a still a time waste!
I appreciate that development of new features is complicated, so I just hope things work out to make having a solution viable one day, hopefully sooner than later. 

IMO the best way is to export the cover alone as a bitmapped format (TIFF for CMYK or JPG for RGB). Although importing a PDF would work fine, this would avoid any bugs with linked PDFs and there have been a couple of those this year. Using a bitmapped format also reduces the load on Publisher. Instead of having to interpret (process) an afpub or pdf file when exporting the page with all the cover shorts to PDF, it could just include the bitmapped image which is much less work. The key of course is to ensure you choose the right resolution, not too low for your needs but not needlessly high which would bloat the file.
Cheers,
Mike

I think this was probably due to fixing the file locking issue so it was a necessary change. Although it worked well for your need, importing a complex document into itself can lead to crashes.
The other recursive hole is still open though - you can import file 1 into file 2 and file 2 into file 1. I tried it with a Book for fun. I even added a cross-reference from 1 to 2 and from 2 to 1. Then I placed chapter 1 into chapter 2 and chapter 2 into chapter 1. Needless to say, saving either chapter was lots of fun. I don't recommend this. 🙂 
 

Yes, there is "a" way – its details depend on your platform (mac/win) and the source file type (spreadsheet, .rtf, txt. … etc.). So it appears to be a more or less complex procedure which requires to consider several if-then conditions.
This two threads discuss this and include sucessful workflows:

FWIW, for me if using Safari I copy the list from the first post to the clipboard, it works fine if I first select enough cells ... but if say I paste that text into TexEdit & do not make the format Rich Text then it all ends up in the first selected cell.
So if you copy the text from this text list.rtf file, if you then select at least two cells & paste, does it work for you?

I got it wrong. Here's how to do it.

2023-10-03 18-17-40.mp4    

Try this way

2023-10-03 17-34-25.mp4    

There is some quirk or bug with pasting a list into a table. Seems to me I have to first paste the text into a Frame Text text frame then copy that and select several rows and paste. If I use text copied from a separate application and try to paste it directly into Publisher then I get all the text in one cell no matter how many cells I have selected.
This quirky bug drives me up the wall.
 

Publisher doesn't yet offer a feature to split tables across pages so you'll need to manage them separately.
Tip: Keep the master copy of your table in a hidden layer or in a non-printing section and just keep copies of the split tables on each page. Make edits to the master table and copy it back to the pages as required. It's more work but less work than trying to keep multiple tables in sync.

Issue:
In my Affinity Publisher documents, I tend to use the same text styles. When copying and pasting text between the documents, the styles get duplicated with a number added at the end. This happens even if the styles are identical. Example:

^ These are all the same style which have been duplicated when copy & pasting between documents. 
Solution:
When copying and pasting between a document, Affinity should ask the user how handle duplicate styles rather than just numbering them.
 
Here is an example of how it could work:

This dialogue box would pop up whenever copying and pasting text in situations where Affinity would currently just duplicate the style.
This dialogue box would be optional, activated first via an option in preferences, so users who like the current handling of style can chose not to activate the option. 
Merge Styles - Keep incoming definition This option will cause the two styles to be merged. All values will follow the source document. 
Merge Styles - Keep local definition This option will cause the two styles to be merged. All values will follow the local document. 
Create new style - This will create a new style (which is how Affinity currently handles it by duplicating the style and adding a number to the name).
Additional options:
Clear Overrides - Any differences between the local and incoming style will be discarded. 
Keep Overrides - Any differences between the local and incoming style will be kept as overrides. 
Save Overrides as character style - The differences can be saved as a character style. 
Example:
I have  "Document A" which has  text that has a style called "English translation". This is just Helvetica, bold text 12pt. 
I copy and paste this text into "Document B" that already has a style  called "English translation". If I select "Merge Styles/incoming" then the style from Document A will be used. If I click clear overrides, then any differences between the text in document A&B will be lost. 
 
Who would this be useful for:
This would be useful for users who regularly copy and paste text between Publisher documents. 
 

To use Export LUT you must:
Start with a source image. Modify the appearance of that image by using stand-along adjustment layers. When it looks like you want, you then Export a LUT, which will incorporate the adjustments you made in step 2. Then, you can open a different image, and apply the LUT adjustment from step 3 to it to make similar adjustments as you did for the original image.

In all Affinity apps, it would be really handy if you could copy and paste the following between objects:
X-position Y-position Width Hight  InDesign has a plugin called the Equalizer which allows for this. You press Ctrl + Shift + C to copy values, Ctrl + Shift + V to paste values and Ctrl + Shift + 0 to open a dialogue box which lets you enable/disable values (e.g. so you can select to only copy the X-position). 
Affinity already has methods to align objects already, but being able to copy and paste these values would be super-handy.

new issue raised for this

@PaulsI created a new MacOS account and it doesn't crash. On the old account, I cleaned Affinity's folders in the "Application Support" and "Group Containers" files and the old account started working without crashing.
BUT: If I open a file that has a linked Publisher file (as per this issue) the linked file appears partially blank (e.g. not all the pages render). If I click on the linked file in any way, then the beta will freeze, and I have to force quit it. (This doesn't happen in the non-Beta version of Publisher 2, nor in the previous 1.10 release). 
I have uploaded the problem file, plus also the linked file it uses and the associated crash report. 

I'm afraid I don't have a workaround on macOS. It seems to be fine on Windows. Sorry