111–120 of 196 posts
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.
The best streamable vector animation format was invented 20 years ago, called Macromedia Shockwave Flash. It was killed by poor mobile processors and Steve Jobs' "Thoughts on Flash"
I don't think even the first generation of iPhone (400MHz ARM) was too slow to run the average Flash games of the time, given that SWF was originally designed to work well on mid-90s PCs (200-300MHz Pentium/Pentium II).
and Steve Jobs' "Thoughts on Flash"
That's more likely.
For simple image generation, nothing beats SVG or EPS. For years, these two technologies have let me add cool stuff to PDFs and web pages without the need for expensive/complex/insecure libraries. It is going to be pretty hard to beat the ease of generating these formats.
Maybe because in the formats named, the image format is the expensive/complex/insecure libraries? I know that sounds a bit snappy, but I felt the author of TinyVG made a pretty good case for what they're aiming at: a simple vector format that does not come with a (or even multiple, in at least the case of PDF) Turing complete kitchen sinks.
There are many other popular vector graphics formats beyond those mentioned here. Lottie has already displaced SVG for animation/motion graphics, and for static content IconVG exists and is backed by Google. There's also PDF, PostScript, Flash, the glyf format in OpenType, etc.
Looking at the website, it seems like the file format is OSS but the creation side of things is proprietary?
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 for TinyVG as it is too large in several regards. XML kinda requires DOM parsing, XML is a text format (so inefficient encoding) and XML parsers need to be large so they can be called XML parsers. All of these properties contradict a embedded world where you can render vector graphics from 32k RAM on a chip that doesn't even have enough memory for a framebuffer itself. Also implementation complexity of XML…
Why? Streaming/evented (e.g., SAX) parsing for XML is as old as XML.
Earlier quoted context omitted.
The problem with that is that you still need to implement a full XML parser. Even if you strip out any CSS and ECMAScript, it will still require the complexity of XML with all it's gloryness and escapiness and ambigious defines. And even if we rely only on XML, we get the DOM and hierarchical structures. If we forbid those, we have as a file format and people will look weird because their other SVG won't be supported…
"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…
Semi-structured data is not bad. Namespaces are not bad. Schema are not bad. In fact, I also on the other hand very much lament that XML's backlash lead us to JSON, which is entirely untyped semi-structured data where everyone has to write an (often buggy and incomplete) ad-hoc typechecker for every single document.
Those features are not the problem, the problem is that they are embedded in the SGML-borne XML, that has many weird and intricate corners that only make sense in light of its history, and that lead to complex parsing, obscure behavior, and lots of potential for vulnerabilities--in the parsers or in code that just uses a (perhaps in itself safe) parser. DTDs, Entities, and Processing Instructions are just some of the more known warts.
The best streamable vector animation format was invented 20 years ago, called Macromedia Shockwave Flash. It was killed by poor mobile processors and Steve Jobs' "Thoughts on Flash"
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…
Amazing.
Huh, nice. I always reach for SVG when i want a hand-editable format for some random project, but your points on the parsing and implementation complexity seem very reasonable. Two qns: 1. Did you consider a re-specification of SVG or a subset in another embedding language that's easier to parse? text/json+svg, application/bson+svg, etc. (Examples for clarity, not literally suggesting json/bson are appropriate choice…
> 2. … Oh that explains why all my rendering experiments looked different from SVG. I think the reference renderer already does gamma correct blending. This is something we should add to the specification for sure. > 1. … Even re-encoding the SVG crap would only remove XML from the equation, but that's not my main concern with SVG. Zig has the Zen "only one way to do things". Meanwhile SVG has tens of ways to solve t…
For a pen plotter, I'd like something like SVG that has color, pen-pressure, and pen-rotation.