Create Read/Write API.

[tatarize]

For vpype-embroidery I made eread and ewrite as commands. These share considerable overlap with read and write which are already in places multiple format commands with svg and hpgl. I should, in addition to various types of processors, be able to just raw encode readers and writers that register some formats and let me piggyback on the non-plugin read formats.

For example, if I wanted to make vpype-dxf to load dxf files. This is pretty easy for me, I'd grab my code that converts dxf files into svgelements paths and slap it together. Suddenly you could do pip install vpype-dxf and you'd get access to new commands dread and dwrite? Without a more complete reading and writing API, these commands would have to proliferate.

Somebody gets a great idea for writing pdf files since they can store some nice vector data within them and they are easy to view. So people can do a mockup of some work they are offering. So you put-together a solid pdf output thing called pwrite?

[abey79]

As I said before, my intension is to regroup all reading and writing into the read and write command, primarily using file extension to decide on the format. I'm thus considering vpype-embroidery's eread and ewrite a temporary solution and I definitely plan on integrating them at some point. The nature if this integration is an open discussion. Some kind of extension mechanism would sure be nice but it's maybe to soon to over-engineer. Regardless, I would like to take the time for a few things to settle before jumping on this, including:

• possible evolution of vpype's data model (Classify lines by colour into layers (read) #35)
• general requirements for embroidery
• particular requirements for a nice pyembroidery

[tatarize]

Well, looking at the plugin architecture, you'd might even want even the core plugins to be spun-off so people could uninstall/not-install-in-the-first-place the svg and hpgl aspects within read and write, and register the vpype organization to house such things. Perhaps my ideal version doesn't contain scipy, etc. Maybe I'd just like to only use vpype-embroidery and do some basic reading and writing and converting of embroidery files and that's everything in Vpype's pipeline I care about for some one-off single purpose use thing.

I mean there would certainly be some specialty reads like if I read a PNG file, into vpype I would want/need Pillow to do the actual file reading and potrace to convert the different layers into vectors. Obviously in that case some of the read stuff would be highly specialized like -turd_size (actual name in potrace) and these wouldn't really apply to other read or write functionality. But, adding in iread for images might get a bit excessive.

You don't really need to overbuild the stuff, but define the outlines for what correct usage looks like. You can change the internals all you want if the interactions for the plugins are the same. As is vpype-embroidery needs a revisit when ever this issue gets resolved. If I design a vype reader what does that look-like to the plugin. How fancy that stuff gets, meh, that's a later job.

---

API isn't finished code, it's the methods and nature of the interactions your software has with others. Do I define a hook that asks whether my reader deals with a particular extension and mimetype? Do I return the data if I managed to read the data or false if I don't deal with that file type? If you made the ability to read and write svg and hpgl as their own plugins how would they interact with the core read and write stuff?

[abey79]

Honestly, I'm the bulk of my user base cares little about the possibility of uninstalling/installing plug-ins and such and does not know what scipy is, let alone has an opinion in installing it or not. Instead, an installer which, ideally, includes everything is amongst the most wanted feature (#66).

There are infinite ways of converting raster image to vectors, eg:

• hatched, which one of my very early plotter-related code I eventually converted to a vpype plug-in)
• a tracing plugin that would generate paths when possible (as opposed to filled shapes) would be an absolute killer
• there are a number of TSP-like algorithms out there that I'd like to integrate as plug-in at some point

To me, these should each have their dedicated command as opposed to being integrated to read. In essence, read should be faithful to the input file (within the limitations of vpype's data model). In an ideal world, vpype read input.XXX write output.XXX would be equivalent to identity for any supported XXX format. Clearly, bitmap to vector commands are out of this scope.

When the topics I listed in my previous message gain in clarity, a non-modular integration of pyembroidery in the current read/write code should be just fine as a first step and I can't really foresee a need for further functionality on this front. If such should emerge at a later stage, it won't be too late to adjust the architecture.

[tatarize]

I could see a couple having a couple other data types in your model. Rather than just a point list of lines, you could also have a 4 wide list point values that correspond to Cubic Bezier curves. Or an MxNx4 (uint8) chunk that's really just a bunch of raster values. You'd need to keep it limited and have plugins register themselves to deal with just the one type of very specific data. Then you could read a raster and then process it in a bunch of different ways. And you'd either have the other registered plugins not get that data when it's handing out data, or throw an error if it gets the wrong type of data. You sort of have other datatypes already you just hide it by making commands big and do a bunch of work. I think in efill the data gets turned into about 5 different structures. Though keeping it simple is likely for the best.

I just kinda want read and write to work more directly on embroidery with the plugin.

Other than that I think there's maybe a need for satin stitch code, and the fills should be the fill color but whatevs. It's a good project and well done. Just some stuff in the embroidery plugin didn't really have a home, so it feels kind of incomplete.

[abey79]

I'm revisiting this issue following the discussion in vpype-gcode (plottertools/vpype-gcode#2).

The direction vpype is taking is now to strip write from any layout capabilities (mainly --center and --page-size + --landscape). The recent addition of the page size in the pipeline (#97) and the new layout command (#168) are much better alternative to using write's layout options. As a result, it becomes much easier to have multiple commands for different output formats, because the scope is reduced to strict file writing, at the exclusion of any layout functions. There would thus be minimal functional overlap between various "export" functions.

As a result, I'll probably be happy to integrate a version of gwrite as a standalone command, when the config stuff and other things are settled (and we can find a command name that reflects the actual flexibility of such a command!)