TinyVG / specification

The specification for TinyVG. This is the central authority for the file system
https://tinyvg.tech/
MIT License
246 stars 7 forks source link

[Proposal] Add a new command "tag" for embedding arbitrary data #18

Open neinseg opened 2 years ago

neinseg commented 2 years ago

Something I often do with SVGs is to have a "master SVG" that has named objects and groups, then selectively change the style of some of these groups during rendering. Thinking about TinyVG use cases, imagine a "Checkbox" SVG. It might look something like this:

<svg>
<rect ...>
<path id="checkmark" d="..." fill="green">
<path id="cross" d="..." fill="red">
</svg>

The renderer can then select any of the styles by rendering with an override of `fill="none" for one of the IDs.

I don't think that explicitly specifying this type of CSS-like behavior makes sense as part of a format like TinyVG. However, it would be nice if it would be possible to uniquely identify individual elements or groups of elements in a TinyVG file from the outside.

One way of doing this could be to have "id start" and "id end" commands in between graphical commands. These would have no effect on the actual graphical rendering and can be ignored during rendering since in contrast to SVG groups they do not change graphical state such as style or transform. IDs could be variable-length strings, which would not make implementing a parser worse since there are already variable-length integers and lists anyway. Example TinyVG file structure for the checkmark example above:

[header]
[color table]
<outline rect ...>
<start id "checkmark>
<fill path ... color=green>
<end id "checkmark>
<start id "cross">
<fill path ... color=red>
<fill path ... color=red>
<end id cross>
[EOF]
ikskuh commented 2 years ago

I accept a slightly modified variant of this:

A new command tag(string) will be added. There will be no specification about how the tag content is formed, it is just an arbitrarily sized byte stream that can be used to identify or control custom renderers. Tags can be ignored by conforming renderers.

neinseg commented 2 years ago

I think that's a really neat solution.

Evrey commented 2 years ago

Something like this would also be useful to e.g. have an entire icon theme in just one image file. Then you pick the group of the icon you need, which could itself build on top of some base icon. I can imagine this being useful for especially websites, giving you all your icons in just one request.

ikskuh commented 1 year ago

As it's requested right now:

The new command will be called tag and has command index 11. The layout will be like this:

command-name:  "tag"
command-index: 11
layout:
  length: varuint
  data:   [length]u8
Evrey commented 1 year ago

Nice!

What’s the spec on the u8 payload? UTF-8? /[a-zA-Z0-9]+/? UUID? Any random blob of no assumptions?

ikskuh commented 1 year ago

The last thing:

data is an arbitrary blob without assumptions for now. As it's an application specific command so all implementations are free to ignore the blob.