On Tue, Nov 30, 2010 at 02:02:14AM +0100, Axel Beckert wrote:
> Adam Borowski wrote:
> > htop is a full-screen rather than a line based program. Instead of a body
> > of text with color tags, it produces codes for a terminal with an
> > addressable cursor: instead of lines separated with \n, it says "go to
> > position 0,15; write 'foo' there".
>
> I see, so I'd probably better stick to "classic" screenshots for
> everything which looks like colored curses (sic!). Seems less effort,
> despite being less cool, too. :-)
I admit that in a few cases when I wanted to show a screenshot for a
full-screen program I converted that by hand. If there's a need, making it
automated wouldn't be a lot of work, though.
> Anyway, the blog posting for which I needed that stuff is now online:
> http://noone.org/blog/English/Computer/Debian/CoolTools/ccal.futile
Nice posting! Since color-highlighted output is far easier to read, it
deserves to be popularized.
> BTW: I had to modify the resulting code to not using <style> tags but
> only style attributs as <style> in the middle of an HTML body (because
> the header won't be used on the planets) worked in my blog but got
> posted quoted on Planet Debian.
Good idea. I did it this way to reduce the size of long files, but this
approach has the downside of making the output useless if the header is
lost. It would also make the header massive if xterm-256 support is to be
added.
> I also prefer to use <span> instead of <b>, but that may be because of the
> age of ansi2html.
I did this on purpose, after a request from a blind user. Screen readers do
handle <b> specially (or at least his does); so do browsers which don't
support CSS (like Lynx). It may sound a bit weird to use <b> then redefine
all of its default properties away, right.
There's also an added benefit of shaving six letters per color change, which
can matter for those fancy schmancy every-letter-in-a-different-color
gimmicks:
echo -e '\e[0;31ms\e[1mq\e[33mu\e[32m\e[0;1me\e[33me\e[31mz\e[0;31me\e[0m'
> > [1]. I've seen ANSI color codes in build logs quite a few times. It might
> > be a good idea to process them with ansi2html or another such program. But
> > then, this may unleash a wave of colorgcc use on us :p
>
> Hehe. colorgcc and colormake are candidates for my blogging column,
> too. Interestingly if you use colorgcc together with colormake, the
> output is not colored at all.
From colorgcc's code:
if (! $ENV{"CGCC_FORCE_COLOR"} && (! -t STDOUT || $nocolor{$terminal}))
When it's further piped through colormake, it sees its output is not a
terminal, but fortunately it allows forcing it with CGCC_FORCE_COLOR=y
just like ls requires --color=always.
Auto-disabling color makes sense since colorgcc is often installed as "gcc"
and thus could break things that parse its output.
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
Attachment:
signature.asc
Description: Digital signature