Hacker News Reader

Comment by zimpenfish | Hacker News Reader

If you run tiger.svg through `svgcleaner`, you get a file that's 57614 (with no visual difference[1]) that compresses to 20924 with gzip or 19529 with zstd.

`svgo` gives 61698 / 21642 gz / 20228 zstd, again no visual difference.

Not really a need for TVG if you can clean your SVG as part of your deployment pipeline.

(You can go even further and trim the coordinates to 2 places of precision which ends up with 52763 / 18299 / 17114 zstd at the expense of still largely invisible differences but I've had SVGs where this level of cleaning did materially affect the output.)

[1] https://imgur.com/a/2b5CsPQ

View on HN

I came here to say the same thing.

Somebody recently pointed me at a nice online GUI for svgo, so you can try it for yourself without installing anything: https://jakearchibald.github.io/svgomg/

I'm not sure, but it seems svgcleaner can remove unused and invisible graphical elements[1]. I don't know if TinyVG preserves them. but if it does, it's not a fair comparison.

Did you try converting svgcleaner processed SVG to a TVG?

[1] https://github.com/RazrFalcon/svgcleaner

> Did you try converting svgcleaner processed SVG to a TVG?

I would but I can't build the SDK (gets some zig error about failing to add a package) and the darwin-arm downloads don't include `svg2tvg`.

If I use the darwin-x86 download, `svg2tvgt` can't convert the file - `UnitRangeException: NaN is out of range when encoded with scale 1`.

I guess it doesn't really parse all SVGs.

If the goal is smaller files than it's fair and SVG with SVGCleaner wins.

Maybe we need a TVGCleaner too.

While you're not wrong, I'm gonna put my graphic designer hat back on for the first time since high school and point out that sometimes you _do_ want those invisible elements still there, especially if you're gonna want to do further editing on the file later on.

> especially if you're gonna want to do further editing on the file later on.

I think you'd generally only use the cleaning / optimising step when deploying / packaging the asset - you'd leave the original as, well, the original for further editing (and to take advantage of better optimisations if they come about.)

Very true, and I'd expect graphic designers and most dev's to know that.

I've worked with enough people who only had the optimized assets because "Well optimized is better, right?" [0] that I thought it was worth pointing out.

[0] I was working on some web stuff for them and they were curious if I could also do some graphics work, small local company

You're right. The page mentions comparisons with optimized SVGs, but I didn't realize that the downloadable examples were not in fact optimized.

We are starting to miss the point of TinyVG with this discussion. The point is a simplified standard, so we don't end up with feature incomplete implementations. I mean just look at all the stuff Adobe Illustrator can, but Browsers can't. Final size a nice-to-have that comes with a minimalistic approach to the standard.

All of this of course at the risk of https://imgs.xkcd.com/comics/standards.png

What's the point if it's an output format and the authoring uses SVG? Then the lossy bit won't be the rendering but the SVG to TVG conversion.

or better yet, have brotli and gzip both in your pipeline

Just tested this and brotli gives an extra 1-1.5k saving over the zstd versions (18329 vs 19529 for tiger-clean.svg, 15749 vs 17114 for tiger-prec2.svg)

Reply on news.ycombinator.com