Richard Mlynarik

Affinity Designer 1.10.5 incorrectly assigns a stroke width of "0" to all of the lines in the attached file, making the drawing invisible. g.svg

SVG "symbol" elements with non-zero "x" or "y" attributes are not placed correctly by Affinity Designer 1.10.5 Compare screen shots of a web browser's correct rendering (Firefox, same correct results with Safari) versus screenshot of imported image in Designer. The rendered symbol should be placed with top-left at 40,49.1 not 50,50 It is also just weird that Designer has decided the make a "layer" out of the symbol. Why not a simple "group"? (I keep finding basic basic SVG bugs ever single time I try anything. And those reported are never fixed. It's very frustrating trying to do anything at all with SVGs.) <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100"> <defs> <symbol id="xxx" width="20.0" height="8.9" x="-10.0" y="-1.9"> <rect x="0" y="0" width="20.0" height="1.9" fill="red"/> <rect x="0" y="1.9" width="20.0" height="7.0" fill="pink"/> </symbol> </defs> <rect x="50" y="0" width="1" height="100" fill="black"/> <rect x="0" y="50" width="100" height="1" fill="black"/> <use href="#xxx" transform="translate(50,50)"/> </svg> s.svg

Cool cool cool. Hey we could make completely wrong analogies in terms of homotopy equivalence instead of parking, but they'd still be wrong. Here's the deal. In EVERY OTHER PROGRAM IN THE UNIVERSE that has an "undo" feature, when you've undone every single change that you made, you now have something to which no changes have been made. If there's nothing left to undo, the document is unchanged, and I don't need to worry about saving modifications. It really is that simple. Man, what a waste of time.

Well, I don't know. Pretty much every other program ever has this. But I guess they're all just wrong. Thanks for sharing! It's great to have a "bug reporting" system that is really just a fanboy forum.

If I modify a drawing and then undo "all the way", the tab title bar in Affinity Designer still shows "[Modified]". It shouldn't! I've undone all my changes. Feature request: Why isn't there "Revert To ..." (or just plain old-fashioned "Revert" under the "File" menu? Feature appreciation: It's great that my old 10.13 version of MacOS on a old but still perfectly adequately fast Macbook is still actively supported by Designer and that it works very well. Thanks!

Hi, I wasn't suggesting that Designer support non-equal scaling of strokes. I don't even want that myself! What I am suggesting is that the fall-back *choice* Designer makes in how to interpret this unsupported scaling isn't the same as other programs (Firefox, Safari=Webkit, Illustrator CS4 (the only version I can still run sometimes) do, which is to choose to scale the stroke dash pattern by the *minimum* of transformation's scale-x, scale-y instead of the maximium. So in a "transform=scale(30,1)" choose not to scale the stroke pattern (and stroke width, etc) at all, instead of scaling by a factor of 30. Yes, this is an arbitrary choice, but it's one Designer seems to make differently from some other SVG-consuming programs, and I can argue that the opposite way of doing things is slightly superior. (It would certainly simplify my life to not have to patch this stuff up by hand.)

I am generating SVG files with very large viewBox min-x coordinates eg <svg xmlns="http://www.w3.org/2000/svg" viewBox="36900 -60 7800 1590" width="7800" height="1590"> If I import such an SVG into Affinity Designer (1.9.3) the combination of the viewBox and width/height attributes causes the artwork to lie outside the 7800x1590 pixel document with large negative Y coordinates. If I remove the "width" and "height" attributes (which specify the same size as those specified by the "viewBox" attribute) the file is imported in the way I expect. Note that I don't know what the "correct" behaviour is -- just trying to reading the SVG specifications causes anger and confusion! -- but both Firefox and Safari web browsers don't seem to be upset by this combination of attributes, and it would be nice if Designer did the same thing. svg-transform-test-case-3.svg svg-transform-test-case-4.svg

A non-uniform SVG scale transformation -- eg "scale(1,-30)" -- results in dash pattern being scaled by a factor of 30, eg <g transform="scale(1,-30)"> <g style="stroke-dasharray: 5 3 1 3;"> <path d="..."/> </g> </g> will render a path with very large dashes, in effect scaling the path's dash-array by a factor of 30, not by 1. It is entirely unclear what the "correct" behaviour is, but other programs (including the SVG renders in browsers I've tried Firefox and Safari) instead appear to scale the dashes by the minimum of the differing X and Y scales, or "1" in this case. I suggest this may be the less-bad decision, for compatibility/consistency reasons. SVG is simply a nightmare of misdesign and confusion, isn't it? svg-transform-test-case-2.svg

SVG attribute transform="translate (0 -1.9)" is ignored by Affinity Designer, while transform="translate(0 -1.9)" is parsed correctly. Note the single space character between "translate" and the open parenthesis in the buggy case. https://www.w3.org/TR/SVG11/coords.html#TransformAttribute is explicit that whitespace is allowed, but even if it were not, a permissive parser would allow it. The fact that no error or warning is issued and that the attribute is silently ignored makes this class of bug very difficult to isolate svg-transform-test-case.svg