Hacker News new | comments | show | ask | jobs | submit login

I don't wish to sound rude, because this is great work by the author, but isn't this reinventing the wheel? Why not just use SVG? It might be somewhat less efficient for the very simplest images, but doing raster layers in code and including things like bezier handling seems perversely complex.



Because this lets you 'code' the icon visually , rather than describing the steps to draw.

It's a brilliantly simple but effective ideas. Very tempted to use it in my next project.


But why not just draw it instead of, well, typing it in ASCII? Once you start doing layers and blending and so on, you're just asking for misalignment errors, surprises when your bezier paths turn out to generate little unwanted loops and so on...

It seemed like the author's original problem was having to do so over and over to deal with different pixel densities, but this is exactly the sort of problem SVG exists to solve. I do admire the technical skill, I just don't get the attraction of compiling ascii art into a vector image for anything practical, for much the same reason that I wouldn't want to use Photoshop or Illustrator to write code.


> But why not just draw it instead of, well, typing it in ASCII?

Maybe because it is (or at least can be, the more advanced usages become less so) tolerably self-describing in that you can readily see what it is producing, in a way that SVG isn't, while still being source-control and diffing-tool friendly text?

For small things like its intended uses, it fits well within coding tools and workflows, and avoids separately documenting and coding the art.


Um, graphic files are also self-describing.

This kind of reeks of "If your only tool is a text editor, every problem looks like text".


It's more "if your primary tool is a text editor, there is a complexity cost to context shifting, and for some simple tasks that cost isn't justified if you have a suitable method of representing what you want in text."

Just as with programming, polyglot programming has value, but switching languages within a project had a complexity cost that isn't always justified even when for dinner task taken alone a different language is marginally superior.


Graphics files are not both self-describing and inline.

For some applications, having something be both can be helpful.


Way off topic but this is one reason I was excited about Atom the text editor. Given its running inside a browser you should, theoretically, be able to show svg inline, even allow visual editing inline.


Emacs has supported inline SVGs in org-mode since 2007 or so.


Exactly, could not have said it better.


I only use it for very simple icons (square, couple of lines, etc)


That makes sense. I apologize for coming off as so negative, I really do think it's very clever.


No worry, and no offense taken!


>But why not just draw it instead of, well, typing it in ASCII?

Because programmers typically prefer typing in ASCII to drawing :-)


I agree with you, I find this program fun and suitable for one man shops. Not practical for teams with graphic artists. Imagine if coder had to switch icon resources by hand from ASCII files?

There has to be something wrong with SVG when people even thinks drawing icons in this day and age in ASCII is a must do.


I think it's more to do with lack of knowledge than any huge problems with SVG. At least I found it very easy to draw stuff in Inkscape, at least for simple drawings like icons.


I know SVG very well, even have used it a few times for automatic generation of various graphics for bioinformatic projects. I use a lot of different graphic editors, and I am very familiar with them, e.g. Illustrator, Sketch, Acorn, Photoshop, Omnigraffle. I am also very familiar with e.g. Bezier paths manipulations, linear transforms, linear algebra, etc. I love maths.

Pixel alignment, asset management and being a one-man shop allowed more excentricities is what justifies this, for small icons with simple features (a few straight lines or rects).




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: