Sean P

Thank you very much for the crash reports and the fonts. Whilst I still cannot replicate it with those fonts installed, the crash reports do seem to be working this time. I've passed these onto development, so fingers crossed these shine a light on what is happening!

Hi Walt, I believe this behaviour is correct - its appears to be a quick refresh of the thumbnails. There was an issue with them not regenerating previously, and I believe this has been done to address that. I'm checking it with development however.

Thanks for that - I can reproduce that and will get it logged - it does appear to be a regression over 2430

Because this is exactly how Stroke Variance is designed to work in accordance with the Pressure Graph. Notice at around 24-25seconds the pressure graph is rescaled, so whilst the stroke is 287pt it looks a lot thinner as it has a very low pressure graph. This is pretty much how the app has worked since its inception.

This is the correct behaviour. You have enabled 'Lock Line Weight' - once enabled the the stroke width will not change by increasing or decreasing the point size using the stroke width tool. If you unlock the 'Lock Line Weight' option you will find it does update to be a smaller value if you reduce the widest point of the stroke. LockLineWeight.mp4

Thanks Hangman, The fix for this was only intended to address the text in the Text Style Editor to make it consistent with the Character Panel (which was initially different due to space constraints). Regarding the Character Panel labels apparently these should be a slight variant of title case and that was logged separately.

Thanks for the letting us know Anto, but unfortunately without any more information, sample files, videos or even a crash report there is nothing we can do to address this. Is this something you're able to reproduce?

As others have said we have the crashes, and the incorrectly displayed items logged. However I cannot reproduce this on macOS or Windows. Do you have a video showing the behaviour you're getting with this and can you attach the file that shows this please?

Thanks for those - unfortunately I'm still not having any luck in reproducing it. Are you able to get a screen recording (of your whole screen) showing the steps you're doing and the crash please? Lastly could you also zip up the contents at the following locations and send me those please? %userprofile%\.affinity\Publisher\2.0 (Beta)\ C:\ProgramData\Affinity\ The .aff file is known as the Affix file and what contains the rules for the spelling. The hyph file is what controls the hyphenations. If you replace the your fi_FI.dic file with the one in the site I linked to earlier does the issue go away? Thanks!

Thanks for that! Looking at the crash it certainly looks related to the a spelling error. The file you've attached has 'Check spelling whilst typing' disabled, so I suspect thats why you're not seeing it anymore? With that said I did try your dictionary file, but that is missing the .aff file and also seems to differ partially to a different one. I tried the one below (with all 3 fi_FI.aff, fi_FI.dic and hyph_fi_FI.dic files present) and wasn't able to get it to crash still. There wasn't any other files in your fi_FI folder was there? I'll keep poking!

Also unfortunately the crash report you've given us doesn't seem to want to debug either. Are you able to generate and attach another one please?

Thank you for the files! Unfortunately I'm still unable to reproduce the crash you're getting and cannot see anything obvious myself in the Process Monitor log, though I have passed that on to development to see if they can. In the meantime are you able to go to C:\Windows\Fonts\ and select all the fonts, copy them to a new folder (via Ctrl+C, Ctrl+V) and then zip and attach that to Dropbox please if it isn't too big?

Thanks for that aji, and also kenmcd for your image. I've passed these on to development to find out what the correct behaviour should be.

Hi Robocat, I'm not able to reproduce this myself, however looking at your document I can see that it is using Finnish spelling and hyphenation languages. I can only assume that you have Finnish Hunspell dictionaries set up on your machine? If possible are you able to attach those please? By default these are stored in: C:\ProgramData\Affinity\Common\2.0 (Beta)\Dictionaries\ Finally could you go to %userprofile%\.affinity\Publisher\2.0 (Beta)\CrashReports\reports\ and attach a copy of the *.dmp files that are from the same time as the crash (feel free to make it crash again so it'll generate a new one you know is related). Thanks!

Thanks for letting us know Mike. I've reproduced this and passed it on to development.

Factory Reset will only apply to the current document, and if you don't use Save after it will not affect any newly created document. We're aware that there are a few usability issues with this that are logged with development, and that is one of them.

Please check your Leading settings in the Paragraph Panel, and also the Leading Override values in the Character Panel. Using Carlito my Leading is set to Default, which for the font is 12pt so shows as [12pt]. Changing the font size will change this automatically to match the font size used. Additionally the Leading Override in the Character Panel is also set to Auto and shows as (12pt) and will change automatically to match the font size used. The Leading value in the Paragraph is used to change the value everywhere, and the Override option allows you to tweak individual characters. Looking at both your values they're set manually to 12pt (as they're not encased in brackets) so the rest of the text will never move, as its applying the leading of 12pt that you have told it to.

I'm referring to document defaults, not what is set in the Text Styles. If you make a new document and the leading value is not shown in square brackets (i.e [12.9pt] ) then at somepoint you've changed your document defaults. I would suggest you set that value to be Default and then use Edit > Defaults > Save to ensure every new document from that point on will maintain a default leading value.

As Hangman has said this is not a bug - you need to ensure the Leading is set to an 'Default' value which will display the leading value currently used inside square brackets. This will always change based on the font size and uses the font's own metrics for setting the leading. I suspect you've changed you leading to a manual value and then saved that as a document default, so any new documents will use that value. I suggest you change this back to 'Default' and resave your document defaults.

Thanks Benfischer, I've reproduced this and will get it passed on to development.

Thanks for these Mike and sorry for the slightly late response. I've reproduced these and logging them to be looked at. I can reproduce this as well and will get this logged.

Thanks Mike! I've reproduced and logged this.

Hi Muhammed, Just wanted to let you know that this was an issue we had logged and was fixed in 2430 which is why it was now working. Thanks for letting us know

Hi mjw, Please see the post from Mark below on how to use these - you will need to specify the -b Beta argument when pointing to aflaunch.exe. Alternatively you can uninstall the MSIX Beta versions, and install the EXE ones and then you can point directly to the app's installed exe.

Thank you very much for those files (I shouldn't need the highlighted ones either thanks!) - unfortunately everything looks to be normal there and not out of the ordinary, so it certainly seems to me like it could be a font you have installed with Windows. Do you have many fonts installed to your copy of Windows or use a font manager at all? I think the best way to try and find out what potentially could be stopping it is by using Process Monitor to monitor the app's process on launch and then send us the log file that creates. To do this you would first need to download and run Procmon64.exe - this can be found on Microsoft's Process Monitor Page here: https://learn.microsoft.com/en-us/sysinternals/downloads/procmon After you download and run it will start to capture events (of which there are many) so you will want to set up a filter for the app you are using. In my case I created a Filter for the process name of 'publisher.exe', if you're using Designer this will be 'designer.exe' etc. When that filter is set up, just run the application and wait for it to crash in the way you've been seeing. Once it has done that you can disable the Capture using the Start/Stop Capture button to the right of the save icon. After that please save the log file using the 'Events displayed using current filter' option on the save dialog and the PML format. When that has saved could you upload that to us - unfortunately it is relatively large (mine was about 71mb), but hopefully it will be able to give us a little more information to go off. I've made a short video demonstrating those steps below. ProcMon.mp4