Exported SVG has bitmap objects added 1 pixel width of transparent pixel around the edges

[KarlLegion]

My file has pixel and vector objects. The pixel objects are created by power duplicate and carefully aligned. The vector object has a 1 pixel stroke aligned inside. But after I export it as a SVG and check the exported file, I found the objects shifts. And the top left object misaligned with other objects. The SVG I show here shifts the objects by -1,-1, sometimes it can shift to other directions. have 1px of transparent pixels added around the edges.
Attached both the .afdesign and .svg files. test.afdesigntest.svg

Please pay attention to the coordinate from the transform panel. It shifted.

The size of 1 object should be 1583x756. But the objects from the SVG changed, and inconsistent in size.

The other objects are having different size than the first one and shift differently.

This bug maybe related: 

 

System:
Lenovo Legion Y540-15IRH i7-9750HF
RAM 16GB
NVIDIA GeForce RTX2060
Windows 11 Home 22H2 22623.1028
Windows Feature Experience Pack 1000.22638.1000.0

[NotMyFault]

Your curve is 1px wide, and aligned center. So it will cover 2px, 1px outside the canvas. When you export, this adds the extra pixel.

unfortunately it seems impossible to set the alignment to inner, which would avoid the issue. Reason: the curve is open / not closed.

whenever you create an object which extends over its regular bounding box (layer fx, stroke width etc) the exported object will add such extra pixels.

either change settings, or add a rectangular shape as clipping path to cut off unwanted extra pixel.

[NotMyFault]

Mis-aligned 1px stroke (stretched over to 2px with 50%alpha)

after unclip canvas: line gets 0.5px position, but only 1px stroke at 100%.

this 0.5px extra leads to 1px extra at export.

[NotMyFault]

File with clipping rectangle. The inactive layer is svg export - showing no extra pixels

test 2 clipped.afphoto

[KarlLegion]

 

Hi @NotMyFault, thanks for all your effort of trying to help. I really appreciate all Affinity users reaching out for others who are in need for help. But... the curve is actually not the cause of the problem... and your explanation is irrelevant (your help are still appreciated, really🙂). Try this file which has no vector objects or FX at all. Plain bitmap with no half pixel edges. test(no vector).afdesign. When you export it as a SVG,test(no vector).svg the objects will still shift and their dimensions are also changed. Please pay attention to and compare the top-left coordinate and dimensions of all objects (especially the top left object and any 1 other object). 

It seems their original pixel coordinates are not changed. They are just added 1 pixel width of alpha either to their sides, top or bottom. Their bounding box is extended outside of the canvas. Which is definitely unusual.  But for my use, it still matters. The supposed dimensions can't be changed...😕

Quote

Your curve is 1px wide, and aligned center. So it will cover 2px, 1px outside the canvas.

I'm pretty sure a 1px stroke only cover 1px and has 0.5px on both sides instead of 1px😓
When you clip canvas, it clips to half pixel, it's because those half-tone pixels are just for rendering purpose. The stroke is still half on both sides.

Quote

When you export, this adds the extra pixel.

Actually, it won't... Because when you export the whole document, it won't clip the canvas, unless you choose "selection only/selected area" as the export option. Other than that, the single only case it add pixels, is when the closed object has its stroke aligned outline, which will have it's strokes "baked".

And for your example, it will shift the object xy by 0.5px and the dimensions add 1 to h and w.
For other cases (for vector objects aligned to 0,0):

• bitmap files export: out-of-canvas strokes get clipped
• vector with strokes aligned center: keep the stroke property (bounding box is still on the curve instead of on the stroke)
• vector stroke with "texture line style": get flatten (treated the same as bitmap)

You can try all the above by yourself to confirm.😉

For either cases, the bounding box won't be able to get outside of the canvas anyway. 

Even for the case of using "selection only/selected area" to export, the object's top-left coordinate are supposed to always stick to 0,0. Please consider my finding above "It seems their original pixel coordinates are not changed. They are just added 1 pixel width of alpha either to their sides, top or bottom." It's the opposite of your expected result. 

Quote

The inactive layer is svg export - showing no extra pixels

Actually it added extra pixels and the objects shifted...😓
Your embedded document didn't shift but the actual content inside the SVG shifted... After you tap open the embedded SVG in a new view, you can check the dimensions and coordinates I mentioned above.

(Did you export your SVG with APhoto iPad? Then it has the same bug too.)

[NotMyFault]

7 minutes ago, KarlLegion said:

Try this file which has no vector objects or FX at all. Plain bitmap with no half pixel edges. test(no vector).afdesign.

This file shows fractional canvas size. If you want pixel exact results, you need to avoid this issues in any place.

[NotMyFault]

12 minutes ago, KarlLegion said:

I'm pretty sure a 1px stroke has 0.5px on both sides instead of 1px and only cover 1px😓

Only when you place the line at positions 0.5. if you place the line at e.g. 1.0, it will stretch from 0.0 to 2.0 with 50% alpha. You can see this in your file and my screenshots.

if in doubt: create a really small file 8x2 px and try it out.

[KarlLegion]

2 hours ago, NotMyFault said:

This file shows fractional canvas size. If you want pixel exact results, you need to avoid this issues in any place.

Please, don't be picky on such thing...🤨 It shouldn't contribute to the bug. If it did, it's still a bug... If you really think that cause the bug, why didn't you mention it in you first reply?...😓 Could you please resize the canvas to integral dimensions by youself and try to export? I can't access my laptop right now... 

It's an A4 size@1000dpi. Affinity provides the preset and I need it, so I use it. Make sense right?😉 I export it to my laser cutter which has A4 as its maximum project size, so I start the project with A4. I always know fractional size may cause problems at some point, that's why my objects has no decimal dimensions. Please be focus on the objects instead of the canvas. Now the objects have added alpha individually, I don't believe that you would believe the canvas is the cause of the bug right?🤔 (I think I should change the title of of my post)

2 hours ago, NotMyFault said:

Only when you place the line at positions 0.5

No... Forget about the rendered pixels on your screen... of course I know what you mean by "stretch from 0.0 to 2.0 with 50% alpha" That's why I said:

2 hours ago, KarlLegion said:

it's because those half-tone pixels are just for rendering purpose

You can see I did already consider if the curve is placed at full pixel and the rendered pixels of the stroke on both sides of the curve has 50% intensity...😓

I said it "only covers 1 px" is only because the actual stroke is actually covering 1px width of canvas. I didn't say "it renders 1px on the canvas". In contrast, what you meant is like "the curve has a 2px width 50% alpha of stroke when it's placed at full pixel " which is incorrect...😓

Again, those pixels are just for rendering purpose only... They are only valid if you flatten them. In the case of exporting, which is when you export them as bitmaps (flatteningis not involved in any steps right? Then forget it!). No matter how the canvas renders the pixels, for vector objects, pixels are always not there, curves and strokes are. Please remember, you are talking about curves, I'm talking about curves, we should be on the same page of vector objects. Again, forget about those pixels, for vector objects, they are just for rendering purpose only.

Actually, the curve is the thing we should forget about... because it is no longer in the formula. Please forget it and focus on those bitmaps.🙏🏻

[NotMyFault]

I step out of the discussion. Have a nice day.

[Old Bruce]

On 12/10/2022 at 7:41 PM, KarlLegion said:

The vector object has a 1 pixel stroke aligned inside.

Yes, but the vector object is in fact a series of open curves. This means the alignment is in the centre not the outside because, to date, there is no inside or outside for open curves. I separated the curves and made the one in the top corner much thicker and red, the others are green (and slightly thicker). I also dimmed the pixel layer(s). Here you can see how the stroke is outside the canvas.

 

[KarlLegion]

Thanks @Old Bruce, you are right. My statement of "aligned inside" is invalid. I forgot I have an open curve at the time I created the post.😓I didn't clarify, it's because I later found out the curve is not the cause of the bug anyway. I have a new file, simplified and no vector objects, has the same faulty SVG output. bitmap svg test.afdesignbitmap svg test.svg

Please see how the parameters are changed

[NotMyFault]

playing a bit with the file gives the following findings

• You can copy one single pixel layer, and create new from clipboard
• If you export as as svg, extra pixel gets added - and image gets embedded into group layer (Transform) causing the extra pixels

<?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 1583 756" 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(1,0,0,1,-16,0)">
        <use xlink:href="#_Image1" x="15" y="0" width="1585px" height="757px"/>
    </g>
    <defs>
        <image id="_Image1" width="1585px" height="757px" xlink:href="data:image/png;base64, XXXXX
        fs>
</svg>
 

• if you flatten the file with the pixel layer, and export again: no extra pixel

<?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 1583 756" 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;">
    <use xlink:href="#_Image1" x="0" y="0" width="1583px" height="756px"/>
    <defs>
        <image id="_Image1" width="1583px" height="756px" xlink:href="data:image/png;base64,

 

Something in the pixel layer is causing this behaviour. Can you explain how you created the pixel layers? 

[KarlLegion]

28 minutes ago, NotMyFault said:

Can you explain how you created the pixel layers?

I composited the bitmap by shapes, curves, effects, a svg, texts and an image. The background was created by a no-strokes rectangle, sized by full pixels from the transform panel. Then all got flattened. For privacy reason, I then painted out the details and flattened them again.

[KarlLegion]

22 hours ago, NotMyFault said:

image gets embedded into group layer (Transform)

Hi @NotMyFault, thanks for your inspiration, now I have some new findings and several bugs here! "Transform" is the key factor.

But first, the images in your reply is replaced by scripts... I see no images...

At first, I didn't know what "Transform" you meant. Then when I checked the objects which are put under "Layer" in SVG. I noticed they are "Image" instead of "Pixel"😮 I didn't know bitmaps are in embedded form in SVGs 😑... but it makes sense... (I overlooked your word "embedded"...😓I simply translated it as "put"🙄 Because Affinity doesn't handle those kinds of "Image" as "embedded". Embedded files, in Affinity's term, are those stored in their own "container" and can be double-click opened in new view for separate editing. Affinity handles those "embedded" as "Image layers")

Here are some new findings:

• Exported SVG put some objects under "Layer" while others doesn't. Here are some conditions that objects won't put under "Layer":

1. non-transformed pixel layers, shapes and curves (not moved or resized, or rasterized after transformed)
2. non-resized image layers snaped to 0,0

• Objects getting put under "Layer" or not, is not a factor to determine if transparent pixels are add to a pixel layer. All pixel layers will have pixels added, unless they are full canvas sized and rasterized (no transforms afterwards).
• For shapes, curves and image layers, once any one of them have been resized(not by editing nodes) then exported, all objects' dimensions and strokes will not be precise. The changes are very small fractions of the object size.
  

     

• once you decrease the dimensions (width and height) of an image layer to make the dpi increase to a point (e.g. from 72 to 96dpi), the exports SVG will have their dpi changed along with its dimensions. While increasing the dimensions will have no effects.

 

[tudor]

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.

[KarlLegion]

Hi @tudor, thanks for your reply and the reply from my other post.

On 12/15/2022 at 5:25 AM, tudor said:

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.

Do you suggest this is not a bug? Even these behaviors are caused by svg limitations, Affinity should definitely handle it better. This is a design fault of the software, and design faults are also counted as bugs. SVGs are bad kids and bad kids need discipline. As long as Affinity choose to adopt them, she is responsible to discipline them, at least gets them act good in front of public. When a bad kid made troubles and got complains, his parents can't just say "My kid always gets misunderstood." but do nothing else to fix the problem. Affinity can definitely do better than this. For example, "flatten transforms" should be default for svg exports which can prevent "misunderstanding". 

On 12/15/2022 at 5:25 AM, tudor said:

You use bitmaps, millimeters (it's an A4 layout for print), and a weird dpi value (1000? why?)

Why?🙄Why do you ask why?🤔 Here is supposed for bug reporting right? Now you want to start a use case study session? Ok I don't mind having some laser cut file studies here. But first, when you said my setup and 1000dpi value is weird, then I suppose you have a laser cutter and prepare the files by yourself, and you know what a "normal" setup should be, right? And you, somehow, even know what machine and software I use to cut?😮(No way, just kidding😉) 
Only criticizing but without knowing the full picture first is not nice. Tell people "I know!" but without explaining is not constructive at all. Just like:

On 12/15/2022 at 5:25 AM, tudor said:

the SVG file format works in relation to the units of measurement and the resolution of the embedded bitmaps.

So... Then what? You are right and I can make the same conclusion too. I just don't know how it works. For the 4 findings in my comments, you explained none of them... As long as you left the comment and likely that you know how it works, why don't you explain a little bit just like other comments above? What you said is just like "I know something you don't know but I don't bother to tell and I enjoy criticizing.", "Your file is weird. But I don't know how to improve because I don't even know your machine and your software.", "A fraction of a mm shouldn't be a roadblock to your work. Don't bother to report it! Someone else may be affected but they are not you! Just let them report it by themself!"

My post is for bug reporting. Any invalid comments will just make useful findings get overlooked. Some comments may not be related to the bug but may be educational or inspirational which I find they are at least beneficial to other users reading the post. Just like all other comments above, when they pointed out something they were generous to explain and made examples. Even though they may not be helpful to the bug, at least they are beneficial to other users maybe. So, what's the purpose of your comment? Just to make yourself feel good by telling me "I know something you don't know"? Not cool.😕

Now, here's the answer to your questions and the start of laser cut files study session.🎒🏫

"my laser cutter which has A4 as its maximum project size". I know you did read it. So I feel weird that you felt weird about me using A4 to setup the project. Or did you think I made it up? 😕 Or did you think because mine is a laser cutter, so it shouldn't have the size of a printer? This logic is not quite logical.🙄 (Actually the work area is close to A4 (300x210mm). I just don't bother that 3mm.)

• For the 1000dpi, it's for bitmaps not for curves.
• For the bitmaps, they are for engraving.
• I engrave at 1000dpi. So, the dpi matter. It's normal for laser cutters, nothing weird here.
• I work on physical objects so I use physical measurements in software.
• My svg has both curves and bitmaps so I can send a single file to my laser cutter for both engraving the image and vector cutting the contour to finish my products. And it's neat to archive. (Actually I didn't use to prepare my files this way. It's my new method, then turns out to be less reliable. That's why I report the bug just now.)

That's it! Do these make sense to you?🙂
When you have questions, you ask. When you ask, be humble and nice. This is what I deem a good attitude contributing to good conversations. 😉

Oh, one more thing. The most important one: THOSE FILES ARE JUST FOR DEMOSTRATION PURPOSE ONLY! They are work-in-progresses! I'm curious why didn't you ask me "Why do you work on color bars of 10000*10000px SVG? Are you nuts?" (Just kidding😁Of course you know they are demos)

On 12/15/2022 at 5:25 AM, tudor said:

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.

I don't worry about it. And it never gets in my way of my work at all. Actually I didn't even ask for help. I'm just doing a bug reporting. A bug is a bug. Some people, including me, report a bug not because it got in our way, it's simply because we found it, and we want to improve the software so other users won't be affected. It's for ourself and also for all users.
Those fractions of mm won't have noticeable effect on my laser cut but may have negative impact on some use cases for other users, even for seasoned professional designers. Just because Affinity didn't set "flatten transforms" as default. Look at my example:
Someone created a file with 8 curves here. They all look identical, 2560px long with 30px stroke. Aligned perfectly

An then the file was exported as a svg and sent to me. I see something else. I see all 8 curves are not aligned with each other and the stroke are inconsistent.

Then I open it with Inkscape. I see this

If you receives this svg, would you feel it professional at all? "Flatten transforms" is almost always necessary. Why isn't it a default?

Files here 8 lines test.svg8 lines test.afdesign 

Of cause we know the cause and we have workarounds.

• avoid resizing (inconvenient in some cases)
• Flatten Transforms in svg exports (if you have image layers reduced size, the canvas will still be changed in Affinity, object positions will still be shifted, possibly be fractional and get unsharp pixels. I don't know what will happen in other software.)
• don't use SVGs (sometimes we're forced to use, e.g. client request)

I don't know if we have other workarounds. I don't even know the meaning of other options in Export Settings (e.g. Longer text span, Use tile patterns). Unfortunately no one tells me but criticizing. Anyway, it supposes to be ok. I suppose don't need to know all the options and technical details of SVG specifications. Affinity should have made us easy for exporting SVG without messing things up. Even though people "misunderstand" SVG's working principle, they deserve to get the exported files as close to their expectation as possible. A little check box "Flatten transforms" for a much better improvement. Why isn't it a default? (I really don't know and am really asking because I'm not a SVG expert)

Any suggestions? 🙂

 

[tudor]

8 hours ago, KarlLegion said:

Do you suggest this is not a bug?

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).

8 hours ago, KarlLegion said:

I work on physical objects so I use physical measurements in software.

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.

8 hours ago, KarlLegion said:

"Flatten transforms" is almost always necessary. Why isn't it a default?

Because SVGs have many other uses besides laser cutting and sometimes they need NOT to be flattened. Read this:

 

[NotMyFault]

@KarlLegion Affinity has very limited resources, and prioritizes what bugs to get fixed. As far as i understand, Affinity looks  how many people are impacted, and how severe the impact is. 
 

From history i can tell you that bugs

• reported by only one user
• reported using tons of text, very time consuming to read and understand
• complex to reproduce 
• Multiple reports opened by same user to the same topic
• have almost no practical impact (made-up documents)
• related to software design decisions instead of implementation
• affecting principle limits of import / export file formats (out of control by Serif)
• workarounds are available

probably get a very very low priority. We have currently thousands of unfixed bugs, some open since >5 years.

There are tons of older reports about 

• issues with SVG export
• issues with added pixels during exports

so you report does not bring much new aspects, and is probably covered in those older reports.

 

[Old Bruce]

Dots Per Inch don't work well with the metric system's linear measurements.

[KarlLegion]

10 hours ago, NotMyFault said:

Affinity has very limited resources, and prioritizes what bugs to get fixed

I know... You're right... I don't hold my breath. I also feel the priority is very low.😒 But that's ok for me. It won't affect my work anyway. I can just work in my old way.(no images in SVGs)
I'm just doing my job of bug reporting, somehow having lengthy discussions.🙄

10 hours ago, NotMyFault said:

reported using tons of text, very time consuming to read and understand

That's why I said "

20 hours ago, KarlLegion said:

Any invalid comments will just make useful findings get overlooked.

I was going to abandon the post, somehow a new comment came...
Quality comments matter😉

2 hours ago, Old Bruce said:

Dots Per Inch don't work well with the metric system's linear measurements.

Thanks for your advice, Bruce. Your single sentence explains a lot. 🙂

(updated: Do you mean if I use imperial as the canvas size can avoid rounding(at least for the canvas) and get more precise results?)

[KarlLegion]

Thanks for your explanation first.🙂

14 hours ago, tudor said:

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.

So you think I'm an idiot that don't know pixels is a physical unit of measurement? 🙄 It's quite insulting...😕 If you're really asking, could you please ask it nicely? If you're judging, that's just unconstructive...

Something I have to clarify. Although I was producing physical objects, it's not necessary for me to work my file in physical measurement. Although I set up the project in an A4 size, I worked everything in pixels. The size was just for a reference so I knew nothing was working outside the limitation of my machine, so were other image designs. After I got their physical dimensions, I will convert them to pixel size by rounding them manually, instead of leaving them having unsharp lines. You can tell from my file attached file before, I was working in pixels all the time. So I was not checking for errors using pixels, I was told there were errors while I checked the file.

The story is: First, do you remember what I said:

On 12/16/2022 at 5:41 PM, KarlLegion said:

Actually I didn't use to prepare my files this way. It's my new method, then turns out to be less reliable

I used to use Photo instead of Designer (because of v2 trial) for image preparing and exported them as bitmaps. The vector cut is exported separately or done directly in the laser software. Since I only need physical measurements for reference only, I chose to work in pixel unit for pixel perfect result. (The smallest details can be shown on my projects is as less as 3px) Although my laser software only accept physical measurement as input value (even for bitmaps), using physical units as file outputs will just make images lose even more sharpness. I did really say that "I work on physical objects so I use physical measurements in software." because I really used them and/only needed them for physical dimension references. And again, the file I provide was altered from a work-in-progress. The final output was "Clip canvas" from those full-pixeled objects to achieve a full-pixeled bitmap, at the same time, the physical dimensions were noted for laser software input. (The rounding from laser software is unavoidable)

I didn't expect to explain so much details about my work flow because it's totally irrelevant to the topic. And previous comments are lengthy enough. And I didn't expect anyone would ask such irrelevant question trying to make themself superior. 

Some people give comments for trying to help, while some trying to make themself superior. I don't want any arguments. I just hope everyone's comments is comfortable for anyone to read 😉

[tudor]

11 hours ago, KarlLegion said:

Although I was producing physical objects, it's not necessary for me to work my file in physical measurement.

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.

11 hours ago, KarlLegion said:

After I got their physical dimensions, I will convert them to pixel size by rounding them manually, instead of leaving them having unsharp lines.

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.

11 hours ago, KarlLegion said:

You can tell from my file attached file before, I was working in pixels all the time.

Your test file opened on my computer as an A4 print layout set up in millimeters. 

11 hours ago, KarlLegion said:

Although my laser software only accept physical measurement as input value (even for bitmaps), using physical units as file outputs will just make images lose even more sharpness.

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.

[KarlLegion]

On 12/18/2022 at 1:40 AM, tudor said:

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.

I can't agree with it. It's just up to people's preference, including their needs and convenience.
For example, for average people, when they sent their photos for casual printing, almost no one will care about the dpi-dimensions relationship. They just set the print size and fit mode then print. So, working in pixels is sufficient enough, for people's convenient.
But when people want to preview/predict the outcome of their prints, they need to work in the physical output size and resolution from the screen.
Also for commercial printings, you may need to set your files for 1:1 printing. So we need to work our files in physical units. In this case, it's for the needs. But again, even we don't provide a 1:1 file, the print shop can still work them out, the difference is just few more conversations for clearing things out. So, at the end of the day, it's also for convenience.
The dpi-dimension concept is for the working principle of printers, luckily the driver will handle it well. While for the need of 1:1 printing (and use physical dimension units), the reason is valid, however It will be just fine for us even we work in pixels.
Please be flexible. In this fast and ever-changing world, don't say "you should always" so easily. Laser cutting, 3D printing, CNC routers, AI graphic, deep learning, optical logic gates, quantum computing, RSV-influenza-COVID tripledemic... So many we don't know and even more is coming! Please be open-minded and be humble to learn.
Flexographic, lithographic, rotogravure, screen printing, pad printing... How much of these have you heard about or familiar with? Do you know how they implement digital technology in the printing production? You are not in the printing industry, why do you talk like you know everything?
For my case, working in pixels is for my need. I do everything for every processes. I know my work the best. I can tell the difference between good and bad results. Who know better than me for my work? While a good chef use a drill as a food blender. You don't tell him "you should always use a proper blender. Drills are for drilling things." A wise person don't judge the method, only judge the result. Please don't be ignorant and arrogant.😕

On 12/18/2022 at 1:40 AM, tudor said:

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.

Bitmaps are not like vectors, as long as the print scale is 1:1, we get what we see (of course it depends on the machine and substrate quality). If it's unsharp on the screen, it's also supposed to be unsharp on the print. For my laser engraving, those unsharp edges are half-value pixels. Half-value pixels are half-power beams. Considering the engraving depth is not proportional to the beam output. Reduced beam power may lead to some materials have depth significantly reduced, or even have the surface just scorched. So, for designs with small detailed textures, those half-value pixels can change the product from textured to plain. Sometimes the product is not just for show like prints, they can be a tool. Take rubber stamps as an example, those unsharp pixels can make thin line text of a stamp unstampable (Do you remember I said the smallest detail can be as small as few pixels?)

On 12/18/2022 at 1:40 AM, tudor said:

You're just wasting time converting everything to pixels.

It just use me few seconds on it because I'm not converting everything. I only need to convert the object contour (only 1 object per project) to pixels from the dimension reference.

On 12/18/2022 at 1:40 AM, tudor said:

Your test file opened on my computer as an A4 print layout set up in millimeters. 

I can't believe I have to repeat it the third time... The file is a work-in-progress... And I said it in my last comment, the canvas is destined to be clipped... Look at the things I already worked on - the objects... If I didn't work in pixels, how can I create full-pixeled objects?😕

On 12/18/2022 at 1:40 AM, tudor said:

Even your laser software tried to tell you that you should always use physical units!

It suggest nothing... Every printers also only accept physical units...😕 Just like I mentioned above, average people don't care about the physical dimensions when sending their photos to print. Are they doing all wrong?😒
Please remember, bitmap exports are destructive, they're not like vectors. Once they get fractional pixels, after exported, those pixels will shift and become fractional value full pixels. You can't just input your intended dimensions and get those half-value pixels reconstructed back to full-value. It's no advantages in quality when exporting in physical size. 
Actually I don't know what my laser software is suggesting, it's quite ridicules. It doesn't accept "real" 1:1 bitmap import. I mean, the 1:1 input is 254dpi for bitmaps, fixed. But interestingly it doesn't support 254dpi engraving... So, the dpi setting for my bitmaps are useless... At the end of the day, I still have to resize my images...

On 12/18/2022 at 1:40 AM, tudor said:

Pixels are for screen, stop obsessing with pixel-perfection if you don't do screen work.

It's true that pixels are meant for screen, but the value it represent is valid for printing/engraving. By checking on the pixels, I can predict the engraving quality. Working in pixels give me better prediction than working in physical units (pixels won't shift after export). While doing pixel-perfect is easy, nothing wrong and getting better result, why not pixel-perfect? It's not an obsession, it's a good practice and useful. In contrast, if I can get better result by working in pixels, easily, but insist to work in physical units instead, just because someone tells me it's a conventional way for creating printing/lasering images, then it's what we call obsessed, and also stubborn and stupid.

On 12/18/2022 at 1:40 AM, tudor said:

But you need to learn the difference between screen and print before blaming the software for bugs

Why do you say that I "blame" the software for bugs? People usually blame something when any loss is caused. But for me, I didn't say the "bug" (don't be sensitive, just to make things simple) caused any damages to me, not even once. What I did was just reporting the "bug" (like anyone does), pointing out some findings (descripting the nature of the "bug"), making some arguments with others (because someone had objections but didn't explain the unusual phenomenon), making some suggestions for an improvement (so constructive), but I did never blame the "bug".
I assume what you said "blaming the software for bugs" is actually meaning "bug reporting".
You know what? No one knows what they don't know, no one knows everything. So you can't say "But you need to learn the difference between screen and print" when people report "bugs". Are you suggesting no one should report any bugs, until they know everything? It's nonsense...

Also, all the stuff you talked about svg is nothing related to "the difference between screen and print". I don't know what's the logic behind such comment... SVG rounding errors, I understand. But why suddenly you talk about print? I think I know their difference better than you. I used to work in 2 different companies in printing industry.😒 In contrast, screen and print have something in common, they both use "dots" to represent resolutions. When they see vectors, they all calculate and render the vector data to "dots". If their are any difference from input to output, it's only because vectors in between (dots>vector>dots).

Considering your lack of example of usage of SVG and explanations of the working principles, seemingly ineffective formular causing unnecessary rounding, and all those invalid comments about printing, you are seemingly neither professional in SVG, maths nor printing technology... Considering the effort you did in your comments, it's not worth my challenge, but people can tell by reading... More invalid challenges won't make you look smarter... Please stop your ever-raising challenges or trying to explain something not you familiar with... I'm so tired to explain again and again and again... I have my own way to do my work and I know it's just fine... The topic is off too much... Please stop...🙏

[Old Bruce]

1 hour ago, KarlLegion said:

Actually I don't know what my laser software is suggesting, it's quite ridicules. It doesn't accept "real" 1:1 bitmap import. I mean, the 1:1 input is 254dpi for bitmaps, ...

Hmmm... this suggests to me that your laser is moving in tenths of a millimetre. 254 DPI equals ten pixels to the millimetre. 

[KarlLegion]

59 minutes ago, Old Bruce said:

Hmmm... this suggests to me that your laser is moving in tenths of a millimetre. 254 DPI equals ten pixels to the millimetre.

My maths is the same.
But for vector imports, it's a standard 72dpi, fixed... Only one unit can be used in a job, mm or inch, even that's a mix of bitmaps and vectors... And only resolution options are 100, 250, 500, 1000dpi... So it's only right if it really has a 254dpi option for me...