`read` should disregard full transparent elements (both fill and stroke)

[tatarize]

Should it tho?

Also, there's a straight 'opacity' value on objects that is unrelated to their fill or stroke. They didn't disable the rendering, they just made it invisible, it's still there. You don't take color into account other places, why should invisible colored thing suddenly be wildly different?

[abey79]

My position is that it should so long as #35 is not implemented because IMO the primary aim of vpype is provide a (visual) render as faithful as possible (within the constraint of plotter stuff). That said, given the lack of popularity of the present issue (you are not the first I'm arguing with on the topic 😃), there is a decent likelihood that it will rot until #35 is addressed.

[tatarize]

I must be missing somebody about #35, what about it takes any time to implement? I debated affixing a color object directly when I did vpype-embroidery, it seems like you'll get the same objects passed through the pipeline. I sort of wanted to be able to call eread and the later ewrite and not lose the colors which is currently a requirement. I didn't want to mess with it if I was going to have to conform to #35 later but I don't see how a dict of metadata to follow the objects around couldn't be implemented in adding a dictionary and defining best practices somewhere.

[abey79]

what about it takes any time to implement?

Nothing in particular. I just need to get around to doing it, and it must be done carefully because any modification to the core data model may have implications on most of my, and other's, code base.

[tatarize]

You're not modifying the API in breaking ways. You're adding a some functionality to it. Usually that's always safe and the real risk is you can't take it back after it's changed remotely as easily as you added it. So if you add the API wrong it gets set in stone and correcting any errors become intractable.

So you can't call your color .color and then switch it to .stroke later on, or if you generalize all your metadata into a dictionary and say 'color' is an int in (0xAARRGGBB formatting) and later permit that to use a Color class, you can't really change that stuff later. But, initially adding stuff won't break things. So long as the new API is a superset of the old API, all plugins still followed the same API they just never set the colors. It's like everybody used the API but didn't use the aspect of the API that was invented later.

I'd prefer a dict object just attached to the layers, and one attached to the document, so I could dump most the stuff in there from loaded formats. SVG has a bunch of layer properties and stuff that could be dumped in there and some things like Desc and some other metadata. There's some document level metadata in embroidery formats (keywords, author, title), pyembroidery goes to long lengths to preserve that stuff, it would be a shame to not have access to it, even if it's just for the ewrite (or modified custom write at the end). Also, embroidery has thread-level metadata, so in addition to color of the thread you have the weight, manufacturer, pantone, description. Though if you have 1 color per layer, this is pretty easy to add to the layer-level metadata.

It's usually best to make a method that works broadly but correctly. The problem isn't adding the stuff, it's changing it later if you did something wrong, or made an API that didn't cover wouldbe eventualities. svgelements for example has processed values for .stroke and .fill and .strokewidth but also .values['stroke'] is still there in the unprocessed form and not as a svgelements.Color object.

But, if you have #35 working, you could just add in a command or flag to strip transparent objects.