Gerry Weaver wrote:
> 
> 1. Is printing support a priority?

Probably.

> 2. If so, where does it stand in relation to other work items?

It is at the top right now, albeit fltk2 suffers greatly from stability.
 It seems developers are planning to add printing to fltk1 first and
call that fltk1.5 or so.  For that to happen, fltk1 needs utf8 first,
which is still in progress, unlike 2.0.

> 3. Which core team developer would be the best candidate for the job?

Michael Sweet on the unix side.  He wrote the CUPS book, and has tons of
experience in postscript.  Only problem is he is an fltk1.1 only
maintainer so far.
On the windows side, probably Matthias, as he is the only developer that
won't scream in pain of using windows :)  However, Matthias'
applications are not concerned with printing, so not sure if he is
something that he'll jump into.  He also works in 1.1 only.


> 6. Does anyone have even a rough idea of a design?

There's basically 4 problems to tackle:
        - A common GUI for printing - the easy part. See:
        http://www.easysw.com/~mike/uiexperiments.html
        - A back-end communicating with the OS to detect what printer is
        available (locally and on the network) and what options it has
        at its disposal (is it color, bw, etc).  A headache, as each
        OS is different.
        - The actual printing - either by communicating with the printer
        driver directly, going through some library or just outputting a
        common format (for at least some printers) like postscript.
        A headache, but if you stick to just postscript it isn't so bad
        (that's what Fox does, for example).
        - API exposed to FLTK.  This is simple but for fltk is also
        a big issue.  FLTK's api, even in 2.0, is not printer friendly.
        Most draw functions reside on the global namespace, instead of
        being part of canvas class or similar, which means
        that either you have to change those functions whenever some
        global printing pointer is set (ugly, slow and not multithread
        safe) or the api will need to be broken (or a separate new
        api provided).
        Also most coordinates in fltk are pixel based, which is also
        a big headache for printing.
        Fox, Qt and Ultimate++, imo, do this better.



-- 
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy

_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk

Reply via email to