I found this neat snippet in this answer: $('pre').css('line-height',1)

There, Timwi suggests running it in the browser's console to make ascii art look better. It definitely improves the look of several questions.

For example:

I'm suggesting that maybe we can add that statement to the tag wiki excerpt, so that other people might find it.

share
    
I'd rather see it as the site CSS or maybe as a userscript that adds a button. BTW the snippet could be simplified to $("pre").css("line-height", 1) –  Jan Dvorak Feb 7 at 8:23
2  
An even better userscript option might be something like $(.post-taglist a[href="/questions/tagged/ascii-art"]).length && $("pre").css("line-height, 1") –  Peter Taylor Feb 7 at 10:32
    
@JanDvorak: Gah, why didn’t I think of that :-D –  Timwi Feb 7 at 16:49

2 Answers 2

While line-height: 1 does tend to look pretty tight for normal source code, something like:

pre { line-height: 1.1 }

or:

pre { line-height: 1.2 }

ought to strike a pretty good compromise between code and ASCII art readability. Thus, I would support (and, indeed, was just about to post a request for) adding this style to our CSS site-wide.

Examples:

To evaluate the effects of this proposal, I took a couple of more or less representative screenshots of both ASCII art and code at various line-height settings. All these screenshots are taken using Chrome 32 on Windows 7. The ASCII art examples are from here and here, while the code is from here:

Line-height: 1.4 (current):

enter image description here enter image description here enter image description here

Line-height: 1.2 (proposed):

enter image description here enter image description here enter image description here

Line-height: 1.1 (alt. proposal):

enter image description here enter image description here enter image description here

Line-height: 1.0 (comparison):

enter image description here enter image description here enter image description here

Based on this quick test, it appears that line-height: 1.1 is close to optimal for ASCII art; at line-height: 1 the line-drawing characters in the second example actually start to overlap a bit. Both 1.1 and 1.2 do look reasonably readable for both ASCII art and code, whereas the current line-height: 1.4 looks absolutely awful for ASCII art, yet not much (if at all) better than 1.2 for code.

Besides, keep in mind that the code sample above isn't really all that representative — a large proportion of the code on this site looks more like this:

,;._1'A',' _|\/A()V`,'''{~+/;._1]0,,(6$2)#:-&40]3 u:'8H1(((((H:f[4ZS4ZP2(RPMAMANf[>CZD[F;I[OVFF;TgfS5aGd[7T9JW4[eG[+Of7ddg?d[.AfT]WUASE=S>bSdgI]cS[RWBYSE?gSeG_X(()WG('

With code like that, line-height doesn't really make any difference to its readability (which some might argue to be zero, in any case).


Edit: This fix is now included in the SOUP user script as of v1.14. The line height I went with is 1.15, which seems to offer the optimal compromise between ASCII art and code readability.

share
    
Just tested this on Firefox 26 / Kubuntu Linux, too, and the results are pretty much the same. 1.1 seems to be ideal for ASCII art, 1.2 leaves slight gaps but still looks pretty good. I tried line-height: 1.15 too, and it looks pretty good, too: no gaps in ASCII line art, but very slightly more room for code than with 1.1. –  Ilmari Karonen Feb 9 at 23:53
2  
I would support a change like this. Either of 1.1, 1.15 or 1.2 seems fine to me. –  FireFly Feb 11 at 14:26

Unfortunately the snippet changes every <pre> tag, which is not always appropriate (it makes genuine source code harder to read, which is why the line-spacing exists in the first place). You can, of course, add javascript: in front and use it as a bookmarklet.

The ideal solution would be to have something like the already existing <!-- language: lang-javascript --> but for ASCII-art. However, I highly doubt that we can get the site developers to add that feature...

However, regarding your suggestion of adding it to the tag wiki excerpt just for informational purposes, sure, we could do that. (I’m currently a bit wary of doing it myself because some users here seem to react negatively to that, so I’ll wait until this thread looks like concensus.)

share
    
We could hook the style to lang-none. This should be fairly reliable. –  Jan Dvorak Feb 7 at 17:32
    
@JanDvorak: The lang-* thingie doesn’t seem to add a CSS class, so I don’t see how you could distinguish the <pre>s... –  Timwi Feb 7 at 17:38
    
A class is added for every language except for lang-none. $('pre:not[class*="lang-"]'). ... –  Jan Dvorak Feb 7 at 20:00
    
@JanDvorak, I rarely see it auto-identify languages, and most people don't use the language tags, so I think hooking to lang-none wouldn't have much benefit. –  Peter Taylor Feb 7 at 20:47
1  
@PeterTaylor would lang-none + tag:ascii-art be a sufficient test? –  Jan Dvorak Feb 8 at 0:20
    
@JanDvorak, yes, that's a good balance point between the pros and cons of the ideas proposed so far. –  Peter Taylor Feb 8 at 9:17
    
@JanDvorak tag:ascii-art has the drawback of disallowing some cases when it'd be useful, like using box-drawing characters to make tables (or, ideed, Timwi's Funciton answers). What about plain HTML <pre>? Is <pre class="lang-ascii"></pre> accepted by the site's HTML whitelist? –  FireFly Feb 8 at 20:54
2  
If you’re going that way, please make it <pre class="ascii-art">, not lang-ascii... –  Timwi Feb 8 at 20:56
    
Well, yeah, that makes sense. –  FireFly Feb 8 at 20:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .