151–160 of 196 posts
I have to install a plugin to allow my WP sites to support SVG because they can potentially contain scripting, what a pain in the ass. All we wanted was vector images, what we got was vector images and a couple kitchen sinks. Bring on the alternatives.
Also, don't use WordPress. It sucks.
Earlier quoted context omitted.
Franky somebody should do like a TinyDF replacement for pdf... That's also a somewhat bloated format at this point. Ideally though, the tiny* formats should be forward compatible (?) and interpretable as a valid non-Tiny* document. That would be quite nice for wider adoption (like JSON).
PDF is indeed a very bloated format, but documents are inherently complex. I don't think you can create anything that deserves the name "tiny" but can still handle anything you might want to send to a printer (and that's a much smaller use case than "anything you want to display on a screen").
A compressed, paginated and indexed postscript file is not complex.
Earlier quoted context omitted.
Franky somebody should do like a TinyDF replacement for pdf... That's also a somewhat bloated format at this point. Ideally though, the tiny* formats should be forward compatible (?) and interpretable as a valid non-Tiny* document. That would be quite nice for wider adoption (like JSON).
PDF is indeed a very bloated format, but documents are inherently complex. I don't think you can create anything that deserves the name "tiny" but can still handle anything you might want to send to a printer (and that's a much smaller use case than "anything you want to display on a screen").
It's not very well known, but it's so elegant, and also efficient, especially for scanned files.
I am not sure how relevant this is, but I recently published a proof a concept library that converts SVG documents into simulated machines. See the link below. https://www.getlazarus.org/videos/physics/blueprint/ The rendering in my library relies upon OpenGL and the NanoVG library. My library is called Tiny Sim. All of these nano tiny and vg names seem to be colliding adding a bit of confusion in my opinion.
Very reminiscent of Line Rider. https://www.linerider.com/
I have to install a plugin to allow my WP sites to support SVG because they can potentially contain scripting, what a pain in the ass. All we wanted was vector images, what we got was vector images and a couple kitchen sinks. Bring on the alternatives.
Of course this has some drawbacks, particularly when talking about user-uploaded SVGs on a website (they probably shouldn't be on the same domain as the website at all). But that's a much narrower use case than what SVG was supposed to be or even than what SVG is used for today.
Earlier quoted context omitted.
"XML is bad" is still one of the worst engineering arguments. Why is it bad? What is the tradeoff? Things that are bad are easy to quantify as they're measurable. What does it have? It has strong schema support built in. Any intelligent IDE allows for cmd-space completion by reading the XSD. I don't buy this argument as full XML parsers are not even as complicated as HTML5 parsers, which nobody seems to have an issue…
> "XML is bad" is still one of the worst engineering arguments. It’s reached meme status. I think most people conflate complex XML-based _formats_ (e.g., WSDL, XSD) with XML _the format_. The rules of XML parsing can fit on a notecard. And a basic parser that supports all the core functionality plus namespaces is really not that complicated to implement. Now, implementing schema validation, Xlink, etc. in your parser…
Yes, but SVG requires a lot of those optional bits... A parser complex enough to deal with all the nooks and corners of SVG is not simple at all.
Earlier quoted context omitted.
XML is an integral part of SVG. Don't even know what implementing a subset without using XML would actually mean. An XML being a strong contender for the title of worst file format ever devised by mankind, I'm not sure how 'implementing a subset' would fix that.
Well yes, it’s true you’d have to implement basic XML parsing to implement a subset of SVG. At the same time, despite how unpopular XML may be it’s among the easiest textual languages for which to write a parser. This isn’t hyperbole. It’s so trivial I didn’t even consider that that’s what you actually meant.
To define a subset of SVG doesn't imply that simplifying the XML part is going to be easy.
A small nitpick as the resvg author: the repo located here https://github.com/RazrFalcon/resvg I'm not sure why the author linked some random, outdated fork. If you're trying to beat SVG, you should have done a better research. But yes, SVG is extremely bloated and under-documented. Especially SVG 2. The core resvg codebase is close to 20 KLOC, while the whole package is like 50 KLOC. On the other hand, resvg is an e…
> A small nitpick as the resvg author: the repo located here https://github.com/RazrFalcon/resvg
Oh, i didn't see this. Thanks for some more correct and real numbers, i will correct them in the article later!
> I'm not sure why the author linked some random, outdated fork.
because it appears way higher up on the google search if you search for "svg rendering library". Sorry i didn't recognize that it's a fork!
Nice work then! I should check it out for SVG rendering and parsing.
How much work would it be to port over the C# SVG→TinyVG converter to Rust based on resvg? Considering that you already have a well done parser compared to mine...
Earlier quoted context omitted.
That's a good question! I fell for this problem with text rendering once as the font i've used in a SVG wasn't installed on the target machine. If i create a image, i want that image to look exactly the same on all machines. This is sadly not the fact for SVG :( The W3C SVG example files contain a lot of these files that make every SVG renderer explode. There's images that don't render anywhere except inkscape
> There's images that don't render anywhere except inkscape You just have to convert the text in the image to a path before using it wherever you plan on, just be sure to save the original for editing.
https://mq32.de/public/9f3cd5eb7f310139cf8acdd61edb73080d26a...
TinyVG doesn't implement node referencing. In SVG it is done by the `clone` operation, which creates SVG node that references original shape. Using this you can build smart scenes with shadows, reflections, arrayed clones and other interesting effects. It's like DRY principle for art; you can later modify the original shape and see changes reflected in other parts of the scene.
TinyVG doesn't even seem to have object groups. If I wanted to draw a gauge and control needle rotation in runtime I would have to manually re-compute path coordinates each frame. In SVG I would group all parts the gauge needle, and in each frame I would update just the rotation angle in group transform.
For a vector format to de-throne the SVG I would expect it to be smarter than SVG while discarding legacy features. I'd like to see things like infinitely large dimensions for shapes (shapes for ground and sky, or a ray of sun), specifying design constraints, interactivity and procedural animations. IMO the TinyVG takes vector graphics into wrong direction, as a boring subset of SVG.
Edit: I like that TinyVG takes form of very readable lisp-like data description language. Maybe it could be used as a starting point for a smarter vector format for authoring graphics and not just for distributing the end results.
