I guess one could train a Convolutional Neural Network to convert the ASCII art to an actual image. Something like this, but for ASCII: http://sketchy.eye.gatech.edu/
because some pixel are "more black" when an area is covered by two SVG elements
How can you possibly see that? This definitely needs a lot of more work on adding optimizer to reduce the elements into simplest form possible. Right now, this is just trying to put into screen what should it look like, it would be nice to have a more simplified SVG version up to primitive levels such as rect, circle, etc.
Short answer : I'm writing a drawing software and I've become pixel sensitive.
Technical answer : you are creating 1 pixel wide horizontal/vertical line with integer coordinates. Sadly in SVG this mean you writing your line between two pixel lines. So you don't write 1 black pixel but two semi-transparent black pixels. On white background the result is two RGB(127,127,127) pixels.
When two line overlaps you write semi-transparent black pixel twice and you end with two RGB(191,191,191) pixels.
You can hide this behaviour by shifting everything by 0.5 or using a retina display.
^^^ SO IMPORTANT. I returned to working with SVG seriously for a project last year, and was bitten by pixel-alignment rendering behavior along these lines. This was frustrating, as it was completely hidden during initial development by the fact that I was working on a retina-class display. On low-dpi, the rendering artifacts were quite noticeable. Compounding matters, the specifics varied by the SVG renderer (web browser) in use which also made it harder to identify the worst problem cases. Fortunately, it was noticed by an internal, design-sensitive user first!
This gets rid of the "more black" problem, but you lose the antialiasing effect which makes shapes with curves look horrible. Could try and apply it to only straight lines I suppose?
Network isn't the only issue - speed of processing, and memory usage, are both things people should care about a lot more than they do.
This is equivalent to wrapping every character of your website's text in a div, precisely positioning it - at a large enough scale, or with a dynamic page, it's just eventually going to cause performance issues or even lock-ups.
Years ago I had a program that turned ASCII diagrams like that into line drawing characters.
┏━━━━━━━━━━━┓ ┏━━━━━━━┓
┃ Like this ┣━━┫ Box ┃
┗━━━━━━━━━━━┛ ┗━━━━━━━┛
It's an easy transformation. You only have to look at 3 lines at a time, and then only at 3x3 blocks of characters. This would be a fun
transformation to put in a text editor.
The line drawing characters in Unicode (and originally on the DEC VT100) aren't expressive enough. They lack arrows and round corners. With SVG, you can do more.
There are a lot of people who just can't use a draw program. Not sure why. I use Inkscape for this sort of thing, or sometimes LibreOffice Draw.
I keep the Unicode box drawing characters in my XCompose configuration. For example the sequence 〈ComposeKey〉 〈#〉 〈-〉 〈-〉 produces ━ (The thin horizontal line). Not too difficult to type, even compared to the ascii approach. Also quite easy to remember — the # looks like a box, so all the box drawing sequences start on it.
This reminds me of Ditaa[1].
Org-mode offers support for it, so you can basically draw diagrams with Artist Mode and have org-babel convert them for you[2].
Haven't used emacs but base from the looks of it, it should render the text created in emacs-ArtistMode nicely. Try copy-pasting what you have in the text-editor, we'll see.
It seems to not recognize shapes and instead renders them using a bunch of lines, though (just like in the ASCII version). This is visible, at least in Safari 10.
Please, no. Maybe as a "plug-in" like MathJax, or a drop-in replacement for syntax highlighting in code blocks fenced off by "```svg ```". But please don't bloat the Markdown core.
This is useful in a plain-text based document system, for producing nicer rendered output. Box diagrams typed up in a man page can be rendered more nicely in a HTML version.
It could also serve as part of the markup input language in a system like asciidoc. The benefit is that the source resembles the output.
For displaying "inline glyphs" made of sequence of consecutive characters there is option to use font with corresponding ligatures baked in, such as Fira Code [0].
Yikes, LICENSE! Full of how it may or may not be sold phrases requiring a lawyer to understand to answer the question, "can I stick this font into a PDF that could end up in some software distro that could end up being for sale". The LICENSE appears to involve users into a contract; i.e. is not a pure license grant. 2-Clause BSD or fsck it.
In a HTML rendering, references to exotic fonts are pretty much a nonstarter, unless you include them in the page.
Actually I use a tool similar to this (ditaa) to generate drawings in an automatically generated reference manual frop ascii code diagrams in source code. There's definitely a good use for it.
Shameless plug: If you're on a Mac and want an app to create those ASCII diagrams, check out Monodraw [1]. I've just released an update [2, 3] which allows you to define to define snippets / templates which you can easily re-use: seems perfect to define snippets for this website.
I just wanted to thank you for this incredibly useful piece of software - I've used it even for creating diagrams on its own as it's very user friendly, and the ability to "render to ascii" is just an added bonus :)
