Live data from Hacker News

TinyVG: A challenger to the throne of vector graphics

zig.news

181–190 of 196 posts

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

#181
post #37
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.

Agreed; I was playing with pinwheel tilings [1] today and decided to make some pinwheel art [2] that fits in a signature: %!PS % -John Tromp http://tromp.github.io/ /t{dup 1 sub gsave dup 0 gt{[.4 .2 -.2 .4 .4 .2]concat t currentgray .8 mul .2 add setgray -1 1 scale t -1 2 translate t 1 -1 scale t[0 1 1 0 0 2]concat t pop}{0 moveto 1 0 lineto 0 2 lineto closepath clip fill}ifelse grestore}def 10 10 translate 600 600…

Apologies for being off-topic and possibly absurd question - could the binary lc be considered a concatenative language?

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

#182

Earlier quoted context omitted.

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.

Careful now. SVG uses a lot of XML features that goes beyond "basic XML parsing". To define a subset of SVG doesn't imply that simplifying the XML part is going to be easy.

> Careful now. SVG uses a lot of XML features that goes beyond "basic XML parsing".

Could you name the feature to which you are referring specifically?

> XML part is going to be easy.

What part of parsing XML is hard? My premise is that all XML parsing is easy.

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

#183

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?

It's hardly a caveat for SVG - where you usually want total control over the placement of the text elements.

If you want it to look like a document with wrapping then use HTML for your text, not SVG

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

#184
post #159

Earlier quoted context omitted.

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

I wasn't talking about text in that case. Here's a screenshot of that image: https://mq32.de/public/9f3cd5eb7f310139cf8acdd61edb73080d26a...

Huh. I'm afraid I don't know enough about Inkscape or the SVG specs to help with that, just enough to know it's a pain.

Off topic question for you though, that looks like probably i3 or dwm, did you make any modifications to Inkscape to make it more usable in a tiling wm, I always have to turn off tiling when I launch it.

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

#185
post #133

Earlier quoted context omitted.

> XML kinda requires DOM parsing Why? Streaming/evented (e.g., SAX) parsing for XML is as old as XML.

Yes, but SVG can and will do forward references. Ergo, we have to store some kind of DOM in order to resolve them. Even if it's not in the form of the XML doc

Couldn't the proposed subset just drop forward references?

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

#186
post #37

Earlier quoted context omitted.

Agreed; I was playing with pinwheel tilings [1] today and decided to make some pinwheel art [2] that fits in a signature: %!PS % -John Tromp http://tromp.github.io/ /t{dup 1 sub gsave dup 0 gt{[.4 .2 -.2 .4 .4 .2]concat t currentgray .8 mul .2 add setgray -1 1 scale t -1 2 translate t 1 -1 scale t[0 1 1 0 0 2]concat t pop}{0 moveto 1 0 lineto 0 2 lineto closepath clip fill}ifelse grestore}def 10 10 translate 600 600…

Apologies for being off-topic and possibly absurd question - could the binary lc be considered a concatenative language?

(I would have expected this comment on https://news.ycombinator.com/item?id=29630293#29631288 instead:-)

No, Blc is not a concatenative language. It uses application rather than concatenation to combine programs, and its semantics is not described in terms of stack operations (the blc seld-interpreter happens to use a stack though).

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

#187
post #104
post #83

Earlier quoted context omitted.

"somewhat bloated" is the understatement of the century. PDF documents can contain executable code in two different programming languages (JavaScript and PostScript), interactive content, digital signatures, their own form of encryption, and more. Why they thought adding JavaScript to an already infamous attack vector of a format is beyond my understanding.

Javascript was added to PDF in order to implement interactive and dynamic forms, including input validation and normalization and dynamically adding/removing form elements based on user interaction. The contents of forms can also be directly submitted to a server. Basically, Adobe didn’t want HTML forms to steal their show, so they implemented the equivalent with PDF. Not saying that was a good idea, but here you go.

[deleted]

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

#188
post #127
post #83

Earlier quoted context omitted.

"somewhat bloated" is the understatement of the century. PDF documents can contain executable code in two different programming languages (JavaScript and PostScript), interactive content, digital signatures, their own form of encryption, and more. Why they thought adding JavaScript to an already infamous attack vector of a format is beyond my understanding.

PDF can contain executable PostScript? That was new to me. I know the syntax is still PostScript, but without the programming language. Is there a nice description somewhere?

It seems that my understanding of this was not correct. I should have checked this before posting it, but I have a vivid memory of some PDF that rendered a different maze each time you opened it using PostScript and that override everything else. Most of what I'm reading suggests that the turing-complete aspects were removed in the design of PDF.

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

#189
post #131

@ikskuh -I do not see any mention of layers or grouping in the specification (unless it went by some other terminology I missed in my skim). In the blog post you said you wanted to avoid having an "authoring" file and a "redistributable" version. I am far from an artist but have hacked out a few .svg sketches and layers/grouping are a requirement for creating new content.

I think you got me wrong then. I WANT authoring files and redistributables to differ. Nobody should send SVG, xcf, psd files to the consumers. We use PNG or JPEG for pixel graphics, why not send of TinyVG instead of SVG, but use SVG as the source file. This is what i've done for a lot of test files until i had the TinyVG text form ready. Also, we should not edit graphic files in a code editor. We have better tools fo…

Whoops. Well then sounds great.

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

#190
post #127
post #83

Earlier quoted context omitted.

"somewhat bloated" is the understatement of the century. PDF documents can contain executable code in two different programming languages (JavaScript and PostScript), interactive content, digital signatures, their own form of encryption, and more. Why they thought adding JavaScript to an already infamous attack vector of a format is beyond my understanding.

PDF can contain executable PostScript? That was new to me. I know the syntax is still PostScript, but without the programming language. Is there a nice description somewhere?

Old versions of PDF allowed to embed arbitrary PostScript for some area of the page, but this was always specified not to have any effect except if the PDF gets converted to PostScript. Especially it was specified to be ignored by PDF viewers and non PostScript printers, making it rather useless. In current PDF versions, this is no longer allowed.
Post reply on HN