Re: [Gnome-print] Re: [Gimp-print-devel] An introduction to gnome-print (fwd)

[Michael Sweet <mike easysw com>]

Federico Mena Quintero wrote:
> ...
> Generating PostScript is not hard for applications until you have to
> implement the document structuring conventions in every one of them.

Um, it's been done for years, and good printing APIs in toolkits like
GNOME will make this argument useless.  It's not hard for an app to
put out:

    %!PS-Adobe-3.0
    %%Pages: (atend)
    %%EndProlog
    %%Page 1 1
    ...
    showpage
    %%Page 2 2
    ...
    showpage
    %%Trailer
    %%Pages: 2
    %%EOF

which is the minimum required by the DSC; additional comments for
fonts, etc. can be included as needed.

> ...
> but this is hardly friendly to a printing system.  To do any
> meaningful accounting you have to rely on the printer to be able to
> provide you with such information.  Doing it in software would
> require having your own PostScript interpreter with accounting
> capabilities.

Putting printer drivers inside GNOME-print will not fix this.

Also, most consumer printers (those Desktop users you want to write
software for) need a RIP anyways (many can't even print text), so
the accounting info will be available to the printing system via
the RIP.

> ...
> you won't have to keep enormous bitmaps around.  I.e. you need some
> sort of GnomeCanvas-like functionality.

Print preview != printing.  Applications and toolkits can provide
this functionality without using PostScript as the internal format.

> You also don't want to generate a lot of magic PostScript code to
> deal with missing fonts, a particular printer's capabilities (i.e.

Well, that's why you use a PRINTING SYSTEM to include the missing
fonts and set the printer-specific options for your application!

> what if you want to generate a bitmap fill tuned to a particular
> resolution), and other ugliness.  It is easier to do this in your

A good printing system will provide you with resolution information,
which can be used to tune the PS output from your app (not that
making your own CMYK bitmap is a good way to print images)

> Also, people do want something better than the PostScript imaging
> model, the most obvious things being alpha transparency, gradients,
> and antialiasing.  Most applications don't need these and would be
> perfectly happy with the PostScript imaging model; the gnome-print
> looks to them just like the PostScript imaging model.
> 
> [I know PS3 supports gradients and other exotic stuff, but most
> printers are still PS2, so you can't rely on having that
> functionality everywhere; in that case your RIP will have to
> generate them by hand.]

Alpha transparency has limited use in printing; applications that
use it need to composite the final image before printing anyways
(whether the app or the toolkit does it, it needs to be done
before the printed image is generated, right?) so this is a non-
issue.

> [I also know antialiasing may not make much sense when printing on
> black and white printers; color printers are an entirely different
> issue.]

As for anti-aliasing, it has limited use on bi-level devices, which
represent about 90% of the printers in use.  Doesn't matter if you
are using a black-and-white or color printer, if you have "on" or
"off" for each color you don't see a benefit from anti-aliasing
(in fact, you may get lines/text with "spurs" on them)

4-level devices are becoming more popular and benefit slightly from
anti-aliasing, however this doesn't preclude using PostScript...

> Your underlying printing system *still* needs to handle PostScript
> input, since legacy apps will require it.  This does not mean that
> you need to go for the lowest common denominator and screw all new
> nice and pretty applications.

So far you still haven't brought up a single example of printing
that *can't* be done via PostScript.

> As far as where the RIP functionality goes, it is a moot point.
> Applications don't care whether it is loaded as a shared library or
> if metafile-like data is sent over the network to a RIP->imagesetter

Um, *I'd* care if the resident size of my app is 1MB or 2MB, or if
it requires 15 DSOs of just the right version to work.

Also, an application that does all the RIPing will probably appear
to print more slowly than one that sends a PS file to the printing
system and returns control back to the user.

> ...
> It would be good if people from the GIMP and Unix printing system
> side of things could explain what they need.

That's what we've been trying to do...

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mike@easysw.com
Printing Software for UNIX                       http://www.easysw.com