Dan C

THAT WORKED! The RGB/8 works perfectly. The RGB/16 imported the image, but there was no option to select layers, and the RGB/32 gave the same "?" as above.
Thank you so much!

Thank you, that works! I actually thought I had tried that too, but I guess not.
At least this is a workaround.

That did the trick (although it's Designer, not Publisher). Thank you very much - very swift help!

Hi @PeterPeterPeter,
As Return mentions above, the Square Brackets [ ] should function as shortcuts to resize your Brush Tool within the Liquify Persona - though there is no option to manually change these shortcut keys in Liquify at this time, my apologies.
I hope this helps

The information I provided is an excerpt of a comment from our developers on the original bug report for the issue that has been logged against all 3 of your threads here on the forums - which can be seen in the 'Tags' section of each thread (AFD-1907).
Unfortunately I'm not personally familiar with font tables and therefore I can't provide much further clarification surrounding this - though my apologies if this does not align specifically with the issue you've reported above.
There are many similar reports of Hindi, Bengali, Thai & Myanmar diacritics failing to export to PDF from Affinity logged in the same development report as your report (AFD-1907) and it's possible the comment regarding Morx tables was specific to one of these reports, rather than a generic comment as to the cause of the issue across multiple fonts/languages.
The issue is still logged with our developers and is a known issue for the diacritics shown in your thread, as well as for multiple other fonts/languages - the exact reason for which may differ slightly between document/font/language, but essentially remains a known, unsupported feature of the apps when exporting to PDF at this time.

Thanks for your report @Seneca!
I can confirm this issue is logged with our development team - many of the users experiencing the crashing are running macOS Ventura, though not all.
Users that don't experience the crash on macOS, and Windows users see the 'Connection Failed' error, which is also logged with our team.
I'll be 'bumping' these issues with your report now.
I hope this helps

Thanks for letting us know @Dlm71 - the behaviour you've described certainly aligns with our current understanding of this issue, in which it only occurs when installing fonts directly through the Affinity apps.
Equally, there is a separate issue logged regarding Adobe Cloud Fonts showing as 'red' when first used, as you've reported above.
I'll be sure to update both the development logs for these issues with your report now and we hope to have this resolved ASAP.
I hope this helps

Thanks for your report @Seneca!
I can confirm this issue is logged with our development team - many of the users experiencing the crashing are running macOS Ventura, though not all.
Users that don't experience the crash on macOS, and Windows users see the 'Connection Failed' error, which is also logged with our team.
I'll be 'bumping' these issues with your report now.
I hope this helps

Thanks for your report @Seneca!
I can confirm this issue is logged with our development team - many of the users experiencing the crashing are running macOS Ventura, though not all.
Users that don't experience the crash on macOS, and Windows users see the 'Connection Failed' error, which is also logged with our team.
I'll be 'bumping' these issues with your report now.
I hope this helps

Just found the - easy - answer... Press shift when click on the triangle and … booom.
Thanks for the great videos! 
 

Thanks for your report @Old Bruce!
Using the above steps from Mike, I'm able to replicate this on both Windows 10 and macOS and therefore will be logging this with our devs now - as I'd only expect Master A to be applied to the newly created pages.
I hope this helps

Thank you so much, that helps a lot. Great customer service! 🙂

Hi @Evgenii,
Thanks for your report - I can confirm this issue is still logged with our development team at this time.
The officially logged bug is due to Affinity not supporting 'morx' tables with fonts, which causes this issue when exporting.
Our dev team have confirmed that adding support for these font tables are unfortunately no small task and although this is something we do hope to implement in the future, we don't currently have any timescale for this - as our team are focusing on other features at this time.
I have updated the relevant bug report with our dev team for you now. I hope this clears things up!

Thanks for your report @anto!
I can confirm that the 'Automatically update linked resource when modified externally' Setting option does not apply to Linked Affinity Documents (.aphoto, .afdesign & .afpub) - these will always automatically update within your parent file when edited.
I hope this clears things up!

Thanks for your report @Peter Panino!
I'm not entirely certain of the exact reasoning behind this currently, though I can see that Affinity macOS is able to create a New from Clipboard document using SVG data, so I would expect Affinity Windows to also support this.
I have therefore logged this as a bug with our development team for you now.
I hope this helps

Unfortunately, that does not work on Designer 2.2.1 for Windows when there is an SVG text in the clipboard:
https://app.screencast.com/LgJJLBOQtXcnK
Please implement this feature. Thank you!

I believe the PDF data from the embedded file is essentially 'missing' from the Affinity document, and the app is trying to determine the file type for the data remaining - albeit incorrectly.
There are a few oddities with this embedded file, including the 'Type' shown in the resource manager, assumedly due to the unexpected status of this embedded data, which is also causing the reported issues when exporting.
As above, I've logged this file with our development team for further investigation, as without the required development tools it would be very difficult for me to be certain of the exact reason for this file being in the 'embedded' but 'missing' state that it appears to be in.

Welcome to the Affinity Forums @Freddie Poser 
Thanks for providing a copy of your file once the object has been converted to curves - with the above document I'm able to replicate this issue.
Interestingly, it appears very similar to a report we've had recently:
As shown in the above thread, the users curve object was not exporting/printing until the Node Handle had been moved for the Curve, or the object had been Flip Transformed.
I'm seeing the same behaviour in your file, therefore in order to resolve this I'd recommend simply moving the Node Handle for the end node of the object slightly, and it should then export -
2023-10-20 17-39-42.mp4
In the meantime I will be updating the development log I submitted against the above thread to include your file, as this should help our developers identify the cause of this and stop it from happening in the future.
I hope this helps

Welcome to the Affinity Forums @Freddie Poser 
Thanks for providing a copy of your file once the object has been converted to curves - with the above document I'm able to replicate this issue.
Interestingly, it appears very similar to a report we've had recently:
As shown in the above thread, the users curve object was not exporting/printing until the Node Handle had been moved for the Curve, or the object had been Flip Transformed.
I'm seeing the same behaviour in your file, therefore in order to resolve this I'd recommend simply moving the Node Handle for the end node of the object slightly, and it should then export -
2023-10-20 17-39-42.mp4
In the meantime I will be updating the development log I submitted against the above thread to include your file, as this should help our developers identify the cause of this and stop it from happening in the future.
I hope this helps

Unfortunately I can't comment on the icon as I'm not personally certain how these are obtained and displayed by the app for each object currently, though I can verify the layer name (which is user definable) is a completely separate layer property, which has been present in the Affinity apps pre-version 2 - unlike the layer 'tags' - and therefore is completely independent.
I can only provide the information I am given from our team internally, and based on the info I can publicly share, I understand that the cause of this issue is currently due to how artboards are handled within Affinity - as a sudo Rectangle object, therefore I don't believe this to simply be a change of text string within the Affinity codebase to resolve the tooltip issue, and that is what I wanted to clarify here.
I don't disagree that the label should be correct and show 'Artboard' for these objects, so rest assured I have updated the development log regarding this issue for you once again.

You get the Trial by installing from the iPad App Store. That will install V2 as a separate application, in Trial mode, and you'll have both V1 and V2 on the iPad. When you're sure you want to purchase V2, you can make your purchase.

Thank you both for your super-fast replies! I'll go for your suggestion, @Dan C 🙂

Hi @tallonius,
Thanks for your report!
I can confirm this is known issue with Adjustment dialogs when using 'Floating' document tabs, whereby the Adjustment controls are drawn behind the 'floating' canvas window.
Please navigate to Window > Arrange > Dock All, which will stop the canvases from 'Floating' over the UI and display the adjustment dialogs as expected.
I hope this helps

yes, that's fixed it - thanks!

Hi @Lon,
Welcome to the Affinity Forums
To expand on the above, as the Affinity apps use a shared document format between Affinity Photo, Designer and Publisher - although each app uses a different file extension (.afphoto, .afdesign & .afpub respectively) these are completely interchangeable - meaning you can open and Affinity document in any Affinity app, even if it doesn't 'match' it's namesake, or you can actually rename an '.afphoto' file to '.afdesign' and it would retain all of it's data and still be openable within any Affinity app.
For this reason we're unable to categorise the file format as an 'Image', as this would then also affect .afpub or .afdesign files that don't necessarily contain any images, and this would cause confusion for part of our userbase.
Therefore any of the Affinity file formats are simply sorted under 'Other'. 
I hope this clears things up!