Open abey79 opened 1 year ago
After thinking—and discussing—about this, I'm strongly leaning towards forgoing entirely a hierarchical metadata organisation:
I'm still trying to figure out a good strategy for metadata handling, and it occurs to me that there might actually be no benefit to vpype for metadata to be hierarchic. In other word, what I'm considering is to have only path metadata, and skip trying to maintain layer- or/global-level metadata, and dealing with the related hierarchical relationship (e.g. if path X doesn't have stroke-weight but it's parent layer does, then it should inherit it's parent's stroke-weight).
Of course, reading SVG absolutely must handle attribute hierarchy properly, but then the resulting metadata can be entirely flattened into the paths. Likewise, exporting SVG should also try to extract common subsets of metadata within each layer so that the corresponding attributes are set at the layer/group level rather than in individual paths (in order to limit file size). Finally, some commands will definitely want to operate at the layer level (e.g. the current color --layer 3 red) . In such case, it will have to iterate over the layer's paths and set the metadata for each of them, and it's effect will not affect subsequently added paths (e.g. color red and line 0 0 10 20 would no longer be commutative as is currently the case—this could possibly be addressed by maintaining layer-level "default values").
It feels like the price to pay for this is very reasonable, in regards to handling the complexity of the hierarchical relationship. A path can truly be self-contained, without the need to know which layer or global context it is attached to in order to know what its own color or stroke weight is. Much code can be simplified with this approach I believe.
My current plan is as follows:
DocumentMetadata
(e.g. page size), LayerMetadata
(e.g. name), PathMetadata
(e.g. stroke width & colour).Option
field (an empty layer name isn't the same thing as no name).DocumentMetadata
and LayerMetadata
include a default_path_metadata
field that cascades to paths when relevant.For example, merging two layers involve the following steps:
None
.default_path_metadata
has a special treatment: the difference after merge is cascaded to the corresponding paths' metadata, such that the overall operation isn't lossy on the "resolved" path attributes.
I'm still in the process of sorting that out.
There are at least two design goals:
Maybe a
HashMap<_, Cow<_>>
? Or immutable data structure from theim
crate?