Dan C

Sorry to hear this - it's certainly strange that Publisher has not generated a crash report for this. Your Event Viewer log may show more information in this regard, even when a crash report is not generated. To generate the eventviewer log, please do the following: 1. Open Windows Run (Windows Key + R) and type the following - eventvwr 2. In the window that opens, select the Windows Logs drop-down list on the left and then Applications 3. With the Applications logs selected, navigate to the right side of the window and select Save All Events As... and save them as .evtx (the default option). 4. Attach this saved file to your reply here. I'm not seeing this behaviour here, nor have I seen similar reports of this occurring. It appears as though this might be a rendering error after opening a document - if you zoom in the file do you find it then appears 'fullscreen' as expected? It's hard to be certain from the screenshots you've provided - are your documents 'Floating' in Publisher? If you navigate to Window > Arrange > Dock All, do they now appear 'fullscreen' as expected? Did the app generate a crash report directly for this crash? If not then hopefully the aforementioned Event Viewer log will have more info for me to assist

Thanks for your report! This is certainly interesting, I've opened your document and tried to replicate this and have thus far been unable - even after closing & reopening your document multiple times. I was able to add new Symbol instances from the Symbol Studio, Copy/Duplicate the Symbols added and then continue to drag new instances from the Studio as expected - Do you notice this issue only occurs following a copy/paste step, or can it seemingly occur randomly after any action? Unfortunately if we're unable to replicate the behaviour internally then I couldn't log this as a bug with our team so any further information you can provide to assist this process would be helpful

I agree with both points, the FAQ could be more specific in this regard and needs the second instance of this requirement noted - so I've updated the FAQ again to include both of these __________ Thanks for verifying this for me, I'll be sure to let the development team know in my bug report. Affinity 2.2 updated the PDF library used when exporting, so I suspect the failure to export is related to the new PDF library version and should be fixed in a future update. The easiest way to see your embedded file type is using the Resource Manager, as this indicates which of your embedded images are .BMP, .TIFF, .JPEG etc. However the resource manager does not indicate which BMPs are using transparency. As mentioned previously, if you look at the main Image on Page 11 in your file, you can see this has transparent areas around the white 'cutout' of the image (you may need to enable Transparent Background in document setup to clearly see this), which is an example of such image that causes issues when exporting to PDF at this time. Unfortunately there's no direct way to locate all BMPs using transparency in your file, essentially in order to fix the document that I've returned to you, I spent hours inspecting each placed BMP resource for transparency and Rasterising these images until the file successfully exported to PDF. You should only need to 'rasterise' any new BMP images with transparency introduced into the document I've returned via Dropbox, as this version of the file has had all current transparent BMP files rasterised. Of course this is only a required workaround whilst our devs work to resolve this issue internally. You should have received an email from Dropbox with a link to download this repaired file by now - can you please confirm if this has been received on your end and if you are able to successfully export this repaired document on your PC?

Thanks for your file provided and my apologies for the delay here! I can confirm there are 2 things happening in this file from the recording you've provided - firstly the reason you're seeing this in the Wireframe view mode is that when creating a selection in the view mode, the application selects the Objects within your Groups layers directly, rather than selecting the Group layers themselves. When you then Group this selection, the objects within the Groups of the Symbol layers are 'pulled' from the Symbol layers into this new Group. This is technically expected behaviour when you've made a direct selection of objects within a Group layer that is a symbol, (that is, it's expected for the objects to change their layer order when grouping with this type of selection, but it's not expected for the layers to move or scale, which I've covered below separately), however I can certainly understand why this would appear unexpected based on the type of selection made whilst in the Wireframe view mode and therefore I'm logging this as an improvement request with our team to make considerations as to how the app should behave when making selections of Symbol objects in the Wireframe view mode. The below recording shows the difference the Layer selection makes when Grouping these layers - 2023-10-16 13-43-58.mp4 Secondly, based the knowledge above, the issue shown in your recording when you select the objects and group them, causing them to move or scale unexpectedly can be replicated outside of the Wireframe view mode, provided you manually select the layers within the symbol first. This is a bug that I can't personally explain at this time, as there's no obvious constraints etc applied to the objects and therefore I will be logging as such with our development team, to be resolved in a future update. I hope this helps!

Welcome to the Affinity Forums @lrevans89 Our developers have responded to the bug report to confirm that the font picker in Affinity 2.2 is provided by the OS and not something we have direct control of. According to the team we used to render our own font picker but had to change it to the OS one, following the iPad OS 17 update, therefore we believe this issue to be caused on Apples end. At this time, were awaiting an update from Apple to address the issue and therefore cannot provide any estimated fix timescale, our apologies.

Thanks for verifying that for me - inspecting your crash reports provided appear to show the app is crashing due to 'marching ants' (used to indicate an active selection) though I cannot see an active selection in your recording, so this is a little strange. Our team would like to request a copy of your log.txt files in order for our devs to investigate this further. To find this please open Windows Run (Windows Key + R) then paste the following string and press OK: If using MSIX - %USERPROFILE%\.affinity\Publisher\2.0\ If using EXE - %appdata%\Affinity\Publisher\2.0\ In the window that opens, please select log.txt, then attach this to your reply here. Many thanks once again!

Hi @borntobe, You can hide the Affinity apps UI using the TAB key as a toggle, effectively giving the canvas as mush space as possible on your screen whilst editing. I hope this helps

Hi @mpstaton, Thanks for your post! If I've correctly understood your requirements, you can achieve this by simply Grouping your multiple vector objects, then applying a Gradient using the Gradient Tool to the Group layer, which will reflect the gradient through all objects within, without the use of Mask layers - 2023-10-16 11-12-53.mp4 Does this achieve the results you're looking for please?

@NAK, in regards to the original issue reported, your PDF export is failing due to the BMP files with Transparency within your document. Our developers have confirmed this issue and I'll be logging it with them now, in order to be resolved in a future update. They have requested a little further information regarding these files if possible, in what app are they generated? Are you able to attach a copy of one of these files in a .ZIP folder that has not yet been embedded into a Publisher document? (for an example of the type of file I'm referring to, please see the main image on Page 11 of your document, which is a BMP file with transparency around the edges). In the meantime, unfortunately the only workaround I'm aware of is 'Rasterising' these images into your document before exporting, which will convert them from being an Embedded BMP file to a local Pixel layer, saved within the Affinity file itself. I have meticulously performed this on your document and returned it to you via Dropbox, to the email address associated with your Forum account. This version of the file should hopefully export to PDF as expected for you, as it has exported correctly for me. I hope this helps and our apologies for any inconveniences caused due to this!

Thanks for letting me know, I'm glad to hear this is now working as expected for you! Step 1 of the FAQ is currently: 'Close Affinity' - as it's required in order for the terminal prompt to take action. I'll try and highlight this in the FAQ to avoid further misunderstandings

Thanks for letting me know - a colleague of mine has tried this on Catalina using the Terminal command and this has produced a log file in v2.2, so I'm unsure why this isn't working for you at this time. Are you using the Affinity Store or Mac App Store version of the app? Is this the same for V1, where the log is being generated? FWIW, I have tried the command on my Sonoma mac and it generated a log as expected when exporting a simple file with a rectangle to PDF in both V1 & V2 from the Affinity Store. I can't explain that behaviour, perhaps as there is a profile installed (in use?) on your Mac with the same name, the Affinity app would perhaps embed that 'iMac' profile. All of the above testing I've performed with R C-Rs specific file has been on Windows, where there is of course no such profile.

There is no issue with the contents of thomasos post above. They are simply another user of the Affinity forums and have as much as right as anyone, including yourself, to post here. If you don't wish to see replies from specific users, please use the Ignore function. As I understand this should mean the replies from this user are hidden to you. It does not 'block' their ability to post within your thread (nor should it). Please do not '@' tag myself or other forum moderators like this publicly if you have an issue with a post or a user, use the built-in report function of the Forums and this will be dealt with as required. I am locking this thread from further replies. I hope you all enjoy your weekend.

The file I have updated is specifically for the Windows Registry key, I checked with our team and they confirmed the mac terminal command should not need updating for 2.2. Therefore I'm unsure why you're not seeing a log file being generated at this time, but I will be sure to check the command on macOS here to make sure this is working for me as expected. The error in the file above is due to the 'iMac' Colour Profile set against the document, the presets you've mentioned are attempting to embed this profile in the PDF export and failing: [Last exception 1910 in PDF_load_iccprofile]["Tried to allocate 0 bytes in function pdc_icmAlloc_calloc"] Changing the Colour Profile in use for the document, or choosing not to embed this profile when exporting resolves the error with this file. I'm not 100% certain if this is due to the known issues with ICC profiles in 2.2 or if the profile in use is corrupted, meaning it simply cannot be embedded by Affinity. I hope this clears things up

Hi @Mariusz go, Thanks for your report! I can confirm our team are aware of this issue and we're working to resolve it as soon as possible, I'll be sure to 'bump' the development log with this thread to bring it to our teams attention once again. I hope this helps

Many thanks for providing that for me! I've been able to replicate this issue and have logged it with our development team internally. In the meantime, please find a copy of the document below, where I have expanded these strokes correctly for you - Airplane_F.afdesign I hope this helps

Thank you for trying that for me and the additional screenshots provided above - our team are yet to replicate this behaviour here or understand the exact cause of this on your machine, as there is no clear indicator for this to occur. Firstly, we'd like to see if the same issue happens in the 2.1.1 MSIX versions of the Affinity apps to see if this is related to the latest update or simply is coincidental timing. Currently I believe you have the 2.2 EXE versions installed, which can be left as-is, as you should be able to install the MSIX versions simultaneously, provided they are not the same version number. Please visit the below link and select the 2.1.1 download option for MSIX then install as normal - https://store.serif.com/update/windows/photo/2/ Once installed, please launch this app - you should know you've launched the correct version as you'll be prompted to update to 2.2 upon launch, please simply close this dialog without updating. Does the 2.1.1 MSIX version of the app crash in the same way as 2.2 please? If so, our team recommend creating a new user account on your PC and installing the latest version (2.2, either MSIX or EXE) on this new user account, then repeat your testing. Does the app crash on this new user from the same workflow as before, or does this work as expected?

Hi @PierMax, Thanks for your report & I'm sorry to see you're having trouble! Can you please provide a copy of your Affinity document that shows this issue, so I can investigate further? Many thanks in advance

Hi @Phoenix078, Thanks for your report and I'm sorry to hear you're having trouble! I can confirm that our team have recently replicated this issue when saving/loading Affinity documents from an iCloud location on Windows, whereby the app will eventually lose access to the original file location, causing the error message you're seeing. This is a bug within the Affinity apps and has been logged with our development team to be resolved ASAP. I'll be sure to 'bump' the development log using your thread now to bring it to our teams attention once again. Unfortunately, outside of using Affinity V1, I'm not aware of any workarounds for this issue at this time - my sincerest apologies for any inconveniences caused due to this.

Thanks for letting us know - what % scaling value were you using in Windows that caused the crash to occur please? I understand you have set this to 150%, which stopped the crash from occurring, but I'm not sure what your previous value was originally that showed this issue

This is expected behaviour, as the error message referred to in step 4 of the FAQ is the 'Error whilst exporting to PDF' error the app throws when a user is unable to export to PDF, for example: If you're exporting a document that doesn't error, the PDFlog will still be generated, simply this part of step 4 can be ignored from the FAQ as the PDF export was successful on your device

Many thanks for letting me know - I can confirm I've been able to replicate this crash after linking your resources within these files and having both open at once, and I believe I have determined the cause of this. Reflect0881 has a placed .PSD file, which appears to be in an unexpected state. Although the Resource Manager shows this as Embedded and I can select the file and use 'Edit Document' as expected, I'm unable to use Collect from the resource manager on the file, which isn't something I've seen before. After linking all other resources in both documents, then saving, closing and reopening the files, Reflect0881 causes the app to crash when zooming. This issue stops after deleting the Embedded .PSD file from the document. I'm not entirely certain of the cause of this at this time, though I would recommend deleting and replacing this file on your end using the source PSD and hopefully this should stop the crash from occurring for you, which using Linked resources. I hope this helps

Thanks all, my apologies as I've found the PDF liblogging file was outdated - due to the Affinity apps updating PDFlib (the Library used to write PDF files) in v2.2, the logging file also needed updating, hence the reason a log was not being written. I've since updated this file in the FAQ to support the new PDFLib version, though I don't require this to be used in this case as I now have a copy of the file in question ____ In regards to the issue being reported here, it appears to be errors caused from certain BMP files in the document, though this isn't an issue I've come across previously and therefore have escalated this issue with our team internally. I'll be sure to respond here ASAP with any further information I'm provided. Thanks for your continued patience and understanding!

Thanks for your file provided @jackamus! The issue in your file is due to the Compound object - you have a very strange layer setup for this object, which includes multiple compounds within the same compound shape, some of which are simply empty compounds within a compound group. It appears as though this is causing a recurring mathematics error for the Compound shape, setting the X& Y location, as well as the Height & Width of the object to; 15220468541834272403530696713984091417512736516259435112031139106814910766953401025357054709781589502319562428582293058800246641899534378429240315730800057085531258937648020520853768518830879150395566171888181809594625546509775424923231356337594894783572486312364486501173963294843541702712847289214866292736 mm As you can imagine, when the app tries to copy an object that is impossibly large, it simply crashes. Although Compounds are compatible to be nested within other Compounds, there is clearly an issue caused from to your layer setup in this file. I've been able to replicate this by creating a Subtract Compound, then adding an Add Compound within this and deleting the object within the Add Compound. The app then cannot calculate Subtracting an infinite Addition and the above issue occurs. I'll be logging this with our devs now. As this is a relatively simple shape, you can create this using a single Compound and it will work as expected, retaining the correct H&W values and the ability to be copied, etc - Please find a copy of your file with these fixes applied below: Spring winder 1_F.afdesign I hope this helps!

Thanks for providing that for me! As mentioned above, please ensure you are holding the Shift Key when using Place, otherwise the document will be automatically placed on the first page in your active selection (Page 1) and the Place Panel won't be shown. I can see in your recording the document is immediately placed within the frame on Page 1, indicating you don't have this key held down. Equally, you shouldn't need to select both pages in the Pages Panel before using the Place Tool either, though provided you are holding the Shift key as required this shouldn't technically change the behaviour experienced.

No problem at all, please upload the document to the below link for me: https://www.dropbox.com/request/BSPyqXAqLxcFRuIr1btb Once uploaded, please reply here to let me know!