WavyDavy

It might only happen if aligning the stroke to the inside, but it doesn't consistently cause a problem. In the last example that I posted, all I did was flip the same drawing horizontally, and the the flipped drawing exhibited the problem whereas the un-flipped drawing didn't. The SVG files created for the "working" and "non-working" versions look the same structurally. They both replace the outline with a path statement. I don't know why one path statement resizes properly while the other one doesn't.

Here's a more compelling example. In this test, I drew a refrigerator and then copied and flipped the refrigerator. The flipped version does not draw properly, whereas the non-flipped version does. The original design file includes both refrigerators, flipped and unflipped. I've also attached the exported .svg files of each version of the refrigerator along with an svg design files that uses and resizes the svg files. fridge_right_test.svg fridge_left_test.svg appliance_test.afdesign Fridge_Test_export.svg

I apologize. I forgot to include the original design file. I've attached it here. office_chair.afdesign

Just wondering if you've had a chance to look into this. This problem is still happening for me for several different drawings. Thanks.

Just wondering if you've had a chance to look into this. This problem is still happening for me for several different drawings. Thanks.

OK, I've stumbled across this problem again. It's very strange. As I said before, I'm surrounding a piece of svg code with an svg transform in order to shrink it down. The outlines that Affinity Designer creates for my shapes seem to work fine for all but one. In all cases, I specified in Affinity to align the border to the inside, and to scale with objects. I've attached 2 files. The office.svg file contains just an office chair. When you open up this unscaled version, everything looks fine. The other file, Test_export.svg takes the office chair svg code and surrounds it with a transform. Everything shrinks down fine with the exception of the back of the chair, which is all black. I didn't do anything different for the back of the chair vs. the other shapes that make up the chair. You can find the office.svg code in the Text_export.svg file by searching for "office". Test_export.svg office.svg

Selecting the scale with object box seems to have fixed the problem, but I can't be 100% sure. In the past, it seems like sometimes the scaling worked fine and sometimes it didn't, so there's still something going on that I don't quite understand. I'm transforming the .svg code by using the code as a library element in a different program, and surrounded it with a group tag with a transform matrix. I'll post if I find additional information to understand when the transformation does or doesn't work. As I mentioned, the only part that wasn't always transforming properly for me was the complex outline path created by Designer. Thanks again for your help.

I think I understand now, thanks. Part of my confusion was that I was thinking that the stroke curve created was a solid shape sitting behind the fill layer, rather than a complex curve that creates the outline shape. I'm trying to use the resulting .svg as a library element for another program, but when I apply a transform to the .svg data created by Designer, the complex outline curve created by Designer doesn't scale properly, resulting in the fill area being covered up. My work-around for now is to not use strokes in Affinity, and create 2 shapes, with the outline shape being slightly larger, and locate the fill shape above the outline shape. I don't quite understand why the transform doesn't work properly on the outline shape. If Designer instead did something similar to what I'm doing manually, I wouldn't have this type of issue. The complex outline shape seems like overkill, but I'm sure you have your reasons for doing it this way. Thanks for your help.

I'm using version 1.9.2.1035 of Designer. At least in this version, when I open the .svg, the gray inner fill is the second-to-last item in the layer, and the surrounding black is the third-to-last item. I would expect the order to be reversed such that the surrounding black is behind the gray fill. However, when you actually click on the gray curve in the layers panel, the black curve is the one that gets selected in the drawing, and vice-versa. Because these are swapped, Designer actually draws it properly, but the .svg is not correct.

When exporting shapes to .svg with strokes aligned to the inside of the shape, Affinity breaks up the shape into 2 filled paths, one shape to represent the black stroke outline, and one shape to represent the gray fill. When I open up the generated .svg in Affinity, the shapes appear to be in the wrong order looking in the layers panel. I would expect the fill to come before the "stroke" shape, but it doesn't. However, strangely enough, Affinity will mark the outline shape as being selected when I select the fill shape in the layers panel, and will mark the fill shape as being selected when I select the outline shape in the layers panel. Therefore, Affinity thinks that the 2 are in a reversed order than as seen in the layers panel, and therefore displays the image correctly. However, when I then take the .svg code for the image created, and include it in a larger .svg file with other elements, the error becomes apparent. As expected, the shape representing the outline/stroke of the shape is on top of the fill, and therefore the whole shape is black. For export, I'm using the svg (for export) setting along with flatten transforms, and I'm only exporting the selection. The incorrect ordering occurs on the "back" of the chair on the drawing. I'm attaching 2 files, the .afdesign source code, and the generated .svg code. AffinityTest.afdesign AffinityTest.svg

Well, I went back to try to recreate some of the original behavior, and it's not happening at the moment. I must have been in a strange state. Now the tool is doing what I wanted, which is that when I do the export and tell it to rasterize nothing, then no images are included in the SVG. If it comes back, I'll update the post.

Stokerg, thanks for your reply. So, it sounds like there's no way to do what I'm trying to do, correct? I can put together an example for you of the zoom level behavior, but what about the behavior that I noticed in the last paragraph of my post where I can also prevent the image data from being exported by selecting a filled object, going to the export menu, selecting the export only selected item with background option, and then selecting the export only item selected without background option? This will prevent the image from being exported. If I just go directly to the export item selected without background option, then the image is exported.

I was wondering if there's a way to do an SVG export but exclude any images from the export. I basically want an SVG that I can work with which has all of the outline information separately, and save the graphics portion of the drawing as a separate bitmap. I thought that selecting the "Nothing" option for the Rasterize menu option under the export menu might work, but it did not. I did some additional debug, and I found that by changing the zoom level of the bitmap patterns that I'm using, I can make the tool either include the image in the SVG export or exclude the image when the "Nothing" option is selected in the Rasterize menu option. Sounds like a bug?? Yet some additional debug data. If I select all items to export, I can then go into the export menu and select for the Area "Selection with background". If I then subsequently pick '"Selection without background", then the tool will not export the images. Can someone explain if my interpretation of how the "Nothing" option for Rasterize is correct? If so, it sounds like it's not working correctly for SVG export.