tudor

For printing/outputting a physical object, two important properties are the physical dimensions of the finished product and the resolution of the machine outputting it. That's why you should always use physical units. Pixels are for screen work. The concept of "unsharp lines" comes from the people doing pixel-perfect work for screens. It is irrelevant for printing or laser cutting because your machine does not output pixels on a screen. You're just wasting time converting everything to pixels. Your test file opened on my computer as an A4 print layout set up in millimeters. Even your laser software tried to tell you that you should always use physical units! 😁 Pixels are for screen, stop obsessing with pixel-perfection if you don't do screen work. I'm sorry if I offended you in any way, that wasn't my intention. But you need to learn the difference between screen and print before blaming the software for bugs.

No, it's not a bug, is a result of rounding errors when converting physical units into pixels. It's simple math and those errors cannot be avoided. Here's how that works: First and foremost, you work with physical units of measurement, because you're creating physical objects. The SVG however, is being exported using pixels, so there will be lots of conversions between mm and px. Looking at your original test file, I saw a bunch of bitmaps, each being 40.208 x 19.202mm at 1000 dpi 1000 dpi converts to 39.370079 pixel/millimeter Therefore the size of one your bitmaps when converted to pixels is 1582.992136432 x 755.984256958. The position of each object is also converted into pixels, so for example a y position of 38.405 mm equals 1512.007883995 pixels. Each of these fractional pixel measurements are rounded to the nearest integer values for the SVG export. Rounding the (x,y) positions of the bitmaps embedded in the SVG, while also rounding their WxH dimensions, means that the software is actually resampling them during export. Finally, if you open the SVG file in a text editor you'll see that size of the bitmaps was rounded to 1585x758 pixels. Now, what was your original complaint? That each bitmap had 1px added around the edges? I'm hoping that now you understand why that happened and why it is unavoidable. But, should you really be worried about that? Let's do the math: at 1000 dpi, 1 pixel = 0.0253999 mm. If that precision level is unacceptable to you, then by all means, look for another software package that allows for more precision when exporting to SVG. CorelDraw, for example, has a drawing precision option for SVG exports that goes up to 1:100000 units. I've no idea if that is helpful or not, but it's an option. (CorelDraw will also export SVGs in mm or inches, if that was the measurement unit of the original artwork). Then why do you check for errors in your artwork using PIXELS as your measurement units? Are pixels a physical unit of measurement to you? You're producing real-life objects, not doing pixel-perfect stuff. Because SVGs have many other uses besides laser cutting and sometimes they need NOT to be flattened. Read this:

All "weird" things described here in this topic are caused by a misunderstanding about how the SVG file format works in relation to the units of measurement and the resolution of the embedded bitmaps. You use bitmaps, millimeters (it's an A4 layout for print), and a weird dpi value (1000? why?) and then export everything to a file format (SVG) where everything is converted to pixels. The result is a lot of rounding errors. However, that SVG will be sent to your laser cutter, where a 1 px SVG rounding error on a bitmap converts to a fraction of a mm, that most likely won't even be visible. I'd say don't worry about it.

This is due to rounding errors. To avoid this, when exporting the SVG, enable the "Flatten transforms" option (you'll find it in the Advanced section of the Export window).

This is a bug from V1 that hasn't been fixed yet. I've just posted it again in the V2 bugs forum. You should be able to choose the RGB color space when exporting as PDF/X-3, but on some computers this is unavailable.

This is an old bug from v1 (see the thread below). On some systems (mostly macOS/Apple Silicon, but also some Windows 10 computers), when exporting as PDF/X-3:2003, the RGB color space option is missing. This affects anyone who has to produce flattened PDFs (no transparencies) without converting to the CMYK color space. Any updates on this issue?

MacOS or Windows?

This is interesting: "The stroking operation on paths—mandated and specified by all the listed standards above—lacks a mathematically grounded theory to define what stroking means." Maybe that's why all apps work with the basic inside/outside convention. It's a straightforward concept that's easier to implement if there is no precise math theory for stroking the paths.

This document describing a method for "stroking Bezier paths", seems to confirm that the math involved in this seemingly basic operation is quite complex: https://arxiv.org/pdf/2007.00308.pdf

I'm not a software developer, so I don't know. As I said, it was a guess based on the fact that nobody (except the VectorStyler developer) figured out (or care about) how to implement this feature. There must be a reason for that, and it most likely has to do with the complexity of the math involved. Keep in mind that a vector drawing tool for graphic design does more than just drawing paths. It has to calculate and render everything from simple paths, to paths with overlapping parts, fills, boolean operations, clipping paths, effects, etc. One example: in Illustrator, aligning the stroke of a clipping mask (a closed shape) to inside or outside, makes that stroke disappear. It is visible only when the stroke is center aligned. Why? I have no idea, but it's something they still haven't figured out how to fix after so many years.

That’s easy to solve: VectorStyler automatically converts those strokes to outlines when exporting. I guess the main reason is that it makes it difficult for the software to calculate and draw the stroke alignment in many situations involving complex paths. In other words: it’s complicated to get it right, so it’s not worth it.

Yeah, it sounds easy, but it's not. Ask yourself why none of the other vector drawing apps (big and small players like Illustrator, CorelDraw, Sketch, XD, Figma, Vectornator...) offer support for changing the stroke alignment on open paths. VectorStyler is the only exception that I know of.

An open path does not have an inside or an outside, therefore the stroke can only be aligned to the center of the path.

Let me give you an example: nesting the layers inside the artboard in a strict parent/child relationship allows us to move the artboards freely on the canvas, without worrying that some objects might end up on another artboard. (That happens in Illustrator, where an artboard will automatically grab any object that touches it. It's extremely annoying.)

That happens because an artboard is actually another type of layer. So the parent/child relationship also applies to the artboard and its content. Once you move an object outside, that object is no longer a child of the artboard or the artboard layers.