Optimized SVG diagrams

[davidlehn]

The diagrams in the spec are basic SVG but very large files:

$ du -b diagrams
1735778 diagrams

A pass with SVGO can cut those sizes down quite a bit:

$ svgo -f diagrams -o diagrams.min
$ du -b diagrams.min
1003470 diagrams.min

Not sure what SVG editors are doing that results in such large files. I'm guessing just non-optimized font to path conversion? It's worth considering using optimized SVG for published specs. They do get compressed and cached, but still good if SVG files were smaller to begin with.

[chaals]

The SVG is super-scrappy and one of the things it is doing is using paths instead of <text> elements, which is why it's massive. Rewriting some of these by hand could be done pretty quickly, (and in the microdata draft spec are some hand-written node diagrams with clean code we could quickly take and adapt as desired). But redoing others in an editor that produces reasonable lightweight SVG is probably the only feasible way to fix them.

Optimising the ones we can't directly replace with cleaner code does make sense.

I know how to do this but don't have a lot of time available :( I might see if I can get a little help from someone and work through at least some of these.

In any event, such changes would be purely editorial in terms of the spec (although we might e.g. improve the accessibility of the diagrams, as well as their size).

[swickr]

It would be a big improvement if the diagrams inherently became more WCAG 2.1 compliant as well.

[kdenhartog]

Hmm, not sure what we want to do with this one now that some of the latest SVGs have been created manually in #786

We were able to improve them to be more WCAG 2.1 compliant as I understand it, but weren't able to update our tooling to automate this (and address the original concern of shrinking the size of these). I'm not familiar enough with the automated tooling we're using to generate some of these, but agree with @brentzundel assessment that this should be addressed in V1.1. I'm going to leave this one for now until I get a chance to talk with others (Thinking @msporny may be able to help here) about the best path to address the best way to handle generating SVGs in an automated way which is WCAG 2.1 compliant and optimized in size. If anyone has some suggestions drop them here and I'll do some more investigation on what needs to be done to address this.

[chaals]

Ah, hadn't remembered this.

Yeah, making the SVG more accessible (I wouldn't claim WCAG compliance yet and I know there is more to do, but we're somewhere down the path, with the most complex pair of diagrams) also makes them much smaller files.

I think we should close this for now, knowing that there is more work to do. In terms of an automated process that maintains code quality and accessibility, I don't know the state of the art, but something that doesn't break existing source code is pretty much a baseline requirement - and from there, I fear that we will still need manual final editing for the near-term future. Perhaps we should ask the SVG group for info?

Repeating the process for other files should help (and I could readily copy a fair bit from the W3C draft on microdata, for which I generated some of the graph diagrams by hand).

[kdenhartog]

I wouldn't claim WCAG compliance yet and I know there is more to do

Good to know, thanks for clarifying this. I'm not very familiar with the Accessibility requirements quite yet.

I don't know the state of the art, but something that doesn't break existing source code is pretty much a baseline requirement - and from there, I fear that we will still need manual final editing for the near-term future. Perhaps we should ask the SVG group for info?

Sounds about right - I plan to look into what we might be able to do to address this. If it is manually updating things for now, I can report back for that on this issue and we can decide if we want to just close it. More to come on this topic.

[kdenhartog]

I'd suggest for this one to move forward, that someone with the original images should post a link to this so that we can regenerate the ones that @chaals hasn't updated for us already.

[iherman]

The issue was discussed in a meeting on 2021-10-06

• no resolutions were taken

View the transcript

3.6. Optimized SVG diagrams (issue vc-data-model#721)

See github issue vc-data-model#721.

Brent Zundel: Kyle, can you give us an update here?

Kyle Den Hartog: For this one, I believe there is some work in progress for getting these updated;
… the problem is the way we are updating these SVGs I don't think went all the way to meeting it.
… There are some optimized, some unoptimized. I don't have the original images that were used to generate.
… I don't know how Chaals was generating them...
… Another issue is to make it more accessible - those two could probably be combined and done at the same time.
… If someone has those images, please post them

[msporny]

@davidlehn please optimize all of the SVG diagrams and raise a PR that makes that update.

The WG will then describe all the SVG images using the details element in the HTML to make all the images accessible.

[iherman]

The issue was discussed in a meeting on 2021-11-10

• no resolutions were taken

View the transcript

5.2. Optimized SVG diagrams (issue vc-data-model#721)

See github issue vc-data-model#721.

Brent Zundel: this has been partially addressed already.

Manu Sporny: this is difficult. Make the diagrams both optimised and accessible; these are almost mutually incompatible.

Ivan Herman: if you optimise, making them less accessible will be a problem for you.
… you can add metadata.

Ivan Herman: See an example for a11y svg.

Ivan Herman: you still have to give an image description in the text.

Manu Sporny: we should optimise the svg diagram and then write the description of the diagram. If we can do this by year end then it will remain v1.1 otherwise it will have to defer to v2.
… can we assign this to David Lehn from Digital Bazaar.

[chaals]

The images that I worked from were far larger in code size than the resulting images I produced. If your goal is merely to optimise for size, then you're working with the wrong tools from the get-go. Adding a decent layer of accessibility to the base that I got to is not going to make it anywhere near the size that I started working with.

You can also optimise, per spec, by compressing with gzip. Again, the approach I took will give more benefit by doing this.

Happily

Make the diagrams both optimised and accessible; these are almost mutually incompatible.

Is not correct if the specific optimisation you want is for code size. There are many other possible optimisations (e.g. self-describing images) that also work out pretty well alongside improved accessiblity.

[msporny]

What is the current status on this, @davidlehn?

[iherman]

The issue was discussed in a meeting on 2021-12-08

• no resolutions were taken

View the transcript

4.1. Optimized SVG diagrams (issue vc-data-model#721)

See github issue vc-data-model#721.

Manu Sporny: I just requested as status update from Dave Lehn on that one..

[chaals]

@davidlehn I'd like to know where this is at. I am happy to spend a bit more time on some of these images at the end of the year.

[davidlehn]

It looks like the base size of the diagrams has gone down since this issue was opened. The files are now 1062712 bytes.

SVGO has lots of options. The default removes desc and title. I'm unsure if that effects any user agents that might display that data? Those were added for a reason I assume. Disabling those plugins adds back another 2k or so. Keeping newlines and a single space indent adds a few more bytes, but makes files readable.

I'm not sure how these are created, but I'm guessing the source files should probably be preserved? That would make this optimization best as a build step. But with compression on the current files, maybe this isn't even worth it?

$ du -b diagrams* | sort -n
621215  diagrams-default
623793  diagrams-desc-title
625668  diagrams-pretty-compact
629283  diagrams-pretty
1062712 diagrams

See the output and the config file you can fiddle with in #851.

[msporny]

I'm not sure how these are created

We use Google Draw to generate the SVG diagrams.

But with compression on the current files, maybe this isn't even worth it?

Yeah, seems like it's not worth it.

@chaals, this, coupled with the fact that we moved descriptions out into the spec, I think we're done here. Please let us know if you disagree.

I'm marking this with a "pending 7 day close" tag. We'll close this unless there are objections.

[chaals]

The SVGs that have title and desc are ones I have regenerated - they are essentially re-written by hand (but I can easily re-use pieces, once I have made them). That significantly reduces the size (and incidentally increases the benefits of compression).

When I have time later in the month I will happily do this for the images I haven't yet worked on.

I'll look at the doc over the next few days to answer @msporny but I suspect I am happy with where we're at.

[iherman]

If you use svgo: be careful that, by default, it removes metadata, title, or desc.

[chaals]

@iherman warned...

If you use svgo: be careful that, by default, it removes metadata, title, or desc.

Yup. @davidlehn is also aware of that, so I think we're good. And on the stuff I do by hand, it's very clean anyway (I'll wear gloves, just to be sure ;) ).

[msporny]

When I have time later in the month I will happily do this for the images I haven't yet worked on.

Just to make sure you don't end up doing a bunch of work that we then (accidentally) overwrite... We generate the SVGs from Google Draw. Every now and then, we go in to modify images and re-generate those images from Google Draw... if anyone does that, we destroy your hand-optimized versions (thus, accidentally destroying the work you've done). I don't think anyone in our group knows how to effectively hand-edit SVG, thus the conundrum. We need to make sure the individuals in the WG can continue to refine the images, and to do that, we point them to Google Draw and "Export to SVG".

@chaals, my suggestion is that you don't hand optimize the images -- we fixed the a11y considerations by describing the images at length in the spec (and not in the SVG).

[brentzundel]

Closing per: #851 (comment)