[SVG scaling from CC to LightBurn]

Unsupported
1

Right before the server crash there was a post about how when one exports an SVG from Carbide Create, and then imports it inside LightBurn (popular laser engraving software), everything shows up 133% larger than it should.

Just setting the scaling value to 0.75 on the imported shapes inside LightBurn addresses the issue. But I was still wondering, so I dug a little bit deeper.

Since the word editor where I had taken a few notes yesterday evening was still open, I figured I would dump the conclusion here for future reference.

So just for fun I tried creating a 100mm long straight line in Carbide Create, in LightBurn, and in Inkscape, and tried to export it to SVG from each one and import it into the tow, here’s what this told me:

image
image1024Ă—1017 227 KB

The single case where a scaling problem exists is when exporting from CC and then importing in LB: the 100mm becomes 133mm.

Out of curiosity, I checked the content of the three SVG files, I’m copying extracts here (with all unrelevant data removed for clarity)

SVG exported from LB:

<svg width="100.000mm" height="0.000mm">
    <path d="M15.000000,49.000000L135.000000,49.000000"/>
</svg>

SVG exported from IS:

<svg height="297mm"  width="210mm">
    <path d="M 0,0 H 100"/>
</svg>

SVG exported from CC:

<svg width="377.953px" height="0px">
	<path d="M0 0 L377.953 0 "/>
</svg>

So,

  1. CC uses pixel units, and uses the standard 96DPI, 100mm at 96DPI is 378pixels.
  2. Lightburn manages SVG import correctly when the input unit is mm
  3. but apparently, when the imported SVG unit is pixel, LightBurn uses a 72DPI resolution, and therefore converts CC’s 378px to 133mm instead of 100mm.

And now I’m headed to the LightBurn forum to ask whether this guess is correct, and whether this is intentional (apparently there is no absolute right or wrong in the world of SVG formatting and DPIs)

EDIT: and by doing so I now remember it was @GJM who initiated the original thread. Not that I want to pull him into my SVG rabbit hole :slight_smile:

3 Likes
2

I dug the hole…I may as well join you.

2 Likes
3

FWIW, I’d suggest that the problem here is that Carbide Create is outputting SVGs using pixels as the unit for its dimensions.

The user’s intent is to produce files that represent a design with certain physical dimensions. As such, the output files should be written with physical units.

If you want to get into the value for “correct” DPI, I don’t think there is such a value here. You’re right that the CSS standard (upon which SVG has based its dimension attributes) specifies a “96DPI” reference pixel, however that’s a simplification.

What the reference pixel really is, is:

the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm’s length

The specification then goes on to elaborate that different reading distances will result in different conversions from pixels to physical units.

So I’d expect to see different physical pixel sizes depending on whether I’m using, for example a laptop (which is closer to my face, say 50cm), a large monitor (which is a bit further away) or a TV hooked up to my computer (which is across the room).

Fundamentally, the pixel is intended to be used for display devices, to produce a design that is equally legible across many different devices (and even print media).

It’s not intended to be used to represent physical dimensions. We have physical units for those.

4

Unfortunately, the SVG specification seems to lack an agreed-upon implementation for using real world dimensions.

5

Yes…but it seems that CC is standing alone on 72DPI and use of pixels - at least among this set of products…

6

What do you mean? SVG follows the CSS specification, which supports a number of physical units, including inches and millimeters.

7

Carbide Create uses 96ppi on import which matches Inkscape. as noted at: Download Carbide Create

427

  • (NEW) Updated SVG parser to newer version. SVG import scale might have changed for some files. We now assume a 96 DPI scale.

ISTR mentioning that exporting and reimporting didn’t yield the same result, so this should be in the queue for review.

8

None of which are agreed-upon as to be used by any programs AFAICT — if you can find an instance of specifying dimensions in one way on export in one program and then importing them into another program which uses some other method of specifying dimensions which will properly parse things, I’d be very surprised.

specification != implementation

9

Didn’t Julien demonstrate this in the first post? Inkscape was able to import CC’s pixel-denominated file and translate it to mm.

And every piece of software was able to accurately handle files denominated in mm.

So it seems that the physical units are better supported than pixels?

10

And the tests above suggest it also uses 96DPI on exports.
Funny story, the thread on the LightBurn forum is developing to add that Illustrator imports CC exports correctly, but CorelDraw doesn’t.

I can see the conclusion coming, that it’s pointless to figure out who’s right or wrong, and just compensate the scaling factor and call it a day.

2 Likes
11

This, I think, should be the conclusion for now.

1 Like
12

Given that Adobe pretty much developed the SVG specification, they should handle its files correctly.

I’ve always found Corel hard to take seriously given that they started out as an internally-developed program for the marketing division of a computer storage manufacturer and their PostScript support has always been execrable and the interface not much better (and I’ve used it since v2.11 or so)

1 Like
13

@WillAdams Could CC be adapted to give the user a setting a to how they’d like to export their SVGs? Make mm a default, but give people a checkbox to export px so that you maintain backward compatibility?

14

If you can find a widely available/used program which will accept and properly size an SVG based on it being output in mm we’ll put that into the feature request queue.

15

@WillAdams Unless I"m reading it wrong, Illustrator, Inkscape, LightBurn, and apparently CC! (since an SVG exported in Inkscape (mm at 96) is correctly loaded into CC!)

16

I think the burden of proof is backwards.

We have hard evidence favouring physical units (numerous pieces of popular software interoperating correctly while using them, including the two most popular vector editors) and hard evidence against pixels (popular software failing to interoperate correctly while using them).

What we don’t have is the inverse: hard evidence against physical units or hard evidence for pixels.

17

FYI, the LightBurn guy answered and has changed the DPI for “px-based” imported SVGs from 72 to 96DPI (thumbs-up for this reactivity), which I think settles the matter.

And they all lived happily in 96DPI kingdom ever after.

3 Likes
18

For anyone’s info who’s interested…

I was able to create a design for some clamps in CC and then brand them with my name in LB by exporting the SVG in CC, importing into LR, scaling by 75% (soon, will not have to do that), and then positioning the text.

At first, I ran into an issue creating a starting point (I chose to use center), because the center point in CC ends up in a different place than the center point in LB, due to the fact that LB only sees exported objects, whereas CC sees the entire canvas.

I solved this by bounding my entire design in CC (the entire canvas) in a rectangle that is not Toolpath’d, but gets exported in the SVG. Then, when I imported the SVG, LightBurn sees the rectangle and sets it’s center based on it. This gave me an identical center to CC and I was good to go. Worked like a charm!

3 Likes
19

This topic was automatically closed after 30 days. New replies are no longer allowed.