Re: [school-discuss] Tux Print?

[Bill Kendrick <nbs@sonic.net>]

On Fri, Nov 05, 2004 at 02:40:45PM -0500, Doug Loss wrote:
> Bill Kendricks, I remember a while ago that you and I (and a few others) 
> talked about the possibility of creating a "Tux Print" program to fill 
> the space in the OSS world that PrintMaster and PrintShop Pro fill in 
> the Windows world.  As I recall, you thought it would be a fairly easy 
> thing to do.  I know that you've had your hands full with other things, 
> but do you have any other thoughts on this or suggestions for people who 
> might be interested in trying to create something like it?

Hey Doug.  Yeah, sorry for all my half-started attempts at projects. ;^)

I'm beginning to think that a different environment might be better for
the two apps I was coming up with: Tux Print (described fairly accurately
above) and Tux Writer (a word processor for kids).

I think rather than being based entirely on SDL and friends, it makes more
sense to use a more app-oriented library like GTK+, Qt or even FLTK.
(It doesn't make sense to reinvent such complex GUI widgets.)

Tux Print was the main project I was going to work on first, but it
initally got held up because I really wanted SVG support.  An SVG rendering
library for SDL has been started, but last I saw, was nowhere close to
finished.  (I think the main coder and myself were the only folks interested!)

Tux Print needs SVG (and TTF) support because we're talking about
printing things that could span numerous pages (like a poster made of 3x3
sheets of US Letter or A4 or paper, or a banner made of 10x1 or 12x1 sheets).
Bitmaps would either need to be HUGE, or would just come out ugly and
pixellated.

Also, since the main PURPOSE of Tux Print is to print, it needs to be very
robust and mature when it comes to talking to various OS's printing systems.
My original trick of "pngtopnm | pnmtops | lpr" in Tux Paint for Linux just
isn't going to cut it, I think. :^)


I think the main goals of a Tux Print project should be:

  1. Openness (GPL or other Open Source license for the code AND artwork)

  2. Portability (Linux, Windows, Mac OS X, Mac OS classic, etc.)

  3. Internationalization

  4. Vector graphics support (SVG clipart and TTF fonts)

  5. Ease of use (try to keep the interface more like Tux Paint and less
     like OpenOffice.org; gear it to kids aged 5-10 or 3-8 or something)

  6. Ease of installation & configuration (for the parents and teachers
     who have better things to do than fight with some program for their kids)


#1 is pretty much obvious, with the folks we've got out on these lists
and in the greater Linux and FLOSS communities.  Done.

#2 was going to be handled (for UI at least) by SDL, but again, I think
a slightly more mature and robust GUI library should be used, rather than
rolling our own.  It COULD be done in SDL, but #3 and #4 are affected.
If it's done with a GUI library, it MUST be something that runs 'everywhere.'
You just can't know where your OSS app will end up! ;^)

#3 has been /relatively/ easy in Tux Paint, after much support from the
likes of Karl Ove Hufthammer and Mark K. Kim.  There are places where it
fails, though, like the 'Text' tool's input, and support for some of the
more complicated (to render) languages. :^/  The popular GUI libraries
like Qt and GTK+ would help here.

#4 was my initial sticking point. (Then I got busy and moved and
distracted, as usual.)  If I had a 100% working SVG renderer for SDL
today, I might actually start finishing up the /current/ Tux Print code.
But, once again, our other GUI friends actually DO support SVG already!
(SDL, of course, already does TTF, so that's dealt with.)

#5 is very important to me.  My thought is that the Tux* apps should be
for the very youngest kids.  If older kids want to mess with them, they
can, but by the time they get older, they can probably handle the 'grown up'
apps like The Gimp and OpenOffice.org.  The youngest kids don't have much in
the way of these kinds of apps, though (in the Linux & Open Source realm).
I think I did a good job making Tux Paint functional and easy-to-use
using SDL, but it's just a painting canvas.  Tux Print needs to be a /little/
more complicated (but again, not MUCH more!)

One fear I've had regarding Tux Print and Tux Writer using pre-existing GUI
libraries is that those libraries would add unnecessary complexity.
KDE apps benefit from right-click and menu bars and so forth, but something
like Tux Print should look like a very simple PDA app or a game... that's
how I designed Tux Paint. :^)


Anyway, I'm starting to ramble. :)  Does the above help in any way? ;)

-bill!
bill@newbreedsoftware.com                            New Breed Software
http://www.newbreedsoftware.com/               Tux Paint 0.9.14 is out!