Hangman

Confirmed in Publisher 2.2 on Windows 10.
Also, in my limited testing, the zoom level is slightly different between using the two methods – slightly higher percentage value when page is double-clicked in Pages Panel.
Like you say, it’s a minor issue, but fixing it would make for a ‘smoother’ user experience.

Hi @legolas,
I don’t think there’s anything wrong with your file and likewise I’ve seen several reports of slow export times with 2.2.0…
Hopefully, someone from the Serif moderation team can provide some further insight as to why this is happening…
Could you confirm which version of macOS you’re using, Ventura or Sonoma?

Hi @legolas and welcome to the forums,
FWIW, I ran a test on an Intel MacBook Pro, AMD Radeon R9 M370X 2 GB, 2.8 GHz Quad-Core Intel Core i7, 16 GB 1600 MHz DDR3 and to export all 1,240 pages (620 spreads) using the PDF (digital - high quality) preset took 34 mins 30 secs...
I'm unsure what to conclude from that but is your export time with other apps open or just with Publisher open when exporting? (I had several other apps open during the export test) I'm also assuming you're running Publisher v2.2.0?

Hi @Dan C,
The sRGB v4 ICC preference profile is simply a v4 replacement for commonly used v2 sRGB profiles. According to the ICC website, "it gives better results in workflows that implement the ICC v4 specification. It is intended to be used in combination with other ICC v4 profiles."
I have it installed on my system.

The file has been uploaded to dropbox.   I opened a duplicate of that file just now, to see what I probably did. There were so many corrections to be made on each page (usually including changing selected text from red to black) and adding small margin text frames, that by the time I gave up in despair and posted the video I couldn't remember how it all started.  So I checked.  Initially I used the Pages Panel to click on the spread I wished to edit, then used the hand tool to move the pages on the screen.  But as I needed to work my way through the various phrases on a page, I would have used the vertical scroll bars.  So I haven't found something new.  The only thing I have found (probably everybody else has too) is that it is a constantly repeating problem.  It doesn't matter how often one uses the CMD + 1 or CMD +2 manoeuvre to reengage the Text Frame Tool, or the Move Tool, the minute one uses the scroll bar the problem reappears.  It took me over an hour to make the changes I needed to make on a 20 page document!  
 
Answer in my post above.  Should add that once the scroll bar starts the issue, clicking on the Pages Panel to change the spread makes no difference. 

There's been no official word on this as far as I'm aware but users also need to understand that the PDF file format itself doesn't support variable fonts either which means any software producing a PDF has to convert the variable font to a legacy format or generate each static instance prior to export.
Whether this functionality is on the radar for Affinity apps, I really have no idea I'm afraid.
I think it would perhaps be helpful if the support (or the current lack thereof) for Variable Fonts was added as a question to the FAQ forum.

Just a quick update, I've now found another way to replicate this, press the Tab key to hide the UI and again to bring the UI back, now select something and you won't have any bounding boxes or if you've clicked in a text frame, you won't see the text caret until you zoom in and out or pan around the page.

It bascially converts strokes into fillable Curve's ('Shapes')...
Approach
Use strokes to create your initial Celtic Knot design Expand the Strokes Use the Shape Builder tool to merge the Expanded Strokes to create the overlaps and underlaps Use the Vector Flood Fill tool to fill the merged shapes

Hi @jmwellborn, out of interest, how did you navigate to pages 16 and 17?

Very odd, opening your pdf using 'Estimate' opens it as an RGB image (for me), opening and selecting RGB does the same, opening using Greyscale creates a true greyscale file, certainly not as per your earlier screengrabs and opening as a CMYK file works as expected so I'm really unsure why you are seeing what you are seeing when opening the pdf but glad @walt.farrell had a resolution for you...

PDF Colours.mp4

Hi @NathanC,
Many thanks for checking internally and for clarifying the current behaviour in scenario 1 as being the expected behaviour and also for logging scenario 2 behaviour as an improvement with the developers.
Interestingly, to further back this up you may be interested in this thread which highlights another instance where the current expected behaviour fails... This example effectively mimics the current scenario 1 behaviour and again fails for similar reasons, i.e., because of which elements from the applied spread are and are not detached when applying the Master to individual pages...
It differs slightly here because the 'Chapter Headings' are not linked on the Master when they appear on both the left and right pages of the spread but the same logic applies, i.e., if when applying the spread that has a Chapter Heading on both left and right pages to an individual page, if the left instance of the Chapter Heading were detached and deleted when applying the Master to a right hand facing page and likewise the right instance of the Chapter Heading were detached and deleted when applying the Master to a left hand facing page then the automatic Chapter Heading numbering 'would' be correctly applied where currently it isn't.
Hopefully, that makes sense...

Hi @Gigatronix Pete,
Without seeing the physical Affinity files it's going to be tricky to diagnose, are you happy to upload both so we can take a look at what might be going on?
Could you in the meantime also confirm which particular PDF preset (or PDF Version) you're using so we can ensure we're working to the same criteria...

Hi @NathanC,
Many thanks for checking internally and for clarifying the current behaviour in scenario 1 as being the expected behaviour and also for logging scenario 2 behaviour as an improvement with the developers.
Interestingly, to further back this up you may be interested in this thread which highlights another instance where the current expected behaviour fails... This example effectively mimics the current scenario 1 behaviour and again fails for similar reasons, i.e., because of which elements from the applied spread are and are not detached when applying the Master to individual pages...
It differs slightly here because the 'Chapter Headings' are not linked on the Master when they appear on both the left and right pages of the spread but the same logic applies, i.e., if when applying the spread that has a Chapter Heading on both left and right pages to an individual page, if the left instance of the Chapter Heading were detached and deleted when applying the Master to a right hand facing page and likewise the right instance of the Chapter Heading were detached and deleted when applying the Master to a left hand facing page then the automatic Chapter Heading numbering 'would' be correctly applied where currently it isn't.
Hopefully, that makes sense...

Yes, that's indeed the behaviour I tried to describe as well, so we are on the same page. My only doubt is that if the cross-reference happens to be on another page or outside of the current view, should the view be changed or not? While I said no earlier, I guess it doesn't do any harm either.

I think based on the screen recording this is the same issue @Intuos5 is highlighting on Windows but please correct me if I'm wrong, as in, clicking a cross-reference in the panel doesn't select the field and I assume vice-versa. It's only currently selected when clicking the 'Go to cross-reference' icon in the bottom left of the panel...

Chapters.mp4

Apologies, totally misread that… 

The 183 text shortcuts available in Affinity Publisher 2.2.0 on macOS just in case anyone wants to compare them to those available on Windows...
Publisher Text Shortcuts.xlsx
Publisher Text Shortcuts.pdf

Thanks @Hangman,
Just checked and found this particular artboard issue has been logged with the developers since! I can also replicate it on a new file, looks like it needs the 'Auto update linked resources' enabled for it to trigger, I'll bump the existing issue.

Hi @Dan C,
Thanks for the detailed explanation which is very much appreciated. It sounds as though the cause of the issue has been identified really quickly and will be resolved equally as quickly which is great to hear… 😀

Thank you to you (and others) for all the job of bug tracking you do. 
This one gave me also the opportunity/courage to report one that annoyed me from my very beginnings on Affinity. 

Hi @Dan C,
Thanks for the detailed explanation which is very much appreciated. It sounds as though the cause of the issue has been identified really quickly and will be resolved equally as quickly which is great to hear… 😀

Hi @Oufti,
Many thanks for testing and clarifying you’re seeing the same issue, very much appreciated… 

I see the same failing behaviour as @Hangman with 2.2.0 and Monterey 12.6.9, wether the system preference for Tab navigation is ticked or not. (I don't have previous version installed anymore to compare.)
To see it happen:
Check that width and height fields are linked in Document settings Click once in the width/height field — that will select all its content: [210 mm] Click a second time in it, in the number or just after it (that is important!) — that will insert the cursor inside the field: [210| mm] Add/delete a single cypher (digit) to the present number [2100 mm or 21 mm] Press Tab The other field is not updated — Note that on step 4., you cannot type/delete a second cypher consequently.
Instead of the second character you type, it loses focus and beeps. You have to click again in that field to continue to type in it. 
This latter bug is probably not new. 
Possibly related bug
 
 
 

I'm not 100% certain, but as I understand it this issue is not specific to a certain OS version (or even a certain OS) as it can occur on Windows also.
The reason that some users see the 'incorrect' list, when others do not - or that some users see the 'incorrect' list only in certain Affinity apps, but not all Affinity apps on the same system is unfortunately something I'm not knowledgeable enough to answer, my apologies.
However, our devs seem to have identified this cause (and they certainly know more than I do!) so I am confident this should be resolved across all platforms/OS versions, once the fix is made available via beta/release