Sean P

I've just poked the file some more and found its down to using semi transparent gradient stops in the Gradient Overlay FX with Artboards. Does the issue go away if you delete the artboard and keep the objects? Also can you attach a screenshot of the Performance section of the Settings dialog for the affected apps please? How does the Navigator Panel render as well?

Thanks for re-uploading! I will check back later on Because the issue you're seeing looks related to the way things are being rendered, and having different monitors of multiple resolutions and scalings have caused rendering issues within the app. There were many variables as I said based on where the app window was, and the screen the app was started on that caused the rendering to be different so I want to try and rule these out. There was an issue that was causing Effects to be output incorrectly to PDF and the Export Preview was representive of this. The only way you would have seen that in the main window, was if you was importing the exported PDF back in, which I assume is not what you're doing? Have you tried opening this with external monitors disconnected at all or on your iPad as I suggested please? Also are you able to attach a video recording of the whole screen from a fresh launch that demonstrates this please?

Unfortunatley it looks like that upload might have failed as I can only see your original file and no package - not sure if thats because the zip on Dropbox is the same name as the one you tried to upload? I've had a look on a different MacBook Air and it is still rendering fine for me on both Designer and Photo 2.4.2. Your sig mentions Ventura - are you still using this or have you upgraded to Sonoma? All the machines I'm using are Sonoma. Also regarding screens have you tried disconnecting any external screens and just using the Macbook Pro's built in screen? I'm wondering if this is another issue that is being exhibited, by the rendering oddies that appear when using two screens with different scaling. As I mentioned previously the screen you launched the app on and the app window on all has an affect on what happens, so that might explain potentially why 2.4.1 Retail looks fine and 2.4.2 isn't/2.4.2 Publisher is ok. Have you tried loading the file on your iPad to see how it renders on that?

Thanks for the file Ronnyb. I've tried it on my iMac (Intel Sonoma), MacBook M1 Pro (Sonoma) with an XDR dsiplay and also had a few people try it on their Macs (combination of Macbook Air M1s and iMacs) and we're all unable to reproduce what you're seeing with 2.4.2. I did also install the Alumni Sans fonts (both from Adobe fonts and Google Fonts) and whilst most were detected, the main text wasn't, however I don't feel this would cause the problems you're seeing. Photo, Designer and Publisher all displayed the same for me.

Hi Ronnyb, Please use this link and we'll take a look! https://www.dropbox.com/request/4MhCvJkTqRaZ6fZMkxV8

Hi Philipt18 I've passed the crash logs on to development who have said that the crashing is coming from Preflight checks relating to a broken or unexpected pinned object glyph within the file (as @Pauls suggested above). These will be specific to the document you are using, so unfortunately without that, we are unlikely to be able to reproduce the crashes you're seeing. If you could send us the document you're using to our internal Dropbox account then we can try to investigate more. Also if you're able to find or remake the video demonstrating the crash that would also be very helpful. In the meantime can you try disabling Preflight and see if that stops the document you're using from crashing, please? https://www.dropbox.com/request/eIZQSr7E9DE5KzZ0vRmb

No worries - that is a shame though! Do you happen to use external monitors with your Mac at all?

D'oh It is indeed, I had it in my mind you were on Windows. Thats certainly not going to help you on macOS is it! Unfortunately macOS isn't as simple as Windows, but if you try and temporarily rename the 'com.seriflabs.affinitypublisher2.beta.plist' (whilst the app is closed) from the location below and then the app. It should generate a new plist with the default options, and see if that is still causing you problems. ~/Library/Preferences/ Thanks!

Hi Hangman, I'm wondering if this is a setting you've got on the Beta? Could you try renaming the '2.0 (Beta)' here: %userprofile%\.affinity\Publisher\ so a new one is created and then see if that is affected. If it is not would you be able to zip up a copy of that folder and send it over please? https://www.dropbox.com/request/fw74GhUGN4kPp9OeWavr

Thanks Anto and thanks to MikeTO for the steps! I've now logged this with development. I'll also get the Option drag issue you mentioned logged separately as well.

Ahh I'm seeing this now - I suspect this is actually By Design. When Filler Text is inserted as Filler Text it will always add text to fill the space it occupies. This means that if you have some text after that point it will get overflowed (as evidenced by the Overflow marker on the text frame), so when your clicking to fit the text, its fitting it and then the filler text is likely filling up the space, forcing it to overflow again. I'll pass it on to development to see what they suggest, but I'm not sure mixing filler text with real text is a proper use case - certainly nothing I've ever encountered before! EDIT: Just to add: As filler text will always add text to fill the space it doesn't have a defined word count, so this means it cannot ever flow to a defined page count, so will only do it page by page.

That is very strange! What Input Source is your macOS set to, and do you have any other utilities running that might interfere or relate to the keyboard at all?

What macOS Keyboard Layout and physical keyboard model are you using? I've tried it with both British GB and Ukrainian layouts using the built in keyboard on a Macbook Air and its still behaving as expected.

Hi Anto, This is working fine for me using 2.4.2.2371. It looks like you may have option held down instead of shift? Holding Option and clicking will flow the frame page by page (which is what is happening in your video), where as Shift will flow the entire contents and make as many pages as it needs. Screen Recording 2024-04-05 at 11.37.39.mov

Thanks very much for the file! I can reproduce that here and it looks like its potentially related to the fact that the Warp Group has moved quite a distance from its origin. I'll get this logged with the development team. In the meantime if you place your image inside the curve (and remove the frame) it should be able to achieve what you want - see the attached file. bug_warp_group_resaved.afpub

Hi Anto, I think the issues you're seeing are very specific to the way your using Mesh Warp groups. Looking at what you're trying to do I don't understand why you're using a picture frame for the image. Just clip the mesh warp to the image you want to use for the shadow; the Picture Frame seems pointless in this instance. Would you be able to attach the document your video shows please. When reporting stuff please do try to attach all supporting files you've used to replicate your issues as these can be a massive help to us. Either way I've tried to replicate the layout your video shows but I don't get any rendering issues you're seeing. I've attached the file I've used and a video showing the rendering behaviour I get. Video.mp4 TestSetUp.afpub

Thanks all for your comments! I just wanted to let you know that these have all been logged and with development. Regarding the actual missing search bar, unfortunately, that is currently to be expected due to (as I understand it) its reliance on the macOS Help Viewer. However, we are aware of this and are looking into a replacement for it!

Hi philipt18, Unfortunately, this link isn't working for me - are you able to resend it, and if possible with a link to the file you're using, please? Is it the same file you're having crashes with or has it happened with several unrelated ones? Thanks!

Hi Vehmann, I was actually re-testing this fix yesterday and unfortunately I'm still not 100% happy with the fix. It is now working if you use the 'Colour Handling: Performed By App' option within the Print dialog (which is the default option), however switching to 'Performed By Printer', it is still problematic, so I've had to reopen the issue. You should see the partial fix in the upcoming 2.4.2 build (keep an eye on the Beta forums if you wish to try it out), however as I said above, there are some instances where it is still incorrect, so it has been reopened for further investigation.

You're more than welcome! If you're using the Vector Flood Fill Tool then it is definitely worth learning about the Appearance Panel, as depending on your VFF options, you can end up with multiple fills on an object, so that certainly sounds like what happened here.

I suspect the Bitmap Fill would have created a second 'Fill' in the Appearance Panel, leaving the original colour present. You can delete the empty fill from the Appearance Panel which will select the red fill allowing you to edit it. Alternatively you can click the red fill in the appearance panel yourself to select and it it (the white dot should be present next to it letting you know its the actively selected fill).

Hi Anto, Your crash reports were passed onto development, but the supplied reports were not able to provide sufficient information into the cause of the crash (and no ChatGPT doesn't say anything new that isn't already in the crash reports). Unfortunately without a recipe, there is nothing that we're able to do, to really identify the cause and solution to your crash. Unfortunately this is often the case with one off, non repeatable crashes - the reports cannot always identify a cause. It does seem like you keep doing similar things, so its worth trying to try and narrow down what you're doing to get a reproducible recipe, but realistically without that, there isn't anything development are likely going to be able to do. For example in this thread below you have given us ZERO (not even what part of the app you were using) information on what you were actually doing at the time of the crash. Whilst crash reports can help narrow something down they don't make people into mind readers. As we have said numerous times before please try to give us much information on what you were doing at the time. We don't ask for this information for no reason, and unfortunately sometimes we're just unable to reproduce the crash you're getting - its not that we don't believe you, but attempting to fixing a crash that cannot be reproduced makes things a lot harder, let alone one we have almost zero information on.

My apologies - I thought you meant you had seen the issue listed on the list of issues fixed in 2.4.0 (the thread I linked to), but in context with your last post I understand that is not what you meant. As tzvi20 has mentioned above, the issue is still an open issue in our issue tracking software and is still with the development team to be fixed. Unfortunately, we do not have any control over what issues get fixed by development, and in what order. However, what we can do is keep track of the amount of reports each issue gets which then gets used as a factor for deciding which issues require fixing. Again I can only apologise that this is still an issue for you, I will bump it again with development and try to bring some attention to it.

Hi Satopian. Which issue in the fix list are you referring to? This issue is still currently with development, and I don't see any reference to it here:

Hi bbrother, This is something we're aware of and is logged with development to be fixed. Regarding Hangman's video - the only reason the length affects the Stroke Width is that Hangman has 'Scale with object' enabled in the stroke panel, so when the object is resized, the stroke is scaled relative to that to try to ensure the scale of that stroke is maintained with the resized object.