Live data from Hacker News

TinyVG: A challenger to the throne of vector graphics

zig.news

171–180 of 196 posts

Re: TinyVG: A challenger to the throne of vector graphics

#171
post #113
post #18

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.

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.

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…

> 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

#173
post #31

Earlier 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.

Okay, and he killed it because it was annoying to users and provided little value.

Re: TinyVG: A challenger to the throne of vector graphics

#174
post #113

Earlier 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.

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 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

#175
post #174

Earlier 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…

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, what makes this format preferable to the many existing format other than SVG?

Re: TinyVG: A challenger to the throne of vector graphics

#177

Earlier 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?

Try any Bootstrap site

Re: TinyVG: A challenger to the throne of vector graphics

#178
post #174

Earlier 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…

The recent NSO exploit using the PDF JBIG2 codec was also a hilarious example of abusing image formats: https://news.ycombinator.com/item?id=29568625

Re: TinyVG: A challenger to the throne of vector graphics

#179
post #174

Earlier 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…

It's a bit of a trade-off. An existing browser for example will likely just add the format, effectively creating more attack surface, yes. A new product however can choose to only implement the simpler one (and if no features of the more complex one are needed, will likely want to do so for a multitude of reasons).

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.

Post reply on HN