Experimental SVG support

[arkypita]

Write here about SVG support

[StuartB4]

Hi. Just a bit of info. Just installed v2.9.0 and made a quick test .SVG file. This was the result:

I left the settings at the default ones, loaded the .svg file in which was made in Inkscape. I noticed the M4 command to switch the laser on, like in the picture below. But after generating the code and saving it, I looked at the code and saw it had generated M3 instead for the laser On. There was also an off-set of X1 and Y2 mm's added when I loaded the file in.

I also noticed in the code there is no return to home position code generated. So when it had finished burning, the laser stopped at the (bottom right) end of the last line. Not sure what the M30 was supposed to do, but I removed it from the end of the code and added G0 X0 Y0 to the end instead. Then loaded it back in, ran the code and after it finished the laser returned Home.

Generated code (Beginning and End) with a large section removed, it's actually 234 lines of code:

M5 G0 X31.523 Y32.336 M3 S255 G1 X38.624 Y32.336 F300 G1 X38.624 Y38.570 G1 X31.523 Y38.570 G1 X31.523 Y32.336 M5 ........... ........... ........... G0 X36.346 Y1.928 M3 S255 G1 X31.585 Y7.636 F300 G1 X31.264 Y2.268 G1 X35.063 Y8.577 G1 X29.949 Y7.295 G1 X37.058 Y5.486 G1 X34.219 Y10.062 G1 X34.813 Y2.635 G1 X38.172 Y6.745 G1 X31.431 Y3.963 G1 X36.346 Y1.928 M5 M30 M30

This is the finished test burn after 1 pass. It burnt the shapes in this order: 1: Square. 2: Spiral from center. 3: Circle. 4: Left Star. 5: Right Star.

[arkypita]

Hi @StuartB4 Thanks for your quick feedback. You are right in all of your observations.

I have used a third-party code (heavly modified) for SVG conversion, so I was expected some issues but the desire to publish a new version was stronger than to strong test it!

I noticed the M4 command to switch the laser on, like in the picture below. But after generating the code and saving it, I looked at the code and saw it had generated M3 instead for the laser On.

I also noticed in the code there is no return to home position code generated. So when it had finished burning, the laser stopped at the (bottom right) end of the last line.

M3 instead of M4 and missing of Go-Home at end are known. I'll fix ASAP.

There was also an off-set of X1 and Y2 mm's added when I loaded the file in.

I think the offset was not added by the code, but already existing in your original svg drawing. Check it!

It burnt the shapes in this order [...]

It is an issue or it is ok? I think that the code is generated as found inside xms-svg code, with few control on it by my side.

[StuartB4]

Hi Arkypita. Not sure about the off-set. All I did was to draw the shapes where they are and save the .svg, I did'nt take any notice of sizes or position, just made sure they were all inside the 40 x 40 mm square. I just had a look at the .svg file and marked the X1 Y2 position. So although it was'nt added intentionally it was ok.

It burnt the shapes in this order [...] It is an issue or it is ok? I think that the code is generated as found inside xms-svg code, with few control on it by my side.

Certainly not an issue for me, just an observation. As long as it burns correctly I don't think it matters that much.

[arkypita]

Did you remove Line To Line Tracing from version 2.9.0 ? It appears to be missing.

question removed? no changes to raster import in 2.9 configure with "pwm support" to see line2line option

[StuartB4]

Sorry. My mistake. I had PWM mode switched off in settings. That's why I deleted my comment.

[sanyats]

Здравствуйте. Все хорошо, открывает. Возможно сделать маштабирование векторов. Спасибо

[arkypita]

translated: Hello. All is well, opens. It is possible to do vector scaling. Thank you

Yes, as future option I will add scaling. For now I suggest to use inkscape to prepare the image at the required size.

[Luborson]

Hi, GOOD Job ! i have some question:

1. do you plan for filling of vectors ? (power depend for colour ?)
2. numbering of generated lines Gcode (ON/OFF)
3. every new append file have first move x0 y0, can by switchable to ON/OFF
4. same like 4, but for vectorized and filled picture, outline start again from x0 y0
5. now not work "start from specific line over green START arrow", startet again from first line, not from specified line, but ..File/Send From Possition is work well

i do test opening .SVG file exported from Corel DRAW X7 64b= works well

thanks

[MarceloFreitas028]

I also test the corel X7 SVG exportation and works well. I think that if you can develop the vectors fill it can be very useful. i export the same file filled and unfilled an this is the difference in the files.

unfilled:

Filled:

[arkypita]

1. do you plan for filling of vectors ? (power depend for colour ?)

I can't exclude. Maybe in the future but not for now. For now i suggest to use filling functions from your favourite SVG editor: https://wiki.evilmadscientist.com/Creating_filled_regions

[hayttle]

I can´t import SVG file.

[hayttle]

The same with new version.

[arkypita]

Can you submit your svg?

[hayttle]

SVG is not supported here. :(

[arkypita]

Zip and upload

[hayttle]

I found the error. The file was generated from Vectric Aspire with character coded accent and the software could not deal with this. I edited and removed this character "ã"

Tks,

[arkypita]

I was sure that the problem was in the file, but if you can share it (the one with issues) i can try to make the import procedure more strong and error tollerant

[hayttle]

Of course.

Another feature that would be great is can import dxf file.

Here it is. error_file.zip

Thanks and congratulations for the good job.

[arkypita]

After a little search i found that xml specification define that only some character ranges are allowed in xml (svg is a form of xml file). So your file is not a valid xml file.

I have tried to strip-out any character out of valid ranges prior to parse file content and now I was able to correctly read your error_file.svg

Future version of LaserGRBL will be more strong!

[hayttle]

I'm happy to contribute to the project. Nice job.

Do not forget to allow direct import of the dxf file, without having to convert to svg.

;)

[StuartB4]

Hi Arkypita. Just been trying SVG files again. I noticed when it generates the GCode it writes M5 twice at the top of the code. Not a problem, just wondered why it does it. Start Of Code:

G90 M5 M5 G0X39.6Y19.81 M4 S255 G1X39.58Y19.86 F250 X39.52Y19.92 X39.43Y19.97

The other thing I noticed is when changing the setting from M4 to M3 just before generating the GCode It still writes M4 in the code. Again, not a problem as it can be changed/edited in the saved GCode file if needed.

[kareemtawab]

Hi @arkypita

Just been using the awesome SVG feature. I do have some issue where after an SVG had finished engraving, the machine will go over the same paths several times with the fast speed and laser turned off before going into engraving the second path, third path and so on. I mean after every path, it does that before going to the next.

SVG file: 1.zip

[kareemtawab]

Bump. Any ideas?

[StuartB4]

Strange problem. I just downloaded your file, loaded it in to Inkscape and shrunk it down to fit my machine because it's only 40 x 40 mm's, saved it and loaded it in to LaserGRBL and it burned perfectlly.

For some reason though when loading it in it also showed the original size path in the window, shown in the image below.

After it burned ok it then started to go over the original size path but without the laser coming on.

As good as it's can be at this size.

[StuartB4]

Just tried it again by cutting the object from the original document and pasting it in to a new 40 x 40 mm document. Shrunk it again to fit the document and burned it again. This time it did it perfectly and just once.

May be worth a try to just select the object, cut it and paste it in to a new document the same size as the original.

[StuartB4]

Hi hk89.

Had a look at the file with Notepad++. There are 3 seperate large blocks of characters in the file. Looks like way too much for what it's actually got to do. I removed the last 2 blocks and re-saved the file. Could you just try this file on a piece of scrap when you have a moment. It worked on my machine perfectly and only did it once, as it's supposed to.

12.zip

[garthanstey]

I've just got into svg files from inkscape and tried loading them into lasergrbl . The images are great but I have the problem of getting them the exact size I need. Also I have built a jig at 100mm x and y offsets so that I can rapidly repeat burns. The option to resize and offset is not present for svg and i understand you are working on this. I'd love to know how things are going.

[RudiZc]

Hi. I noticed just a small issue using svg conversion: I'm using illustrator and if I use millimiters as unit, when I import my file the scale change and become bigger. I found that that scale matches with the dimensions of the image if I use "points" as unit in illustrator. So now, to have the right dimensions importing an svg file, i change my measure unit in illustrator from millimiters to points and consider that as millimiters.

[chrisgrul]

Hi. I noticed just a small issue using svg conversion: I'm using illustrator and if I use millimiters as unit, when I import my file the scale change and become bigger.

I'm having the same problem. It seems when using Illustrator, LaserGBRL considers mm to be pt and divides by about 2.83465. I had been dividing my measurements by this value but I like Rudi's suggestion as it is easier.

[svenhb]

Yes, usually scaling is 96 dpi (inkscape) but Adobe Illustrator uses 72 dpi.

[arkypita]

Hi all, and thanks for feedback about SVG support.

I'm aware of these problems, unfortunately fixing is not easy because the code I use to load SVG was not written by me and is a bit complicated to modify-understand.

Maybe in the future I will be able to solve them but at the moment I do not have much time to do it.

What I can suggest is to use inkscape to convert them from the original svg format (whatever the program that generated them) to inkscape svg. Open them in inkscape, set the document property to mm, adjust size and position of your job in page and save again.

What I've seen is that the SVG import routine work pretty well when the files are produced like that.

[StuartB4]

This is a bit strange. Since updating to version 3.0.14 LaserGRBL refuses to load .svg files, no matter which software I use to save them in .svg format, even Inkscape. I select the image then click the Create button and nothing happens, just a blank/empty window.

Any ideas why would be appreciated.

[arkypita]

Very strange! No changes to svg import code. Tried now, it work. Please test with this file:

disegno.zip

[StuartB4]

Thanks Arkypita. Thats fine, star and spiral. Seems to be when I import .png files in to Inkscape and save them as .svg it does'nt work. I must be missing something.

[arkypita]

I think you should vectorize them using inkscape "vectorize bitmap" tool. Raster image embedded in svg are not supported, neither in latest or older version.

[StuartB4]

Ok, Thanks very much. I must be getting old, I've done it before and somehow forgot. Working fine now.

[lbogaardt]

Hi Arkypita,

Thanks for your work on LaserGRBL.

I recently switched from EleksCAM to your software. I am hoping to adjust SVGs after I import them. In particular, I would like to be able to:

• Translate
• Scale
• Rotate

I understand you currently do not have a lot of time to work on this. Could you give us an update on the following two questions:

• Do you think you'll be able to add such SVG features soon?
• Do you still recommend using InkScape to change the original SVG before importing it into LaserGRBL? Or are there other easy work-arounds?

[Rybec]

For those with scaling issues using Illustrator: Please contact Adobe about this problem. Inkscape uses 96 dpi, because 96 dpi is the official standard for SVG. (This standard is inherited from XML, which inherits it from CSS. SVG uses CSS attributes for position, size, and such, and 96 pixels is defined as 1 inch in CSS, thus in SVG, 1 inch is canonically 96 pixels.) Adobe uses 72 dpi in Illustrator, which makes their files non-compliant with the SVG/XML/CSS standards. (One might reasonably say they are not even real SVG files, even though SVG parsers can load them mostly correctly.) No other software should have to go out of its way to support non-compliant software. This means the appropriate resolution to this problem is to get Adobe to make Illustrator compliant with the SVG standard, not to request other software, like this, to jump through extra hoops because some company that is too big to care about its paying customers won't comply with the official standards.

My solution is to use standards compliant software, like Inkscape, when I am doing any kind of work that is likely to be translated into real world objects. And to be perfectly honest, I find Inkscape significantly easier to use than Illustrator.

[arkypita]

Hi @Rybec I totally agree with you! SVG is an open standard or, as I call them, a "non standard standard".

Apart from a series of basic rules that establish the formal validity of the file, the SVG format is subject to different interpretations and implementations that vary from program to program, which have the freedom (since it is an open format) to add their own keywords and specific features.

Also to reply to @lbogaardt my goal is to be as compatible as possible with inkscape svg, because inkscape is free, easy, and open.

My SVG import routine comes from GRBL-Plotter project, which also has the possibility of importing .dxf and modifying the G-code. Both possibilities that I would like to import into LaserGRBL as soon as possible (which could mean months!). Until then my advice is to use inkscape to produce and modify the vectors (including the dxf which are loadable in inkscape and convertible to svg) in order to get the exact job you want to mark, including size and offset.

It is better to use inkscape v0.91 because it was reported that there are issue with SVG format generated by inkscape 0.92 when SVG generated by inkscape 0.91 is always good for LaserGRBL. I have not yet managed to get my head on this problem but I plan to do it in the next few days.

[arkypita]

Looking at the code of the project from which I took the SVG library I see that in the comments it says:

/*  GCodeFromSVG.cs a static class to convert SVG data into G-Code 
    Not implemented: 
        Basic-shapes: Text, Image
        Transform: rotation with offset, skewX, skewY

    GCode will be written to gcodeString[gcodeStringIndex] where gcodeStringIndex corresponds with color of element to draw
*/

This is exactly the cause of the problem reported here by @Ziggy2013

Looking at the code of file GCodeFromSVG.cs line 319 we can see that the code use only the param "angle" and ignore the rotation point.

if ((transform != null) && (transform.IndexOf("rotate") >= 0))
{
    var coord = getTextBetween(transform, "rotate(", ")");
    var split = coord.Split(',');
    if (coord.IndexOf(',') < 0)
        split = coord.Split(' ');
    float angle = floatParse(split[0]) * (float)Math.PI / 180;
    tmp.M11 = Math.Cos(angle); tmp.M12 = Math.Sin(angle);
    tmp.M21 = -Math.Sin(angle); tmp.M22 = Math.Cos(angle);

    if (svgComments) gcodeString.Append(string.Format("( SVG-Rotate {0} )\r\n", angle));
}

Now I'm looking for a trigonometric solution (I'm not very good with this) to implement rotation around a point other than 0.0

[arkypita]

It would seem to be easy, just replace the assignment of M11, M12, M21, M22 of a transformation matrix with the call to the RotateAt function.

if ((transform != null) && (transform.IndexOf("rotate") >= 0))
{
    var coord = getTextBetween(transform, "rotate(", ")");
    var split = coord.Split(',');
    if (coord.IndexOf(',') < 0)
        split = coord.Split(' ');
    float angle = floatParse(split[0]);// * (float)Math.PI / 180;
    float px = split.Length == 3 ? floatParse(split[1]) : 0.0f;
    float py = split.Length == 3 ? floatParse(split[2]) : 0.0f;

    //tmp.OffsetX = px;
    //tmp.OffsetY = py;
    //tmp.M11 = Math.Cos(angle); tmp.M12 = Math.Sin(angle);
    //tmp.M21 = -Math.Sin(angle); tmp.M22 = Math.Cos(angle);
    tmp.RotateAt(angle, px, py);
    if (svgComments) gcodeString.Append(string.Format("( SVG-Rotate {0} )\r\n", angle));
}

Tested with file pent with vines here and now is imported correctly. I am going to do more test.

[Ziggy2013]

Thanks arkypita for following up on this issue.

An explanation of how to handle rotation about a point other than the origin is here on youtube-

https://www.youtube.com/watch?v=nu2MR1RoFsA

[arkypita]

Release v3.1.4 (available as pre release for test) should fix the issue of rotation about point. https://github.com/arkypita/LaserGRBL/releases/tag/v3.1.4

Let me know

[Ziggy2013]

Hi arkypita

I think the rotation about a non origin point is now working.

However it appears there is still an issue with how rotate is handled.

I have attached three test files;

1) an svg file "test_stencil_brd.svg" which been generated out of a PCB program. This file renders correctly in Inkscape 0.92.3 It does not render correctly in LaserGRBL. You will see the difference in rendering affects just one part of the image.

2) The same svg file "test_stencil_brd.svg" has been openned in Inkscape 0.92.3 then simply saved. This saved file "test_stencil_brd_saved.svg" renders correctly in Inkscape 0.92.3 but not in LaserGRBL. If you look at the xml contents of file 1 and 2 they are very different. However I think the reason LaserGRBL does not render correctly is the "rotate(-270.000000)" statement in both files "test_stencil_brd.svg" and "test_stencil_brd_saved.svg" is not handled correctly.

3) The third file "test_stencil_brd_ungroup.svg" is the result of just Inkscape "ungrouping" the content of file 1. Both Inkscape and LaserGRBL now render this file correctly. If you look at the xml contents of this file you will see that Inkscape uses rotation about a non origin point. This translation type now appears to work correctly in LaserGRBL 3.1.4.

I hope this information and test files are helpful. All of these three files should render the same in Inkscape 0.92.3 and LaserGRBL. They should also render the same in earlier versions of Inkscape but I haven't been able to check that.

I can see the svg import code is very complex. If you need further testing please let me know. I appreciate the massive effort you have put into LaserGRBL. It's a great app - thanks.

Regards

Ian

On Wed, Apr 8, 2020 at 9:07 PM arkypita notifications@github.com wrote:

Release v3.1.4 (available as pre release for test) should fix the issue of rotation about point. https://github.com/arkypita/LaserGRBL/releases/tag/v3.1.4

Let me know

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/arkypita/LaserGRBL/issues/451#issuecomment-610895378, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZMN3HBK4KWCLSVKGHOF5TRLRLGVANCNFSM4FYEXQIQ .

[arkypita]

Mail attachment does not work in github. Can you zip and load via github web page, or send them to info@lasergrbl.com?

[Ziggy2013]

Hi,

Just sent the zip file to info@lasergrbl.com

regards

Ian

On Wed, Apr 8, 2020 at 11:00 PM arkypita notifications@github.com wrote:

Mail attachment does not work in github. Can you zip and load via github web page, or send them to info@lasergrbl.com?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/arkypita/LaserGRBL/issues/451#issuecomment-610944835, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZMN3BCKYMZ64DHP4ZEIKTRLRYOLANCNFSM4FYEXQIQ .

[arkypita]

Thanks @Ziggy2013 In addition to the lack of "rotate at point" the problem seems to be more the ability to manage multiple transform operations (rotate translate) in the same transform attribute. In particular, the order in which these transformations are indicated because the order in which they are performed is important (while the library I used ignored this detail).

Now it should be fine with your files and, optimistically speaking, with every file. Let me know

https://github.com/arkypita/LaserGRBL/releases/tag/v3.1.5

[Ziggy2013]

Hi arkypita,

v3.1.5 correctly renders all three test files - it's perfect - thanks.

I agree the root cause issue is more about the order of thransformations. There is some confusion about how the W3C specification defines the order in which transformations should be done - the correct order is from right to left but the specification does not make it easy to understand this.

There is an interesting discussion about the transformation order is here

https://stackoverflow.com/questions/18582935/the-applying-order-of-svg-transforms

regards and thanks for fixing the problem

Ian

On Thu, Apr 9, 2020 at 11:55 PM arkypita notifications@github.com wrote:

Thanks @Ziggy2013 https://github.com/Ziggy2013 In addition to the lack of "rotate at point" the problem seems to be more the ability to manage multiple transform operations (rotate translate) in the same transform attribute. In particular, the order in which these transformations are indicated because the order in which they are performed is important (while the library I used ignored this detail).

Now it should be fine with your files and, optimistically speaking, with every file. Let me know

https://github.com/arkypita/LaserGRBL/releases/tag/v3.1.5

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/arkypita/LaserGRBL/issues/451#issuecomment-611541309, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZMN3BEKEGE526AUBLG7NTRLXHVZANCNFSM4FYEXQIQ .

[arkypita]

Memo: viewbox issue https://github.com/arkypita/LaserGRBL/issues/1126

[lojzik]

Would it be possible to generate PWM and multiple passes count on elements from some element attribute (opacity, color, stroke-width, etc.)?