I'm at the vaguely planning stage of creating an
ascii art toolkit for Perl. I was thinking of Text::YAAAGH for Yet Another Ascii Art Graphics H???? but there's surprisingly little competition.
The [cpan://Text::Graphics] module appears to be
the only one in fact, though there are some
modules to do flowcharts, bar-graphs, tables and
the like.
The features I'd like include
- assemble text art from superimposed layers with transparency.
- nice library of transforms to apply recursively on layers (intelligent rotate, for
example, which does for example tr/db/pq/ for rot180, and automatically moves sub-layers).
- easy to extend to add arbitrary transforms
- nice hooks into figlet, boxes, and the Ascii
graphing/modules
- hooks into an improved version of my Text::JavE module to be able to easily reuse
clipart.
- collision detection for ascii sprites
- Embed animations (possibly imported from .jmov files using Text::JavE)
- ... and of course the previous 2 items imply that this would use something like POE as an
event framework. (And I need an excuse to get my
head around POE).
- ...simple rules to make animation effects based on characters already present in other layers (effectively a 2D Cellular Automata machine!)
- ... and of course a point and click interface
to the text art widgets would be lovely.
There's a POE::Wheel::Curses module, which
would be very cool, except Win32 doesn't really support Curses. (I think
dada wanted to do a Win32::Console write of
Curses, which would be nice).
I spent some time on the way back from YAPC::EU
thinking about this. It's surprisingly difficult
to decide how to represent the layers. I started off assuming that each character would have
- The ascii character
- Background colour
- Foreground colour
- a bit vector of various internal and user-defined flags (mask, 'hot' for collision detection etc.)
Now I'm going with the simple version of an
array of strings, with the mask represented by
an appropriate (e.g. non-ascii character)
This loses flexibility, but makes everything
else much simpler. I think every layer will have
a hash of properties, so additional out of band
information could be stored if required.
I'm a little worried that by refusing to design
colour in from the beginning, it will be
very hard to add in later if needed.
