Sorry, I meant portable in terms of other hardware
> platforms that run Linux but not X, embedded systems for
> instance. The situation I had in mind was to run
> matplotlib in a linux PDA (which are becoming more and
> more popular). The Sharp Zaurus, for instance, runs a kind
> of Qt, for which there is no matplotlib backend. All linux
> systems, big and small, have console interfaces. Although
> I think it may be possible to install GTK or Wx on a PDA
> like the Zaurus, It would not be the the best way to go
> due to limitations of memory and other resources. A
> console Backend wold not only be lighter and faster, but
> could go wherever python can go, independently of heavy
> GUI systems.
> Another solution would be a backend for Qt embedded
> library, but it does need framebuffer as far as I know...
> And it's not only PDAs, matplotlib could run on
> cellphones, set-top boxes, industrial controlers, etc.
> Again it's just a thought, I am a big fan of Links...
I'm not familiar with Links....
As far as embedded devices, one possibility is the paint / libart
backend. libart was designed to be small and had the embedded market
in mind, if I recall correctly. A quick google search appears to
indicate that libart is ported to Zaurus. Also, if the embedded
device has a recent cxx compiler, it should be able to compile agg.
The reason I mention this is that it is fairly straightforward to mix
and match an image backend (gd, libart/paint, agg) with a gui toolkit.
Witness GTKAgg, TkAgg, WxAgg (forthcoming) and GTKGD. So it might be
easier (and more general purpose) to implement QtPaint or QtAgg than
it would be to implement a libsvga backend. One thing I've
encountered with the variety of image backends (ps, paint, agg and gd)
is that it is very difficult to support all the features you want on
all the backends.
ps - no alpha channel or antialised drawing
gd - no alpha and a color allocation bug; only 256 colors
libart - a pesky clipping bug that the libart author has been
unresponsive on; no subpixel rendering. no freetype2 support in
agg - no significant 2D limitations.
The same can be said for the native GUI drawing backends GTK and WX.
My push to encourage people to use one of the agg backends for GUI or
PNG is to get around the maintenance hassles associated with trying to
support all these features across many backends. So my preference
would be to 1) implement QTAgg and 2) try and port agg to the embedded
device. The latter may not satisfy the size constraints for embedded
devices (_backend_agg.so is around 600K on my box).
But if you don't think these arguments are persuasive let me know.
Especially if you would be willing to implement (and maintain) a