SVG Metadata for Power and Feed Rate

[Rybec]

Is your feature request related to a problem? Please describe.

One day a while back, I was trying to cut a sample grid to determine how my cutter handled a particular material. I put each grid element in a separate file, then I used "Add File" to load those after the first, and entered the settings for them. Unfortunately, the grid was 5x5, so I had to do this with 25 files, and even fairly infrequent typos or just forgetting to change a setting caused me to have to start over entirely enough times to be very frustrating and waste a lot of time

Describe the solution you'd like
SVG files are nothing more than XML in a particular format. I've messed with SVG as text myself, on a few occasions even writing software to generate SVG. It wouldn't be very difficult to check an SVG file for a particular metadata tag after loading, to find a power and feed rate setting. If the field doesn't exist, continue as normal. If it does, then pre-populate the "Target image" settings box with specified power and feed rate. This allows the user to include default feed rate and power settings in the SVG file, and it also allows the user to change them when cutting, if desired.

I do realize that not everyone wants to manually edit the SVG file to add this, and Inkscape doesn't include a simple way to do it (as far as I am aware...), but for power users who would really benefit from this, it wouldn't be too much for them to add the metadata themselves.

EDIT: Due to someone not bothering to read the full thread before commenting, I find it necessary to strike out the above paragraph, because Inkscape does have ways to add metadata fairly easily. See the comment directly after this one for details. Inkscape has means to add document and object level metadata, without having to directly touch the SVG at all.

Describe alternatives you've considered
I've tried LaserWeb, which keeps track of all of the files loaded and allows specific settings per file that can be changed after loading. Even that is tedious though, if I need to load several files at a time. Additionally, for some reason LaserWeb doesn't work with my current cutter (I think LaserWeb times out before GRBL on my cutter responds, but that's not relevant here).

Additional context
It's possible that Inkscape does have a way to add this sort of metadata. I can look into this and post a reply in this issue, if I find a way.

EDIT: Inkscape does indeed have ways to add metadata that could be used for this. See the following comment for details on how this is done.

[Rybec]

Ok, you can add metadata in Inkscape, but it's limited to a handful of specific fields.

Files > Document Properties has a Metadata tab. The "Description" field could have text like "feed: 500; power: 1000" to inform LaserGRBL of the default settings. (Other formatting could be used, if it is easier.)

Alternatively (or perhaps also), the "Object Properties" panel has a "Description" field, if instead you wanted to allow the creator to give each path its own setting. Maybe add a checkbox to the "Target image" field, that will override the individual object settings and do the whole image with the specified settings, since it's not really reasonable to ask the user for settings for every object to verify.

[Nemecsek]

Editing SVG is a pain in the a... Not everybody would like to go through it.

Why not to use line colours instead?
Any 24bit colour can encode a number of parameters, i.e. red quantity 0-255 could be the speed (X50 mm/min), green 0-100 the power (% of max). Blue is free for whatever else you need to code.
It would be easy to precalculate very precise settings for power and speed.

[Rybec]

In the comment right before yours, I described how to add metadata without directly editing the SVG. No offense intended, but please don't comment if you haven't read the previous comments, as it just clutters things up and is frankly quite rude.

Now, the colors idea isn't terrible, but I suggested using metadata for a reason. Metadata is ignored by any program that it isn't meaningful to. Other laser cutting programs often use color for layering or for allowing the user to set parameters on a per color basis at the time of cutting. (I've done this with LaserWeb, but for some reason it doesn't work with my new laser cutter.) This creates a pretty serious conflict if LaserGRBL does it differently. For example, say I want some lines engraved with only slight differences in feed rate and power (I've done at least one project where I needed this). Now I've got an SVG with colors that look very similar, so similar in fact, that it would be hard to differentiate visually. That's a serious problem, if someone uses different software from LaserGRBL with my SVG. As someone actively planning and working on open source projects involving laser cutting, that's a serious problem for me and anyone using my work. It would be significantly better for me to have to just edit the SVG directly to add metadata than to try to encode this in the actual image data itself, and I don't even have to go that far, because Inkscape provides ways to do this without directly editing the SVG. Similarly, what happens if I download someone else's SVG, that's color coded for the software they use? That's going to be a bad time for me, isn't it?

Also, no. Just because it's easy for you and I to calculate the right values does not mean it's easy for everyone. Sure, most people using laser cutters have an engineering mindset and can easily handle the math, but there are plenty of casual hobbyists and fresh new makers who can't. Much better to use metadata that can easily be entered without having to directly edit the SVG, since Inkscape already provides mechanics for that. (And better yet, if this feature is added, maybe someone will write a simple plugin for Inkscape to make it even easier to add the metadata.)

On the surface, it sounds like a good idea, but color already has meaning in more contexts than it should. Adding yet another layer of confusion on top of that is a terrible idea. Inkscape already provides a fairly simple way of adding per document and per object metadata that does not require touching the SVG directly and that would allow for much more human readable metadata to be added, without touching the actual image data. No need to overcomplicate things.

[Nemecsek]

If I sounded "rude" to you, my fault. I didn't mean to be.
And I definitely read what you wrote: as English is not my mother tongue it is possible I didn't comprehend fully what you meant or understood the implications of my idea.

I've been a programmer for 35+ years, and I'm used to incompatibilities among similar softwares. They are the rule, not the exception.

I don't use Inkscape most of the time: I generate my own SVG engraving images in Processing (java-like language to generate artistic images). I'll continue to use colour because it is the only thing I can do in this environment, and I'll write a SVG converter where colour is transformed in metadata as soon as this function is implemented. Piece of cake

[Rybec]

No worries then! I'm in the process of learning Japanese, and I understand how communicating in a second language can be!

And yeah, software incompatibility is basically just how things work. Writing a color to metadata converter is a great idea, to cover software that doesn't provide a way to add metadata. LaserGRBL seems to focus mainly on maintaining compatibility with Inkscape, probably because Inkscape seems to be the only image editor that adheres closely to the SVG standard. Adobe doesn't even use the standard DPI, which is a serious problem when trying to make physical products from SVG images. If other software followed the standards as strictly as Inkscape, it might make sense to worry more about making the feature accessible in everything. The problem with color is mainly just that it can have its own independent meaning, so basing something like this on color would make this feature problematic for a lot of people who already use color to mean something else. Cutting parameters are fundamentally metadata in terms of SVG images (because they aren't part of the actual image data), so it makes more sense to make them metadata. Also, if color is used, then LaserGRBL would have to assume every path had embedded cutting parameters, even when that wasn't intended by the user. With metadata, if the path/file doesn't have them metadata, then LaserGRBL knows when no parameters are provided. Not a huge thing, but I could see people (like me) accidentally accepting default parameters that weren't intended.

Some people would even argue that cutting parameters don't belong in the file at all, because they vary from machine to machine. This is why color is often used to differentiate paths that need different parameters, and then you manually enter the parameters on a per-color basis in the cutting software. I would argue that for scale production, where you know the file is going to be used on the same machine every time, it makes perfect sense to embed the cutting parameters in the cutting data. (And since I would like to eventually sell laser cutting services, this could save me a lot of time manually entering parameters and avoid expensive mistakes in the long run.)

I really hope this feature does get implemented. I would do it myself, except I don't know C# very well, and my very limited experience with it has already caused me to absolutely hate it. I just don't have time to learn a language I don't ever want to use to add a single feature to one piece of software. If LaserGRBL was in Python, I would totally do it myself. (Hmm, I wonder how hard it would be to write a Python port of LaserGRBL... I wouldn't need to fully learn C# to do that...) On top of that, I mainly work in Linux, which throws another wrench into the gears in terms of compiling and debugging. (I currently run LaserGRBL in Wine, and sometimes it's a little buggy there, so I would never know whether the bug was in my code or in Wine.)

But yeah, a color to metadata converter would be trivial to write. That would be an excellent solution if this feature does get implemented!