Brian M

@Sean P Thank you. Is the issue of not being able to export with real units on the radar as well? I was going to file a separate report about that, but haven't done so yet.

Here's a simple SVG: <svg width="4in" height="4in" viewBox="0 0 384 384" xmlns="http://www.w3.org/2000/svg"> <circle cx="192" cy="192" r="196" /> </svg> It's a 4-inch circle, at 96 DPI. The DPI can easily be inferred from the svg tag. Opening the file in Affinity produces questionable and frustrating results: The document gets changed from inches to pixels and transparently rescaled to 72 DPI, discarding any information about the original size and DPI. If you then re-export at 96 (which needs to be the DPI for some applications) it will now be 3 inches. (And if even if you change the document units back to inches, that information will be lost when you export it, but that's a separate issue). This is somewhere between frustrating and infuriating for people who need their designs to have real-world dimensions. I create and sell designs for laser cutters, and I already have to fix my SVGs after exporting from Affinity to have fixed dimensions in order to get them to work with all laser software. But if someone wants to open my design in Affinity and make an adjustment, then re-export, their design is going to shrink by 75%. My request is that my default, SVGs that are sized in inches or millimeters retain both their original document units and pixel dimensions (and therefore DPI). To me, any other behavior is a bug. Along with the inability to export in inch/millimeter units, this behavior causes endless headaches for laser users and designers.

The example was reduced for simplicity, but the original curve is a twin dragon curve, and was generated programmatically and is accurate. It was done a while ago so I can't remember all the details, but what you are seeing is the result of processing done on the curve afterward in Affinity. I likely did a stroke and offset it to create a curve with some width that I could work with and turn into a solid. Whatever it is, the zero-length handles are the result of some operation within Affinity. I'll keep my eyes open for it to happen again, and hopefully can figure out which one.

Turns out they are zero-length. This is the path data. <path d="M46.694,15.778C46.694,15.778 46.694,0 46.694,0C46.694,0 31.129,0 31.129,0L31.129,15.565L15.778,15.565L15.778,0L0,0L0,15.778L15.565,15.778C15.565,15.778 15.565,31.129 15.565,31.129C15.565,31.129 0,31.129 0,31.129L0,46.907L15.565,46.907C15.565,46.907 15.565,62.472 15.565,62.472L31.343,62.472L31.343,46.694L15.778,46.694L15.778,31.343L31.343,31.343L31.343,15.778L46.694,15.778Z"/> Probably the result of a zero-width offset operation or something. When the exported svg is re-imported, the unnecessary control points get removed.

You're right, thank you! No idea how they got there – some of them are invisible even at max zoom level – but that fixes the problem.

I'm seeing an odd bug with the corner tool where some nodes are ignored by it, even when all are selected by it. I have reduced it to a simple example and attached the file. Notice how there are five sharp corners. There are no extra nodes in the shape. I tried closing and reopening as suggested in https://forum.affinity.serif.com/index.php?/topic/123720-weird-thinks-happens-while-using-corner-tool/, but that didn't help. If I export to SVG, then open the SVG in Designer, it works fine. corner-bug.afdesign

I agree, it's more useful to select all within an artboard than all objects across all artboards. For keyboard shortcuts, maybe the first ctrl/cmd+A could select all within the artboard, and the second could select all objects. I also often find myself wanting to select all children within a group or layer. If that were supported separately, it could also be used to select all within an artboard.

For those of us who are very productivity-focused, keyboard shortcuts are essential. I'd like to request adding support for assigning any menu command to a keyboard shortcut. I've run into this a few times, but the commands that made me want to put in the feature request this time are the compound boolean commands. I'm aware that you can alt+click the buttons, but to assign them a keyboard shortcut would be even better.

I've seen several issues with changes within a symbol not propagating to other instances of the symbol. I'm not sure if it is because of multiple bugs, or they are just different manifestations of the same bug. But here's what I'm seeing specifically right now: I have a compound shape within a symbol. When I change the operation, the change is not propagated to the other instance(s), even though other changes are. I've attached a screen recording to demonstrate. symbol-compound-bug.mov

Happy belated 6th birthday to this feature request!!! 🥳🥳🥳 As much as I love AD, missing features like this make me question the value of continuing to invest my time in this product when other projects like Vector Styler (which I learned about in this thread) have been developed FROM SCRATCH in less time than it takes the Affinity team to add a highly popular requested feature and had tons of other features that AD doesn't have. I really do want to make AD my only vector design software, but until it has tracing, warp and mesh tools, calligraphy brushes, and scripting, I will be reluctantly using a mishmash of other tools to fill in the gaps, and sooner or later probably switch to one that can suit all of my needs.

Putting in another vote for supporting calligraphic brushes. Really, all we need is non-rotating brushes. I really hope it doesn't take another 4.5 years to implement it.

I want to add one more thing: I think there also needs to be a way to bail in the middle of an operation that's taking way too long. I just started an XOR that I don't think is going to finish before the app crashes, and there's no way out of it. It would be really nice to be able to reconsider and try again on a smaller subset of curves without having to deal with the crash and recovery process.

I was creating a relatively simple shape where I divided some intersecting lines and circles, divided them, deleted the unwanted segments, and then tried to add them back together. This sent the memory spiraling upward until the OS had to intervene (I had switched apps while waiting) and tell me to shut something down, and at that point Designer was consuming 50GB. I have already learned that I have to be careful adding together too many objects at once, but this is a pretty unsatisfactory experience. Both the amount of memory consumed, and the lack of safeguards inside the application to warn when is taking forever or using an unhealthy amount of resources. I think there must be some room for optimizing the add operation algorithm as well.