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.
> without the need for expensive/complex/insecure libraries. 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.
TinyVG: A challenger to the throne of vector graphics
171–180 of 196 posts
Re: TinyVG: A challenger to the throne of vector graphics
#172> How will this look in different browsers? Let's test! obviously different font widths for rendering of SVG text in different browsers/font stacks > That didn't go as expected. I thought that at least both files on my Linux machine look the same, but it seems like Firefox doesn't like the font-size specification, while Chrome and Edge do. I asked the Render-A-Webpage-As-An-SVG-framework guy about this last week. He…
What’s the deal? The font-size declaration in the style attribute was invalid, and Chromium allowed it, in direct contravention of both the SVG 1.1 and 2 specs, while Firefox disallowed it. SVG 1.1 extends CSS 2’s font-size value to allow a unitless number on a font-size SVG attribute https://www.w3.org/TR/SVG11/text.html#FontSizeProperty >, but when you specify it as a CSS style it must follow the CSS declaration fo…
That's quite a caveat. How many current webpage designs depend on wrapping happening in exactly the same way across all browsers and device dimensions?
Re: TinyVG: A challenger to the throne of vector graphics
#173Earlier quoted context omitted.
> We need more SVG animations on the web. Do we, though? We've already had animated GIFs, the marquee tag, Java applets, and Flash animation, and they've all died out because 99.9% of the time the animation is obnoxious and terrible. Vector animation would be just as annoying.
Flash animation didn't die out--it was assassinated by Steve Jobs. Flash renderers didn't have to suck. However, there wasn't enough money in it for anyone to care.
Re: TinyVG: A challenger to the throne of vector graphics
#174Earlier quoted context omitted.
> without the need for expensive/complex/insecure libraries. 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.
You are 100% right. I will now throw out all of my work because despite being easy to generate, I could accidentally generate an image that does something bad (do you even halt bro?) and I don't want to do that. So I will throw out my simple well tested native solutions and replace them with a solution that needs to be compiled to a native solution.
Look at log4j for a recent example on what unwanted complexity does. For something matching the subject matter at hand here, look at the various image parsing attacks that have gained large notoriety. Now force multiply by having PostScript, an actual programming language, in the path.
Re: TinyVG: A challenger to the throne of vector graphics
#175Earlier quoted context omitted.
You are 100% right. I will now throw out all of my work because despite being easy to generate, I could accidentally generate an image that does something bad (do you even halt bro?) and I don't want to do that. So I will throw out my simple well tested native solutions and replace them with a solution that needs to be compiled to a native solution.
The point is not the producer. The point is that complex formats require complex infrastructure (parsers, interpreters etc.) on the consumer of the format. And the issue with Turing complete kitchen sinks in your image format is not so much that it may not terminate (it is a problem, but a more minor one), but that such facilities are a) themselves often a vector, b) often a good way to leverage other vectors. Look a…
Re: TinyVG: A challenger to the throne of vector graphics
#176Re: TinyVG: A challenger to the throne of vector graphics
#177Earlier quoted context omitted.
What’s the deal? The font-size declaration in the style attribute was invalid, and Chromium allowed it, in direct contravention of both the SVG 1.1 and 2 specs, while Firefox disallowed it. SVG 1.1 extends CSS 2’s font-size value to allow a unitless number on a font-size SVG attribute https://www.w3.org/TR/SVG11/text.html#FontSizeProperty >, but when you specify it as a CSS style it must follow the CSS declaration fo…
> Text in SVG is just as good as text in HTML, except inasmuch as nothing implements runtime (font-dependent) line wrapping, so it’s kinda more like HTML with white-space:nowrap. That's quite a caveat. How many current webpage designs depend on wrapping happening in exactly the same way across all browsers and device dimensions?
Re: TinyVG: A challenger to the throne of vector graphics
#178Earlier quoted context omitted.
You are 100% right. I will now throw out all of my work because despite being easy to generate, I could accidentally generate an image that does something bad (do you even halt bro?) and I don't want to do that. So I will throw out my simple well tested native solutions and replace them with a solution that needs to be compiled to a native solution.
The point is not the producer. The point is that complex formats require complex infrastructure (parsers, interpreters etc.) on the consumer of the format. And the issue with Turing complete kitchen sinks in your image format is not so much that it may not terminate (it is a problem, but a more minor one), but that such facilities are a) themselves often a vector, b) often a good way to leverage other vectors. Look a…
Re: TinyVG: A challenger to the throne of vector graphics
#179Earlier quoted context omitted.
The point is not the producer. The point is that complex formats require complex infrastructure (parsers, interpreters etc.) on the consumer of the format. And the issue with Turing complete kitchen sinks in your image format is not so much that it may not terminate (it is a problem, but a more minor one), but that such facilities are a) themselves often a vector, b) often a good way to leverage other vectors. Look a…
I am not really arguing because more image formats can only make my life easier but I have to wonder what is the point of this new format when I have to compile it into the existing complex-infrastructure format. If you tell me that we should add native support for this format, does that mean that we remove support for the complex-infrastructure formats or have we simply created a wider surface area for bugs? Finally…
Over time, the old format may potentially be removed if it falls in disfavor, or at least only be accepted in more and more restricted contexts, but this works better in closed systems of course. I just finished excising a complex format in favor of a much simpler one, and since it was internal to the organization cutting out the old one did not cause anyone problems. For browsers, I don't know. Deprecating Java Applets and Flash seems to have worked, but those are maybe "heavier" examples than SVG.
As for comparison to existing vector formats, I don't have the necessary domain knowledge there.
Re: TinyVG: A challenger to the throne of vector graphics
#180"a powerful, flexible, declarative domain-specific language for creating vector graphics, using the Haskell programming language."