Sean P

Please try to include a video of the entire screen as we like to be able to see the whole picture (for example I cannot see what your Move Tool Auto Select settings are), however by what you've described and from what I can tell from the Layers Panel it sounds to me like this behaviour is as Designed. You have disabled 'Edit All Layers' - this means your selections will be restricted to objects on the same Layer as the current selection, so if you have a object inside that layer selected, you will only ever be able to select other children inside that Layer, which is likely making it appear as though the selection has broken. EditAllLayers.mp4

It is only once for the whole suite!

When the application gets in this state can you keep an eye open on the status bar and check to see if 'Mouse over an object to get measurements. Click an object to select it' remains visible' when you have no keys pressed down? If this is the case then I believe it happens occasionally after you release the Cmd key. Toggling the Cmd key should get the app back to a working state. Here is an older video demonstrating it - I have been able to reproduce it in 2.4.0, but it took many attempts to get it to happen. Screen Recording 2023-09-05 at 11.56.08.mov

Hi T.E. Thanks for letting us know - I believe the Delete option is mistakenly appearing after you use 'Update from Selection'. This has been logged with development.

Hi EkDor, Thanks for getting back to me! That's great news to hear!

Unfortunately, I'm not sure what is going on with the colour of your cells as your video doesn't show that colour applied to anything I would expect in and outside of the Table Editor. However, I can explain what I believe has happened regarding the !Table Body style - which may partially explain the oddities you could be seeing regarding the colour. When editing a table via the Table Editor, each Cell Format has a definable Text Style (in the bottom right of the dialog). When setting table style up this allows you to set a different format for the heading of a table (as an example). However you said you have deleted this style yourself - this means that the Table is trying to look for a format which doesn't exist, so the exclamation in front of the style is a warning that this doesn't exist. Now you could either add this style back if you want to have the ability to style a table differently to your body text. However, if you would prefer them to both use the same Text Style then you could modify the Table Format's cell formats to use a 'Body' style (or whichever style you have in your document). This means that each cell that uses that format will have that text applied. With all of that in mind its worth knowing that both Tables and Text Style formats can each be saved as Defaults, so any new documents also use those settings. In your case you may have deleted the 'Table Body' and then done 'Save Styles as Defaults' meaning that any new document will not have 'Table Body' so you would see that exclamation in any new document when creating a table. So you could modify your table format as above and then use 'Save Formats as Defaults' in the Table Formats Panel Preferences. This would ensure that any new document you create doesn't contain 'Table Formats' and that any new table will use whatever format you have set. I do wonder if the colouring might be coming from a Text Style or a different defaults format that was set, however as you've now done a Factory Reset, we can't look into your settings. Table Formatting can potentially become confusing, so if you haven't already I would highly suggest checking out the Help article! https://affinity.help/publisher2/English.lproj/pages/Tables/createCustomTables.html

Hi Ronny, My apologies I thought I had replied, but it seems I had not. Many thanks for doing that - I've added it to the original report which is which is with development, so I shall leave it with them!

Don't be silly - just glad to hear that nothing has gone catastrophically wrong!

Hi @joe_l What Chris said isn't strictly true and was a result of a slight misunderstanding. When the software is built it is built into two different variations; one is a Customer Beta, and the other is a full Retail Build (which is what gets released to the Affinity Store). Whilst the code is predominatly the same, there are a few changes in them when it comes to licensing (i.e no Customer Betas will ever offer trials, and always require a valid software licence to run), and lastly one of the major differences is where it stores its preferences and settings. For Windows a Customer Beta will store its settings in the following locations*: %UserProfile%\.affinity\Common\2.0 (Beta)\ - for files shared between apps (of the same build type i.e Beta) i.e Assets, Brushes, Styles, Store downloaded content etc %UserProfile%\.affinity\Designer\2.0 (Beta)\ - for App specific settings and preferences For a Retail build it will store the same settings in similar, but slightly different location* %UserProfile%\.affinity\Common\2.0\ - noting the lack of (Beta) in the pathname %UserProfile%\.affinity\Designer\2.0\ - noting the lack of (Beta) in the pathname For recent documents these are stored in a file called RecentFiles.xml which is stored inside (For the Designer Customer Beta): %UserProfile%\.affinity\Designer\2.0 (Beta)\settings\ This means that the 2.4.0 Beta will store Recents in a separate location to the 2.3.1 Retail downloaded from the Affinity Store. There is an option inside the Customer Beta to Copy Settings & Content from Release apps, which will copy over this data and the Recents are part of this, so you may have done that. I assume you haven't created any custom aliases within Windows to link the two locations? With that said can I confirm that you're saying that opening a document in the Retail app will then show up in the Beta Recents list inside the app? If that is the case could you attach a video (of your whole screen) demonstrating this behaviour please? Also if you could take a copy of the Log.txt files from the locations above (changing the app name for the one you're using) after you close each app and attach those that would also be helpful. Thanks, *These locations are given for the MSIX builds - For EXE users these paths are slightly different: %AppData%\Affinity\Common\2.0 (Beta)\ - For Beta Common %AppData%\Affinity\Designer\2.0 (Beta)\ - For Beta Designer %AppData%\Affinity\Common\2.0\ - For Retail Common %AppData%\Affinity\Designer\2.0 (Beta)\ - For Retail Designer

As GarryP has said this is By Design because you have the View Tool selected. Dragging an image in won't change your selected Tool, and as Photo's default tool is the View Tool it unfortunately makes it seem as though the image is 'missing'. As others have mentioned this isn't a beta issue and nor is it considered a bug, as the software is behaving as intended. If you don't like the default tool of Photo then please feel free to post your thoughts in the issue Return has linked to above.

Thats great to hear! Thanks for confirming!

Thanks - I'll pass this on to development to see if there is anything obvious inside the crash report.

Hi PeterB, I've been able to reproduce this using 2.4.0.2279 and can confirm that since then a change has been reverted that caused PDF Transparency issues on export, and can confirm that with this reverted change in, your PDF exports correctly, so this should be ok in the next build. Thanks for letting us know!

Thats great! I assume 2.3.1 is doing the same for you as well? I expect switching to OpenGL will likely make the issue go away for you? We do all have this logged with development, so just wanted to make sure what you're seeing is matching up with what I've found to be true. Thanks.

Hi Paul, A fix for this got submitted for inclusion in a build the other day, so providing the fix works, it should be included within the next build.

Hi Old Bruce, Thanks for letting us know. As Hangman has mentioned this is something we're aware of and have logged, and as you say only happens if you switch UI. Restarting the app will fix the button however.

Thanks for that - after looking into it I believe it is the font's kerning pairs that are causing the text spans to appear. For example Arial has a kerning pairs on the following Aw, Av, Ve and Vi - but not on Ar, An, Vj or Vm. If you place the caret between these two characters and check the Character Panel you will see a kerning value of something other than zero in brackets. The brackets mean the value is automatically set, with the value in the brackets. It is this that is causing the text spans to appear, so the behaviour does seem to be intentional to counter the changes a font is making to the spacing. Again enabling Longer Text Spans will stop this from happening. That said, it appears as though many SVG renderers automatically apply this spacing anyways, so the text spans that get added appear to be superfluous. I found this by manually setting the kerning myself to zero in the Character Panel to force the the text spans not to export (without using 'Longer Text Spans: On) and found that whilst this was happening, the kerning was still being applied, as noted by a copy of the (zero kerned) text converted to curves below. This can be seen in the attached 'Auto Kern' file. Open the attached afdesign In the blue rectangle the Ay pair as an Auto Kern value of -18.1‰ set (noted by the value in the brackets). This has then been converted to curves and coloured green (the AutoKernPos group) In the pink rectangle the Ay pair has an overridden kerning value of 0‰ set (the value is not in brackets, so it has been overridden from Auto). This has then been converted to curves and coloured green (the ZeroKernPos group) Now export this to SVG (for Export) ensuring Longer text spans are disabled Open the resulting SVG (also attached) in a browser (I used Chrome, but found Inkscape rendered it the same) Inside the SVG the Ay that has auto kern applied (in the blue box) now has the text span applied, and matches the same as in-app, because there is no green visible from the curve copy underneath it However now note that the Ay that has the overridden kerning value (in the pink box) has been exported out with the text spans, but they're still being applied, because the copy that was converted to curves underneath it in green is now visible. So in summary, it looks like the behaviour needs to be reversed. When Auto Kerning is applied, no text spans should be included, when any overridden kerning (even if its zero) is applied, then it should output with text spans. I will get this logged with development. Hopefully, this makes sense to you? Thanks for your perseverance! AutoKern.svg AutoKern.afdesign ArialKerningPairs.afpub

Thanks Ronny! Do you find the issues go away if you switch to OpenGL? And also can you reproduce the issues on 2.3.1 based on what screen the main window was on and what screen you launched the app on? Thanks

Hi Ronnie, Which renderer is your Retail 2.3.1 using and which is your Beta 2.4.0 using? I'm finding I can recreate this in both 2.3.0 and 2.4.0, but both have to be set to using the Metal Renderer. We have also found that the monitor the app is launched from and the location of the main window also affects how this is getting displayed. Could you attach some more information for us please? What is the model number of your LG screen? Can you attach screenshots from Settings > Display showing the settings for both your screens (and hover over the selected setting to show the resolution). If possible can you try the following please? Set to Renderer set to Metal: Have the main app screen positioned on the Macbook and then close the app to ensure its position is set, and then launch from a Finder window on the Macbook - Do artboard labels display correctly? Set to Renderer set to Metal: Have the main app screen positioned on the Macbook and then close the app to ensure its position is set, and then launch from a Finder on the LG screen - Do artboard labels display correctly? Set to Renderer set to Metal: Have the main app screen positioned on the LG screen and then close the app to ensure its position is set, and then launch from a Finder window on the Macbook - Do artboard labels display correctly? Set to Renderer set to Metal: Have the main app screen positioned on the LG screen and then close the app to ensure its position is set, and then launch from a Finder on the LG screen - Do artboard labels display correctly? Set to Renderer set to OpenGL: Have the main app screen positioned on the Macbook and then close the app to ensure its position is set, and then launch from a Finder window on the Macbook - Do artboard labels display correctly? Set to Renderer set to OpenGL: Have the main app screen positioned on the Macbook and then close the app to ensure its position is set, and then launch from a Finder on the LG screen - Do artboard labels display correctly? Set to Renderer set to OpenGL: Have the main app screen positioned on the LG screen and then close the app to ensure its position is set, and then launch from a Finder window on the Macbook - Do artboard labels display correctly? Set to Renderer set to OpenGL: Have the main app screen positioned on the LG screen and then close the app to ensure its position is set, and then launch from a Finder on the LG screen - Do artboard labels display correctly? If you do find one of these scenarios are affected, would you be able to try the same scenario using 2.3.1, please? We expect it to also be the same. I'm wondering if one being set to OpenGL and the other being set to Metal is making this appear to be a regression. For what it is worth I found the following with my iMac: Hardware: iMac Intel Retina 5K 2020 Sonoma 14.0 - Set to 'Default' (2560x1440), also Main Screen LG Screen 27UK670 - Set to More Space (3840x2160), also Extended Renderer: OpenGL - see iMac_OpenGL.mov Main Window positioned on iMac If App is launched from Finder on Macbook Air screen: ✅ Appears fine If App is launched from Finder on LG screen: ✅ Appears fine Main Window positioned on LG Screen If App is launched from Finder on Macbook Air screen: ✅ Appears fine If App is launched from Finder on LG screen: ✅Appears fine Renderer: Metal - see iMac_Metal.mov Main Window positioned on iMac If App is launched from Finder on Macbook Air screen: ✅ Appears fine If App is launched from Finder on LG screen: ❌ Artboard Content is cut off by three-quarters Main Window positioned on LG Screen If App is launched from Finder on Macbook Air screen: ❌ Artboard labels are messed up similar to those shown above. See screenshots attached showing both 2.4.0 (left) and 2.3.0 (right) If App is launched from Finder on LG screen: ✅ Appears fine

Hi Pyanepsion, I don't think the coloured spaces are causing the text spans at all. It is the multiple highlights on the spaces that are causing it. As I understand it SVG doesn't allow for highlighted text, so to make it work we have to draw a rectangle for every space using a highlighted colour. This is why you have that massive block of rectangles. So to ensure that wasn't causing the increased text spans I did an export with all of them set to no fill. SVG export with coloured spaces (attached Highlight Spaces.svg): <g transform="matrix(1,0,0,2.14286,0,0)"> <text x="14px" y="39.665px" style="font-family:'ArialMT', 'Arial', sans-serif;font-size:8px;fill:rgb(16,24,32);">Nullam hendrerit viverra dolor<tspan x="118.488px 120.711px 122.934px 127.828px 132.277px " y="39.665px 39.665px 39.665px 39.665px 39.665px ">. Ves</tspan>tibulum fringilla, lectus id viverra malesuada, enim</text> <g transform="matrix(8,0,0,8,201.648,50.0652)"> </g> <text x="14px" y="50.065px" style="font-family:'ArialMT', 'Arial', sans-serif;font-size:8px;fill:rgb(16,24,32);">mi adipiscing ligula, et bibendum lacus lectus id sem.</text> </g> SVG export without coloured spaces (attached Non highlight spaces.svg) <g> <text x="14px" y="39.665px" style="font-family:'ArialMT', 'Arial', sans-serif;font-size:8px;fill:rgb(16,24,32);">Nullam hendrerit viverra dolor<tspan x="118.488px 120.711px 122.934px 127.828px 132.277px " y="39.665px 39.665px 39.665px 39.665px 39.665px ">. Ves</tspan>tibulum fringilla, lectus id viverra malesuada, enim</text> <g transform="matrix(8,0,0,8,201.648,50.0652)"> </g> <text x="14px" y="50.065px" style="font-family:'ArialMT', 'Arial', sans-serif;font-size:8px;fill:rgb(16,24,32);">mi adipiscing ligula, et bibendum lacus lectus id sem.</text> </g> Notice how the spans are in exactly the same place? The spans are used to try to ensure objects are placed to match what you see in Affinity as closely as possible. Obviously this isn't always what people want, which is why we added the 'Longer Text Spans' option inside the Export Settings. This should do exactly what you want and remove those two text spans. I took the above two examples and exported them with 'Longer Text Spans' enabled and get this: SVG export with coloured spaces using longer text spans (Highlight Longer Text Spans.svg) <g transform="matrix(1,0,0,2.14286,0,0)"> <text x="14px" y="39.665px" style="font-family:'ArialMT', 'Arial', sans-serif;font-size:8px;fill:rgb(16,24,32);">Nullam hendrerit viverra <g transform="matrix(8,0,0,8,201.648,50.0652)"> </g> <text x="14px" y="50.065px" style="font-family:'ArialMT', 'Arial', sans-serif;font-size:8px;fill:rgb(16,24,32);">mi adipiscing ligula, et </g> SVG export without coloured spaces using longer text spans (Non Highlight spaces Longer Text Spans.svg) <g> <text x="14px" y="39.665px" style="font-family:'ArialMT', 'Arial', sans-serif;font-size:8px;fill:rgb(16,24,32);">Nullam hendrerit viverra <g transform="matrix(8,0,0,8,201.648,50.0652)"> </g> <text x="14px" y="50.065px" style="font-family:'ArialMT', 'Arial', sans-serif;font-size:8px;fill:rgb(16,24,32);">mi adipiscing ligula, et </g> So to summarize, I don't think there is an issue here, but it does sound like 'Longer Text Spans' will be what you need. You can also look at further minimizing the file size by using 'Use Hex Colours', 'Flatten Transforms' and also disabling 'Use Line Breaks'. Highlight Spaces.svgNon Highlight spaces Longer Text Spans.svgHighlight Longer Text Spans.svgNon highlight spaces.svg

Ahh so I did! Thanks for picking that up Walt! It was the feature thread below that I intended. I have also created this file which should list the expected layer inside AutoCAD the coloured rectangles should appear in based on what the chosen export setting was. DWGLayerTest2.afdesign

Hi EkDor, Layers should be exporting out with Layer Names, though you will need to ensure your export settings are suitable. See this post for a small description on what the 'Layers' option does and how to it maps from Affinity Layers to AutoCAD. I will double-check the behaviour regarding groups, but from what I recall there are intentional reasons for them not being exported. Do you mind attaching a copy of the document you're trying to export, the settings used on the Export dialog and the resulting DWG/DXF file.

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

Hi Pipouille, Thank you very much for your suggestion, unfortunately this is currently out of the scope for 2.4, however I will pass your suggestion onto development.

Thanks for that! Unfortunately I've still been unable to reproduce it. I've even replicated your menu and dock settings to no avail. I've tried with both a mouse and a trackpad (which is the same model as yours). I will keep my eyes open! Screen Recording 2024-01-30 at 10.49.49.mov