search

TinyVG / sdk

TinyVG software development kit
https://tinyvg.tech/
MIT License
263 stars 16 forks source link

This is a great idea, but it won't work with most SVGs #32

Closed codewitch-honey-crisis closed 3 days ago

codewitch-honey-crisis commented 3 days ago

Unsupported element "defs" - one of the most common elements in an svg document Unsupported transform "matrix(...)" Unsupported transform "translate(...)"

So what exactly do you support in terms of SVG for your conversion tools? If it's just the 1:1 mapping of elements in TinyVG that isn't practical. Your converter should be applying the matrix transformations for example before emitting the final coordinates in TinyVG rather than simply not supporting SVGs with a "transform" attribute in them, because all SVGs have them.

Anyway, the reason I ask is because I just spent a hell of a lot of time porting TinyVG to a more useful language for embedded (C++, w/ no STL - Zig isn't going to take off, BTW) but I can't actually do anything with it aside from process the examples you provide, which isn't helpful.

I was going to incorporate this support into my graphics library, but so far it seems I've wasted my time.

Please tell me I'm doing something wrong, and that you actually support basic SVG with your tools.

And if I'm not doing anything wrong, I'd maybe be willing to help put together a better SVG converter for your tools, but what you ship with isn't usable in the real world, for even simple documents.

Only thing is I don't code Zig.

ikskuh commented 3 days ago

Unsupported element "defs" - one of the most common elements in an svg document Unsupported transform "matrix(...)" Unsupported transform "translate(...)"

I do not support most of the SVG spec, because the conversion tool would be more work than anything else combined in the TinyVG project. What you can do to convert a lot of stuff is using an SVG optimizre like svgo to create a "shippable SVG" file which can then be processed by my tooling better.

Especially transform, translate and def are incredibly complex to process right and are not in no case part of simple SVG files.

Your converter should be applying the matrix transformations for example before emitting the final coordinates in TinyVG rather than simply not supporting SVGs with a "transform" attribute in them, because all SVGs have them.

Feel free to improve the conversion tool. And tell me how many ours you wasted doing so

because all SVGs have them.

That is definitly not correct. If it applies to your files, you should normalize them before using them as image files instead of shipping authoring files (svg is both a project format like .xcf or .psd and also an image format like .png or .jpg)

Please tell me I'm doing something wrong, and that you actually support basic SVG with your tools.

I do support basic SVG files, but the features you mentioned are definitly not "basic" but advanced and complex.

Only thing is I don't code Zig.

The conversion tool is written in C# and not in Zig as it's a much better tool to process whack and non-compliant XML files. .NET ships a quite resilient XML parser which is nice

codewitch-honey-crisis commented 3 days ago

Hmm, well I can do C#, but the issue is I've already created most of the parsing of SVGs in embedded C++. I can port it. I have something akin to XmlReader that I wrote for C++ to do peephole parsing. I can process an XML doc of any size in a fixed 64 bytes of RAM, but in any case, works similarly to XmlReader so maybe it won't be so bad to port.

When I said basic SVG, I mean files like you can get off iconscout, or like the tiger's head you show on your website.

In fact the tiger's head gave me the wrong impression that your conversion tool would support the elements that are in the reference SVG for it. Thank you for providing some suggestions for pre-cooking the SVG to a more shippable format, but absent a conversion tool that's more capable, I don't really want to impose multi step import processes for someone to use this vector format with my graphics library, and since SVG is what's for dinner in terms of source material, I'll just go back to supporting that.

I'm currently working on a major overhaul of that part of my library. My matrices are not being applied to spec right now for some reason, because I either don't understand the spec, I'm bad at math, or both. I'm thinking both. But I will get it working, and then once I understand what I need to do for that part, and can get it back to renderable content I'll poke at your conversion tool. I previously had it working based on Nanosvg but I rewrote the parsing part. The thing is, the result wasn't satisfactory performancewise or memorywise so I'm retooling everything.

Like I said, once I get my SVG situation sorted on my end, I'll have a crack at the conversion tool. Maybe we can incorporate some of the things that svgo does.

Thanks again for your advice