LCamachoDesign

There's so many things wrong it's just easier to see the attached video, screenshot, and sample file. I've noticed that: Hyphenation value does not display correctly Numeric values seem to be randomly (?) displayed with other unrelated values or even units I've seen point values show up as completely different point values, like the font size I've seen units display different altogether, like paragraph stops in mm showing in px The actual values that appear in the design are correct though. For example, setting a font to 12 pt in the Text Style Editor will result on a text with 12 pt size, even if the Style settings text in the dialog box says 37.5 pt. Also happens in Designer, and likely in Photo too. Thanks! Gravação 2024-07-11 153625.mp4 Publisher Sample 2.afpub

When you drag select text going from left to right, you should always be able to also select the carrier return special character. This is for a number of reasons related to text layout. However, this function breaks in Publisher and Designer (and likely in Photo too) if your paragraph starts with a number, and the Figure Style of the said number is set to Old Style. Steps to reproduce: Create a text frame object Set the font to one that supports Old Style numbers such as Arial Write a few paragraphs that start with numbers Set the Figure Style for all paragraphs to Old Style Try to select the whole paragraph including the return special caracter See that you cannot, at least not without selecting the line below Set the Figure Style to Default Try to select the paragraph again See that selection works as expected See attached video and samples files for an example of what's happening. Thanks! Gravação 2024-07-11 151638.mp4 Designer Sample.afdesign Publisher Sample.afpub

If an object has rounded corners that only round the outside angle of the shape, but not the inside, upon expanding the stroke of the said object the outside nodes will be sharp instead of smooth. This is actually hard to explain in words, so I've included a video showing the issue and a sample file for you to try. In any case, here's my attempt to provide a steps to recreate: Create a shape, such as a rectangle Give it a rather thick stroke such as 15pt or more Set the corners to rounded Input a rather low corner value such as 3% for example Expand the stroke of the object Notice the jagged outside edges Undo back to step 4 Try again with corner value 0 and repeat See the stroke expands correctly Undo back to step 4 Try again with a large corner value such as 30% See the stroke also expands correctly This bug is not limited to shape objects, it also happens with simple curves, provided they have a low value rounded corners. This bug does not seem to happen with any other corner type. Also, this bug can be inconsistent, I've seen shapes that follow the "rounded outside sharp inside" rule expand correctly. Thanks! Gravação 2024-05-24 120849.mp4 Sample File.afdesign

Yeah, this is pretty much my take. And we've seen mergers and acquisition on the design/software enough times to know this will likely end badly. I mean, just look at Gravit Designer -> Corel Vector after the acquisition, or even more recently Vectornator -> Linearity Curve after VC poured in. This is why we can't have nice things.

Wait, what? There are key objects in Affinity? When did this happen? I just tested it in 2.3 and it works! I had no idea. Is this even in the documentation? Well, I guess finding out there's key objects is the best feature announcement! 😂😂

Placing an image and trying to set its scale on the toolbar is basically impossible. Steps to reproduce: Create a new document, I've used a simple press ready A4, 300 DPI Drag and drop an image into the newly created document, I've used this from Unsplash Select the image and use the toolbar to set a percentage scale, such as 50% Notice the image is scaled, but to a completely different value Keep trying to scale the image, the values will increasingly become completely erratic (!!!) Notice that trying to set a specific DPI value, such as 300 or 600, works as expected See the attached video below for a visual guide: Erratic Percentage.mp4 Thanks!

Right clicking a swatch created on any document palette created after the first one will no longer have the Edit, Rename and Delete menu entries active. See the image below: Steps to reproduce: Create a new document Create a new document palette, name it 1 for easy reference Create a new global swatch, make it spot to enable the Rename Spot menu too Right click the newly created swatch See that you can edit, rename and delete this swatch Create a new document palette, name it 2 for easy reference Create a new spot global swatch Right click this new swatch, notice the disabled menu items Creating further palettes and swatches Notice the problem continues Video guide below: Swtaches menu.mp4 Thanks!

Small UI bug when the Swatches Panel view option is "Show as list" and a swatch is set to overprint. This is how the documentation shows how the swatches should look: This is how the show in "normal" (?) mode, and it's correct: And finally, this is how the look like in "Shows as list" mode, we can clearly see the grey circles are not being correctly cropped and overlap the swatches above: Thanks!

Just to let you know this is still happening, and only in Affinity apps. No other apps have this problem, so I'm not changing system settings just for this. Can you please look up what's wrong with your icons? More importantly, whatever happened to the mini icon over the file explorer thumbnails? Attached is an example of how Blender does it. Affinity used to do this as well, but somewhere along the way this was lost, and it never came back. So now, when we export a PNG file next to the source file, both thumbnails look exactly the same. The only way to tell them apart is by hovering the file and waiting for Explorer to say what file type it is. Thanks!

I see. But in that case, it's still a problem in Affinity, and not with my system. You should be using the value marked in green, "decimal separator", since that's literally what it is. Instead you seem to be using the "list separator" value marked in red, which is the incorrect value to use (and also; is the correct value for a list separator, so I'm not changing it, it would break stuff elsewhere). Thanks!

I've posted about this before, but Serif could simply use SAM-HQ and be done with it: GitHub - SysCV/sam-hq: Segment Anything in High Quality

That just speaks to exactly what I was saying. The field changes too fast for wasting any time doing custom solutions. When I posted, the only thing you could run locally was Stable Diffusion 1.5. While that works, the quality was pretty substandard, but you only needed a GPU with 4Gb VRAM. Yes, you could use custom checkpoints and LoRAs for waifus, but... that's not the scope here. Jump forward to today, and now you can run SDXL locally. And the quality is much higher than 1.5, vanilla SDXL is ballpark MidJourney 4 I'd say. With ControlNet and LoRA / LyCORIS I'd say you get MidJourney 5 level of generation. But you also no longer can run with 4Gb VRAM, you need at minimum 8Gb, with 12Gb being the recommended value. Basically, you need a 3070 or 4070 and up. Yes, you can use quantization and other fiddly trickery to run below that. I can run SDXL locally on my M1 iPad Pro, but you're looking at 5 minutes per image, it's just not realistically usable. But like you said, it doesn't actually change my initial point, it's still better to have a plugin to connect to these generators. Again, looking at back to when I first posted, Automatic1111 was the way to run SD locally. Fast forward to now, and ComfyUI is the way to do it. Even when A1111 tries to catch up, with the 1.6 release a few days ago, it still can't catch Comfy, it doesn't have support for Control LoRA, and that's a massive downside IMHO. If Serif were, back then, to try porting A1111 into the Affinity suite, that time would've been wasted, they'd need to scrap everything and start again with ComfyUI to be competitive. So yeah, have a plugin system, and let others do that job. This is not speculation either. Just look at Krita, people spent time doing A1111 plugins for it last year... fast forward to today, and both top plugins have gone belly up. The development is now on the ComfyUI plugin hosted at CivitAI.

Bumping this to let you know it's still happening in 2.1.1 and literally all other document icons from all other apps I have installed do not have this problem. Also, none of the options you listed on your workaround @Callum would work as they simply do not exist anymore. These were for Windows 10, and I'm on Windows 11 (and was on 11 too at the time of my OP) where they no longer exist. Thanks!

Steps to reproduce: Create a new document Draw any vector shape Attribute a fill colour to the shape (for easier bug visualisation) Attribute a stroke colour to the shape Set the stroke width to a large value (for easier bug visualisation) Set the stroke colour to none, but leave the stroke width unchanged Notice the object is only showing the fill colour as expected Use the command Layer > Expand Stroke Expected result is for nothing to happen, as the object has no visible stroke. Instead an empty shape in the form of the invisible stroke is created. See attached video for a visual guide to this bug. I can see the logic of why this is happening, the stroke is still "there", it just has the colour of none. But that's not what a user would be expecting when using this command. It particularly aggravating if you have hundreds of objects with tiny stroke widths (the 0.2pt default), and then you expand everything at one to "bake" the design for print production. And do printers hate invisible objects with a passion, it can really mess their low memory equipment. You can't even use the Select Same command to catch all these objects because of this other issue I reported: Suggested remediations: Make the Expand Stroke command ignore any strokes with the colour of "none" Force the object's stroke style to "No Line Style" when it has its colour is set to "none" Either remediation would fix the problem, but implementing both would probably be the ideal as that's what I'd expect the app behaviour to be anyway. EDIT: Additionally, setting an object stroke style to "No Line Style" should force the stroke colour to be none. Otherwise you end up with the situation you select a shape apparently without a stroke, then use the Select Same > Stroke Colour and... nothing happens. The object you selected happened to have a orange stroke set to 0pt width. You can still try to use the Select Same > Stroke Weight > Equal to try and get around this, but it sure is a lot of workarounds to workarounds. Also, why is it Select Same > Stroke Weight if the Stroke panel refers to this object property as Width? Temporary workaround: Select one object with the stroke colour of none Use the command Select > Select Same > Stroke Colour Open the Stroke panel and set the stroke style to "No Line Style" Expand Stroke should now be safe to use (maybe, triple check just in case, you don't want to rouse the anger of a print plant operator) Thanks! Gravação 2023-07-20 144004.mp4

That's a good workaround. It worked. It would still be better to have this fixed in a future build. Thanks!