Re: Re2: An Idea...

[zucchi zedzone mmc com au (NotZed)]

>   I'd wnat to know, how exact it will be realized...
>   My idea was to get any application (not only for gnome-apps in ideal)
> a _simple_ tool for printing on any printer. And to attract printer
> develpoers (hm... I dont know how to say it right - companies, which
> makes printers and writes software for them) to write UNIX-drivers
> as for OS/2 and Win. Some develpoers of video-cards now are writing
> drivers for XFree86, why printers are worse video-cards???

One good thing about printers is thier feature sets do not change as
often.  And even if they do change, they all basically work the same
way (i'm talking non-postscript printers here).  You generally
rasterise an image (convert it to pixels), and then output them to the
device in rows.  This applies for graphics printers from at least
Epson and HP, Cannon - covers most in use.

It should be possible to describe *most* such printers without having
to have a *separate* driver for each one, or each class of printers.

>   The simplicity of input format is important too (as I think).
>   With M$ Windoze I can let my _simple application_ (such wordpad
> or fractal drawer) to print by adding 10..20 strings of code!
>   In X-Window application I must draw my picture/text/etc in PS
> (which is very different to X), enlarging my code by thousands
> strings, and make my application more complicated. Do I need it?

Thats why gnome has gnome-print.  You call its functions to
do your rendering.  It doesn't match X, but then X's rendering
isn't very fun either (although if you stick to lines and
text it isn't *that* much different).

>   The second: I have HP ColorLaserJet 5. Without PS module. And
> my boss wont buy it (it is not our printer). Using GS I can only
> print grayscale pictures in 300 dpi. Is it good? While this
> printer can print color pictures with at least 600 dpi, I thik
> this result is _not so good_.

I'm sure gs can be tweaked to fix this, but that is another issue.

This isn't very hard to address, the rasteriser just has to know
about the density of the print device/and/or the quality setting
the user wants.

>   The third: application must let user to set any printing options,
> regardless does application know about it, or not (E.g. econofats
> mode). This may be made, if application will get information about
> theese options. In my letter I wrote about it a little. I think,
> its important. By simple query application can know:

I dont think applications need to know all of this ...  if they
do, then the backend isnt doing enough work!  If you have econofats on
for example, why should the application need to know and render any
different?

Users need a way to specify such information (via a dialogue), but why
would an application need to know?

>   1. Which printers can be used for printing (and let users to
 choose).

We provide a widget which queries the user for their choice,
and returns the printer to the application.  It neededn't know the
list itself.

>   2. Which paper can be used on every printer (format and may be
>      specials, such as photo-paper)

Ditto basically, defined by the printer chosen by the user.

>   3. Special options of every printer (econofast mode/ color support/
>      paper trays/ look at print dialog in Win for more!)

Again ...

>   4. May be even load of every printer (will user wait while printer
>      will be able to print?)

This is a spooling issue.  A bit beyond the scope of the application
'printing' api.  Still important of course!

>   I think, that application must be able to know about special
> features if drivers of printers such as formats of input data. If driver
> can print gifs or jpegs or (I think its important!) XImages -- then
> it's not needed to convert image in my application and write
> unnessesary code every time (in every app)!

Well it will only support graphic printers.  So all graphics formats
are supported (well, 1 uncompressed format is, but images can
be converted to this format using gdk-pixbuf i think).

So the application doesn't need to know this.  It shouldn't *need*
to know many of the details at all (that doesn't mean it couldn't 
find out if it wanted to).

>   Please, tell me, what is implemented now and what's planed. Are planed
> features, I told about?

Yes planned features will include most of these, in one form or
another.

Currently the system provides an imaging model - an api whereby applications
can generate print data.  The imaging model is the *same* as postscript,
but that does not mean the application must write postscript itself
(it doesn't at all).

i.e. the application can select fonts, draw text, move the cursor,
draw lines and polygons (filled or not), complete a page, even perform
affine transformations (rotation, scaling, etc) and so forth.

There is a way for the application to request a printer (via a
dialogue), and to request a paper from the user (again via a
dialogue), it can then use the papersize to control its rendering.
But there is currently not a mechanism (that I know of?) to perform
any other device queries (like for example, can this printer actually
print that sized form, duplex, etc), so for what is supported, the
user must supply the right values (i.e. only papersize at the moment).

The application can then 'print' this to one of these printers (currently
the only 'printer' is a postscript generator), or perform a preview
(using a nice zoom/pannable window).  It will also handle multiple
copies etc.

There are a couple of things that need to be done:
 - a query mechanism to find out available printers, printer state,
   printer capabilities (duplex, or output densities for example) and
   so forth, for an application (or widgets so the application can
   query the said data from the user).  Of course the system will
   be multilayered, but the application should hopefully not need
   to know the lower level details.

 - a print driver architecture that can rasterise the print information
   for use with non-postscript printers (there is already a colour
   rastersiser written; for this purpose).  This then needs to convert
   it to the right format for a given printer, and output the
   right control codes to actually print it.

   This rasteriser can also be used to do things like for example,
   generate a series of png files for each page output ...

 - some way to queue the print job.  Using lp?  lpr?  I'm not sure
   what the plans are here ...  It would make some sense to use
   the native print system, but well, lp sux to talk to from a
   program.

 Michael