Aaaaaaaaaaaargh! CC why did you do this to me? 🤬

Software Carbide Create
1

I have some aluminium dog tags that I want to engrave using my diamond drag engraving bits. The dog tags are anodised aluminium and are about 1.5mm in thickness. The most effective method I have found previously for engraving dog tags is to hold them in a shallow jig so that they cannot move laterally while being engraved. I use CT90 as my workpiece surface lubricant. This works well with a diamond tip traversal speed of 500mm/minute and leaves a good finish, provided the depth of engraving is set to 0.25mm or less. A well-chosen single-line font completes the task.

I scanned a dog tag and turned the scan into a .png image file and then traced it with Super Vectoriser Pro. The resulting .svg file was the perfect shape. Other than its size, which I would fix in Affinity Designer for my jig carve. I exported the file and brought it into CC and created the design on the substrate at the appropriate size and then set the toolpaths for the carve. I set the machine on its carve and was dismayed to see the beautifully formed jig was sized too small, in every dimension, to accept the dog tags. Grrrr… I swore rather loudly and shouted a stream of invective that many Brits will recognise.

I had forgotten that Carbide Create expects all .svg files, created in other vector illustration packages, to be saved at 96dpi. I was annoyed with myself for missing this vital step but it is getting rather old and I would like to request a change in the code. All vector files are considered to be resolution independent and Carbide Create requires all vector files to be a set resolution of 96dpi, which could usefully be addressed. Please! Pretty Please! With a cherry on the top… can vector file resolution be independent, just as it is in every application that can utilise a vector file format? My idiocy has resulted in much wasted time, work energy, material, and extreme frustration. Cheers! :beer:

3 Likes
2

SVG was created for screen and print purposes.
They both are resolution dependent.

I don’t think CC will change it’s implementation.

1 Like
3

A simple checklist for SVG import fixed my idiocy issue…… :rofl:

2 Likes
4

Yes, screens and printed media have an inherent resolution and could be considered to be limited by and dependent on correctly specified resolutions. For example, we consider a printed bitmapped digital image to require a resolution of at least 300 ppi. It has its inherent 300 pixels per inch (or any other assigned value) yet what we see is governed by our viewing distance from the image. There is a generally agreed-upon consensus that this is usually taken to be 1½ or 2 times the diagonal length of the image. Because we are dealing with pixels, we can soon run out of resolution if we are too close to the image or we use a low ppi value.

Printing requires ink to be applied to a medium such as paper. The ink should be applied in sufficient amount, and not break up when viewed closely. It should maintain its integrity for colour and thickness during the printing process. Consideration should be given to how the ink will act when it reaches the paper, and factors such as dot gain may well affect how the final printed text looks. High quality processes like photogravure require very careful setting up to maintain a high quality print run over thousands of copies. Images will be adjusted for color balance, content and screen angles for the CMYK process print technique. Hexachrome uses two additional inks and brings its own challenges.

The foregoing underlines your point about screen and print being resolution-dependent. The use of vector graphics was predicated on taking less space to store them as files, back in the 60s when computer memory was physically large and very expensive. The file is stored as a set of mathematical formulae and therefore it does not have any particular resolution. It does not change in appearance when viewed from different sizes.

The screenshot below demonstrates the principle with a series of different-sized trains, which are all taken from the exact same file. The detail has not been changed in any of the images shown.

trains
trains1920Ă—1358 334 KB

This is the resolution independence that all vector images are inherently capable of. People who use vector files expect to be able to resize them at will because this is a native property of the file format. Unfortunately, CC imposes and insists on an artificial file resolution of 96ppi if one wants to maintain the created size at an accurate 1:1 ratio. No other vector graphics software demands this precondition from a mathematical construct that is nominally free of every resolution constraint.

1 Like
5

In my experience, if you import and into Inkscape, it will expect 96ppi, while Adobe Illustrator expects 72 ppi.

The options here are we can clutter up our UI w/ a control for this (at least one competing program is doing that) and try to accommodate every possible contingency (or include a field for filling in a value which is also error-prone), or we can choose a de facto standard, document it, and expect folks to check dimensions on import.

1 Like
6

This is all good conversation regardless of outcome. At the very least, I’ve learned I should probably have a checklist :heavy_check_mark:

I’ll just reaffirm my past comments re: the UI.
There are a handful of things that a defaults config would be great for. Letting me change my defaults on niche things would be sweet.
Most of them would require no UI and little to no documentation (plenty of folks have undocumented config options that can only be twiddled via some hidden text document…and I vastly prefer that to not having the option at all :yum:)

Disclaimer: I’m not really a programmer so my views on implementation may be naive and I’m fully aware of this. Feel free to correct me as necessary/desired :slightly_smiling_face:

7

If we add a configuration panel, then it needs to be not just documented, but also supported.

2 Likes
8

I’m missing something. The geometric data in a .svg is resolution independent. i.e. it’s stored as a linear dimension (I assume cartesian). How does dpi (ppi) come into play when importing a vector as a vector??? I can see importing a vector and converting to a raster image, then yes a dpi makes sense. But CC is dimension dependent, not resolution. Why is it even looking at the dpi value?? If I stored it at 100mm, shouldn’t it import at 100mm by default, and then give me the option to change it?

1 Like
9

To be pedantic Config “panel” has a bunch of implications compared to Config “file” :slightly_smiling_face:

And generally supporting things like this are low long term efforts because they ~never change and it’s usually a matter of pulling in a bit of text to convert to an int (much of the input sanitizing is solved these days so that’s not terribly burdensome either…maybe :man_shrugging:)

10

SVGs have a number of entries in their header — since they are XML, this is extensible, and there are about as many ways to represent this as their are programs writing out SVG.

Inkscape for example will have:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->

<svg
   width="210mm"
   height="297mm"
   viewBox="0 0 210 297"
   version="1.1"
   id="svg1"
   inkscape:version="1.3.2 (091e20e, 2023-11-25, custom)"
   sodipodi:docname="drawing.svg"
   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" 
   xmlns="http://www.w3.org/2000/svg"   
   xmlns:svg="http://www.w3.org/2000/svg">

Adobe Illustrator instead does:

<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 15.1.0, SVG Export Plug-In . SVG Version: 6.00 Build 0)  -->
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
 width="144px" height="144px" viewBox="0 0 144 144" enable-background="new 0 0 144 144" xml:space="preserve">

while yet another program (I believe Silhouette) does:

<svg xmlns="http://www.w3.org/2000/svg" version="1.0" viewBox="54.91200256347656 228.1790771484375 623.7097778320312 1733.093505859375" width="3.248488426208496in" height="9.02652867635091in"><style id="svg-style">.outline { stroke: black; fill: none; stroke-width: 1px; }
.centerline { stroke: red; fill: none; stroke-width: 1px; }

Note that 96 (for 96 ppi) does not appear in the Inkscape file, nor 72 in the AI one, and neither appears in the 3rd party program).

If someone could convince the SVG standards folks to add a way to specify this, maybe that would be something which we could look into supporting — until then, check when exporting, and re-check when importing.

1 Like
11

That correlates with the standard, and what I was finding.
I’m still confused as to why CC, importing vector data as a vector, is considering dpi at all.???
If a line is stored as going from 0,0 to 0,100 (let’s assume mm) then make it 100mm long. Regardless of any dpi that may or may not be in the file. Or… I’m missing something :man_shrugging:

12

Yup, I agree with you @Tod1d. All of the software I have ever used treats a vector file as wholly configurable by the user at all times. These ancient values of 96ppi (Windows) and 72ppi (Mac) came about when the print industry was moving towards computer-to-plate printing. These internal screen resolutions were aimed at facilitating the digital typeface foundries and the subsequent desktop publishing revolution.

Taking the Mac, which was a major player in the digital print revolution, 72 points to the inch was the chosen value to get a 1:1 relationship between the selected postscript digital typeface and how it was displayed on the screen. A digital typeface with a size of 1pt, will be defined as having a height of 1/72 inch on a screen with 72ppi internal resolution. A 72pt digital typeface will display at a size of 1 inch on a 72ppi resolution screen.

The need for a software application to know the ppi size of a file that is infinite in size is just not easy to understand. The vector file can be any size chosen by the user. It can be expanded or shrunk in any direction and the resolution of the file will never be affected. Counting (and the application) of pixels in an inch, for a filetype that does not use pixels in any way, shape or form, defies logic.

13

It is a vector, and the user may scale it to whatever size they want after it is imported — but it has to be imported at a size which has to be determined somehow — that determination is made using the de facto standard of 96 ppi which Inkscape and the vast majority of other programs use.

A better approach might be to find all the other programs which do not use this standard so as to play nicely with others and harangue their developers.

14

Note that SVG export from Affinity Designer:

image
image2880Ă—1739 286 KB

has an option for setting PPI:

image
image1200Ă—975 28.4 KB

which results in a correctly sized import:

image
image2880Ă—1728 191 KB

1 Like
15

Raster DPI (Nothing will be rasterized).

Geometry Attributes:
x and y: Define the coordinates of the top-left corner of a shape. 
cx and cy: Define the center coordinates of circles and ellipses. 
r: Defines the radius of a circle. 
rx and ry: Define the horizontal and vertical radii of an ellipse. 
width and height: Define the dimensions of rectangles and other shapes. 
points: Defines the points for polylines and polygons.

The only time the dpi should be needed is if you are converting to a raster image.
Importing into CC is creating vectors.
If a 1" square is imported as a vector, it should be 1". If imported as a raster, then it needs the dpi to convert to pixels. ??? I don’t think the conversion in CC should even be using a dpi ???

1 Like
16

Yes, if you don’t set it, then the vectors will be exported at the default 300 ppi and come in at the wrong size:

image
image2880Ă—1728 163 KB

You have to specify/determine/use a PPI in order to get something to appear in a working area at a particular size.

Contrast:

4x6rect

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="100%" height="100%" viewBox="0 0 3300 2550" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve" xmlns:serif="http://www.serif.com/" style="fill-rule:evenodd;clip-rule:evenodd;stroke-linejoin:round;stroke-miterlimit:2;">
<g transform="matrix(0.949891,0,0,1.15919,25.8001,-112.345)">
    <rect x="514.88" y="705.734" width="1894.95" height="1035.21" style="fill:rgb(235,235,235);"/>
</g>
</svg>

(exported at the default 300ppi)

with

4x6rect_96ppi

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="100%" height="100%" viewBox="0 0 1056 816" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve" xmlns:serif="http://www.serif.com/" style="fill-rule:evenodd;clip-rule:evenodd;stroke-linejoin:round;stroke-miterlimit:2;">
    <g transform="matrix(0.32,0,0,0.32,0,0)">
        <g transform="matrix(0.949891,0,0,1.15919,25.8001,-112.345)">
            <rect x="514.88" y="705.734" width="1894.95" height="1035.21" style="fill:rgb(235,235,235);"/>
        </g>
    </g>
</svg>

(obviously exported at the specified 96 ppi)

It will be, if the PPI is set to 96 ppi for import into Carbide Create.

If someone wants to design a drawing program which imports things without setting their size and then allows the user to use such elements at an undetermined size until their size is specified in some fashion — feel free — but good luck supporting it or explaining the UI to people.

17

OK, this explains it, I think… I exported a 1" square in a 2x2 workpiece.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg  version="1.1" xmlns="http://www.w3.org/2000/svg" width="144px" height="144px">
<path d="M144 0 L144 96 L48 96 L48 0 L144 0 Z " stroke="black" stroke-width="1" fill="none" />

</svg>

It’s storing the data in pixels rather than mm or some other dimensional unit. (inches, fathoms, furlongs, parsecs…). So it needs a dpi to convert pixels to inches or millimeters.

Whereas a similar file saved from inkscape outputs in millimeters…

<svg
   width="9.7387056mm"
   height="9.0895252mm"
   viewBox="0 0 9.7387056 9.0895252"

   <rect
       style="fill:#000000;stroke:#fcfcfc;stroke-width:0.001;stroke-dasharray:none"
       id="rect1"
       width="9.7377052"
       height="9.0885248"
       x="0"
       y="0.64918029" />
    <rect
       style="fill:#ffffff;stroke:#fcfcfc;stroke-width:0.001;stroke-dasharray:none"
       id="rect2"
       width="5.9829001"
       height="5.3142223"
       x="1.9351441"
       y="2.4083567" />

Neither have dpi in the file that I can see ??

The Inkscape svg imports at the same size it was created.

1 Like
18

There has to be a unit or a conversion or a scaling factor, either implicit or implied or assumed — for Inkscape see:

https://alpha.inkscape.org/vectors/www.inkscapeforum.com/viewtopic2577.html?t=20338

For Carbide Create, 96 ppi is assumed. Folks who are using software which does not support that should include a rectangle of a known dimension around their work and then select everything and scale to that size on import.

19

Will, my apologies but I don’t understand what you have said here. (in the emboldened text) The vector file is created at the size the creator and the creation software selects and applies. Ergo there is nothing for CC to determine in relation to the object created sizes.

The attributes of a vector file include the Cartesian coordinates of any object that is contained in the file format. For example, we know that this includes the objects, the line and the fill colours, the line lengths and their positions.The vector file does not carry any information relating to the screen resolution because it is not relevant to the construction of the mathematical objects stored within the file.

Really? Are you having a bad day? I have acknowledged my own mistake in a lighthearted way in my OP. Is that haranguing the developer? I was interested in understanding this issue. You have misread my intentions and sought to shut this thread (and me) down by being obnoxious.

20

I am going to side with Will. It is what it is.

I think the problem does not show up as obvious due to the factor difference is small compared to a inch/mm mistake.

Great conversation, but mute

1 Like