New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document ink/stitch XML namespace #202
Comments
discussed in #200 |
@kaalleen can you create the placeholder page in that adress? Point it to this issue ;) |
Sure! |
@kaalleen Awsome :) |
There was desire to convert between SVG <-> PES formats by frno7. It suffered from a couple problems. Namely that it was missing an engine for the SVG files. Internally PES files have objects like CEmbRect or CEmbCirc and a bunch of properties set like what kind of fill that object has (see PES block description) even if the code wasn't underneith such a thing fully, a robust description of a qualified namespace within svg would actually make that project entirely feasible (It also suffered from the problem that nobody anywhere could find files with those internal structures existing in the wild. All PES files basically only ever contain stitches blocks.). You could still plan out the namespace even if inkstitch didn't actually implement all the given features in the namespace. It would actually be easy from there to parse a PES file and transcode it into SVG if you could say things like this SVG object here has the following stitches applied to it. That's exactly what PES do, but it would be in a much more open and readable format. Done nicely enough, you'd be able to use the namespace without inkstitch at all, or let programs like embroidermodder use the same format. Several of my embroidery programs read svg files natively, if those files had stitching information, I could read that info too so long as they complied with some kind of standard. As is, if I save an SVG without any specialized data I lose things like the actual threads that file used. When I load them back up the threads for those particular layers say "SVG Color #494930" or whatever because even if I got the thread from an entirely qualified thread data filled with metadata, I could only save the color itself and not the thread and associated metadata. It would be a lot easier for people if you could write an SVG file, that says draw a circle here, add this fill to that shape. By simply writing that that shape has that fill. Then run it through an engine that compiles it and outputs to .dst or some such thing. Such things don't actually need inkstitch, they would only need a kind of standardized svg namespace. |
Ok, I created a list of the Ink/Stitch attributes and metadata trying to fullfill our intensions for the namespace webpage. Since I am not a programmer, I am not sure how to correctly do it. I would really appreciate if someone else could have a look at it and do some corrections. Update: |
The ink/stitch XML namespace is http://inkstitch.org/namespace. XML namespace arne't required to have any actual content at the namespace URL, but let's put some content there! For starters it can just be a placeholder. Ultimately, it should be a living document of all metadata tags and embroidery attributes.
The text was updated successfully, but these errors were encountered: