Hi, all. I am the blog post author, blown away by the attention this 1-day hack is getting! I am the author of Findings, a lab notebook app for scientists. Check it out and show it to others: http://findingsapp.com
I also created this page: http://asciimage.org, with my friend @mz2. There is a simple editor as well called ASCIImage Super Studio.
I didn't quite understand how the single points worked. It seemed to me that your definition for, say, 3 single points was the same as a triangle. How does it know which is which? Or do the curves have to be closed?
I think I was thrown off by the example which used 1,1,1,1 for the sphere and 2, 3 to represent isolated points. But they're consecutive. Unless I'm missing something?
Shameless plug - Monodraw [1] is perfectly suited to create the ASCII diagrams for this. I'm planning to add special support for ASCII Image if there's enough demand - so definitely let me know.
Wow, monodraw is a really polished app. That's a fascinating business model, too - your own idea, or inspired by another? Are you planning on giving users notice when the beta period is about to end?
I'm not 100% sure I'll really get regular use out of it, but I'm tempted to buy a copy anyway, mainly because I think you deserve reward for the effort that's obviously gone into it.
If I could wish for anything it would be this: is it even remotely possible for shapes from a plain text file to be interpreted as monodraw objects, rather than just one big text field?
> Wow, monodraw is a really polished app. That's a fascinating business model, too - your own idea, or inspired by another? Are you planning on giving users notice when the beta period is about to end?
Thank you for your kind words :) I think the business model has been inspired from the indie scene over the years. Simply put, I do not want to charge customers before the product is of quality that I deem adequate. That's why the beta is freely available without any restrictions. If anyone feels generous enough to support us before v1 ships, they get 40% off in return.
Yes, I plan to provide ample warning over email, Twitter + our blog.
> I'm not 100% sure I'll really get regular use out of it, but I'm tempted to buy a copy anyway, mainly because I think you deserve reward for the effort that's obviously gone into it.
I greatly appreciate the support. Even if you don't purchase it, knowing that you like the app is enough to motivate me to further work on it. From a financial perspective, every purchase counts - as an indie, my livelihood depends on the apps I make, I don't have any other income.
> If I could wish for anything it would be this: is it even remotely possible for shapes from a plain text file to be interpreted as monodraw objects, rather than just one big text field?
That has been requested a few times and it's something that I'm considering. It's not very high on my list but if I receive enough requests for it, I'll bump up it. I don't have a roadmap that is set in stone and I'm pretty flexible when it comes to the development of Monodraw - I'm willing to listen to the users.
This is a work of art in of its self, never mind the icons made.
It is also inspiring for ascii to graphics representation utilities as well. I wonder if this could be extended to make shape holder content, where in the art you can specify the stretch locations and protected zones. (kinda like how you can do a boxy like configuration on images for dynamic content inside via CSS3)
I imagine it could work like Android 9-patch PNG drawables, which have an extra ring of pixels around the perimeter that mark content zones and stretching zones.
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.
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.
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.
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.
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).
My go-to choice for this has been SVG. For shapes as the ones in the post it's trivial to write by hand and equally trivial to generate various amounts of raster images in various sizes. It's been quite helpful for preparing Android and iOS app icons without constantly having to revise half a dozen different images whenever one changed. It's also easy to change opacity or colour of the shapes/strokes for generating icons for different themes (Holo Dark and Holo Light on Android need different colours, for example).
I haven't checked lately but traditionally SVG wasn't available with UIImage yet was with NSImage. This often lead to custom drawing code for vectors on iOS.
I used it only as source for the differently-sized raster images. I sort-of inherited an Android and iOS app at that workplace and just went with what was there. But given that the app used OpenGL I'm not sure there even was a possibility of a vector format to use.
why does OpenGL rule out vector formats? there aren't that many great libraries out there for doing it cross platform, but if you treat them as platform dependencies it should be easier...
you can probably google and find loads, but to get you started a little...
the main one I have experience of is 'cairo' which is quite a powerful library for all kinds of drawing things. there is an android build config (although its a bit old now) here: https://github.com/anoek/android-cairo - it is however not great for iOS or OS X...
It doesn't rule it out per se, but just rendering a texture is much easier, with fewer dependencies. Android toolbar icons are PNG, not SVG. Most renderers have trouble with all but the simplest SVGs (filters, etc. can be a pain in the ass – Inkscape renders them nicely to PNG and I just don't have to worry). There's a trade-off everywhere and all my solution did was take input SVGs and render the PNGs in various sizes which we previously had to maintain by hand. If rendering vector graphics would have been a major competitive advantage to the app I'm sure it would have been considered ;-)
i do wonder how long it will take for Apple to come around to mipmapping and trilinear filtering to tackle their very normal problem of multiple resolutions.
it seems to work well enough in all their use cases for the last 20 years or so... :)
This looks vaguely like xpm, but monochrome and vectorized. xpm is an image format that is also valid C code, so you can #include "image.xpm" in your C source code.
Also kinda like XBM, a file format that was happily supported in the browser - and you could create the images in JavaScript! http://www.mrspeaker.net/2005/03/27/xmb-images/ - unfortunately, IE was first to discontinue it in 2006 (http://www.mrspeaker.net/2006/09/04/the-end-of-xbm/), and Firefox followed. My guess is it was too obvious of a security hole vector for an image format that no one actually used ;)
XPM isn't monochrome either, though. I always thought XPM was an elegant hack, since I could just #include my icons into the C source for my Xt or Motif applications. I don't miss the rest of Xt and Motif, particularly the pseudo-object-oriented C style code, or the twenty kilograms of O'Reilly books containing the documentation!
This is how we did DOS VGA fonts ~1990. Draw the pixels right in the code (everything was monospace) and write that array directly to video memory. Mode 13 (320x200x256) video memory was sequential, easy to animate. Also you could do palette scrolling. Consequently, Mode 13 was the best video mode for games http://en.wikipedia.org/wiki/Mode_13h
What if you allowed composing multiple "layers" into a single output to make different parts of an otherwise busy diagrams more clear? For example, I found the bug one particularly obfuscated:
I agree, the bug is mostly a worst-case complexity scenario, but it seems to help with the other slightly more complex examples like the lock as well, by separating the keyhole from the rest of the shape:
XPM is only for resolution-specific rasters. His technique allows for bezier paths, arbitrary fills, etc and is resolution-independent. It's pretty clever, IMO.
I'll never understand all the down-votes; this wasn't a criticism of the project, it was just mentioning that the beginning of the article suggests nothing like it had ever been done before.
I'm confused; how is this not comparable? It's creating a pixmap directly from strings. I'm not saying this project is bad or uncool, I'm just saying this isn't a completely new idea.
The ASCIImage rendering code described in the post we're discussing is actually resolution independent vector graphics. You can draw neatly pixel aligned stuff with it, as is shown in the screenshots, but it's vector graphics.
I'm not saying the author didn't make something far more advanced or cool; but the beginning of the article makes it seem like ey thinks ey is the first to ever come up with such an idea, which is false. I was never trying to say that the project is a knock-off.
Exactly. The core concept here is defining images for icons in the code itself, rather than loading them from external resources. XPM was one early way of doing that, allowing you to define bitmapped images in a static array of characters representing the pixel colours, and was a very neat hack. Now this extends and improves the idea, allowing you to define images for icons in your code, using an array of characters to represent the lines in an image, and define a vector graphic. It's definitely in the same conceptual space, although there doesn't seem to have been any direct inspiration from the earlier format. Both are very cool ideas...
For the actual drawing, I'm wondering if the cairo library and drawing model would help. It effectively gives you the move-to line-to curve-to drawing, with some additional capabilities. A simple script around cairo seems like it would cover many more cases, and then this ASCIImage mechanism will help generate those scripts.
What extra capabilities do you think cairo would provide that could be exposed through the ASCII-art mechanism without overly complicating it? This thing is already choosing to not expose the full functionality of the NSBezierPath drawing APIs.
I'm not suggesting extending the ASCII art mechanism. I'm just suggesting that compared to the API shown in the first example, cairo makes simple line-art quite trivial to write as code.
Specific features that would make sense to have available rather than drawing art in an image editor:
Line width, to draw the chevron without having to draw two adjacent lines.
I like it very much. I would push this even further: I see it as a sort of "Markdown for simple vector graphics", with tools able to convert it to SVG and other formats.
Designers have more possibilities with 3x and 2x than with 1x as you can draw small details. If you scale them to 1x, the icon will look blurry, because the details doesn't scale well. If you want high level of polish, you typically make at least some touches to the scaled down icons.
Of course, in the context of the original ascii art icons, that level of polish doesn't matter.
Guess we can expect a full NSImage export feature in the full version. I just started using Monodraw and this was the first thing that came to mind as well.
I actually did consider this when writing the "parser" but it was complicated enough that it was just getting in the way of my goal of having the simplest code and specs that got the job done. Also using 1-2-3-4 is simple enough that I decided it was not worth the extra rule.
I am really surprised that there haven't been more efforts in this direction. As a programmer who's recently been dabbling more in graphics, I hate having to fiddle with knobs and redo my work when I often know exactly what needs to be done and how to do it. If I need to draw an oval 10 times, I shouldn't have to copy and paste it, forcing me to redo the entire thing if I decide to make a change; I should be able to define the oval in script and use a loop to position it exactly how I want!
I wish there was an editor with an interface as great as (say) Pixelmator's, but with an optional script window that let you write and edit the code for your vector graphics if you need to. Something PostScript powered, maybe? (PaintCode does something like this, but it's more of a one-way, vector-to-code mapping. Bloom promises to do a lot of this, but I haven't used it in a while.[1])
> If I need to draw an oval 10 times, I shouldn't have to copy and paste it, forcing me to redo the entire thing if I decide to make a change
Indeed you shouldn't! That's why all serious image manipulation programs have this capability built in.
Most of them also let you write your own plugins for those cases where you need more than what the interface provides.
I think going to all-code drawing is more limiting than freeing. It seems more like a case of having a hammer and seeing that everything can be made to look like a nail.
Well, I'm not advocating all-code drawing! What I'm suggesting is a WYSIWYG editor like any other, but with a 1-to-1 script mapping for all the commands under the hood. If you want to generate an oval in code, go for it; but you can also create one using the oval tool (and edit it later in script if you change your mind).
As for plugins, that's not really integrated into the workflow in the way I'm envisioning. I shouldn't have to write heavy code just to experiment with a quick artistic idea! Think web development. It should be as simple as editing a JS file and refreshing the page.
This seemed like a fun little project so I created https://github.com/bakul/avg.git -- a Go package that converts an "ascii vector graphic" string vector into a shape vector.
I wonder what's better from the point of final user (app size, app starting speed, app performance, memory usage): png or this drawing code? I suspect that PNG should work better. And programmer can easily generate multiple PNG from single hand-written SVG.
Nice to see the actual comparison of the binary size (and there is the 2x and 3x png). On the other hand, to be fair, the memory footprint will be more with the ASCII version (text + final NSImage loaded as bitmap in memory) compared to png (only the bitmap in memory, directly loaded from disk). The size of the bitmap is big anyway: there is no compression.
It could of course be rendered to a PDF or TIFF or other Cocoa supported image file format, consider that just a 5-minute hack to demonstrate the idea.
I'm going to join you here in the grey. Objective-C is a disaster of a language on many levels. Portable C++ is the smarter and better choice(and those few cases where it isn't is solely because of intentional and unethical design decisions by apple to lock you into their platform).
Whether or not that is the case, it is completely irrelevant to the topic of the article, unless C++ would help with the "shouldn't have to exist" part. I imagine that a language like Racket which can embed (vector) images directly into source files might help, but C++ has nothing like that, nor do most languages. You could argue that making icon sets for iOS is harder than it has to be, but that would be an IDE and/or tooling problem, not an Objective-C issue specifically.
I know you & the parent have both been down-voted, but it would be great if you could explain some rationale behind why Objective C is such a disaster in your opinion(s)?
When I first started learning it, I absolutely _hated_ it. With a burning passion.
It is probably now my current favourite and most productive language.
I seem to very rarely write buggy/poor/badly structured code and almost never hit compiler errors/hard crashes unless they are something relatively obscure. It's quite common for me to write 1k+ lines of code, hit build and have exactly what I wanted compile & work pretty much first time.
Not OP, and I agree that Objective-C is great. However, it is potentially troubling, from a performance standpoint, that practically everything is allocated on the heap. There's no support in the language for stack-allocated objects, for example. Now that I've used Swift in production, I also really miss generics. Casting to and from containers gets really annoying and unsafe!
"that practically everything is allocated on the heap"
That's kind of the point though. If you want something on the stack, you write plain old C structs or work with primitives. There's plenty of this happening throughout the cocoa frameworks. On the other hand, if you find yourself writing C structures to the heap in objc, you're probably wasting your effort.
Objective C is mostly used for UI code, and I think it's a fantastic language for that, with its Ruby-like weak typing and strong metaprogramming capabilities.
I think that's just the natural consequence of knowing a language. I can do the same with a JS and a linter. I don't think that necessarily speaks to the bug-free nature of JS!
You do realise that Objective-C was used because iOS is effectively OSX. And OSX is effectively NextStep. Apple is a big company sure but rewriting your entire SDK is never a quick or simple endeavour. So of course when the iPhone came out Objective-C was going to be used.
And for those who aren't keeping track of the timeline, NeXTSTEP predates C++ templates. Large portions of this could have been done with 1989's Objective-C and the graphics capabilities NeXTSTEP had at the time, though this tool does benefit significantly from some newer syntax.
I also created this page: http://asciimage.org, with my friend @mz2. There is a simple editor as well called ASCIImage Super Studio.
And check out Monodraw, I love it!! http://monodraw.helftone.com
(see comment here: https://news.ycombinator.com/item?id=9240942)