Re: [gnome-print] [Fwd: Desktop ain't no desktop without prettyprinting]

[Lauris Kaplinski <lauris ximian com>]

Hello Trever!

On Thu, 2002-01-24 at 10:54, Trever L. Adams wrote:
> Below is my rantings and ravings (I may be mad, but at least I can
> communicate my insanity... no, not as in communicable disease) about
> Unix printing.

OK, I'll answer as much, as I know...

> WHY WINDOWS RULEZ: (the Z is mockery)
> -------------------------------------
> One of the nice things for a programmer on windows is that its printing
> system has a similar interface to the normal raw graphics (GDI for
> both).  At least this was true the little printing programming I did
> around 5 years ago (Windows 95).  This is nice, however it may not be
> necessary.

This is double-edged sword. While excellent for simple needs, it
tends to pose limits for HQ output/display. So I prefer printing and
interactive display to have different API-s - no program can be
100% WYSIWYG, and having different optimized API-s allows it to
choose, whether to treat printed output or on-screen data as master
display, and the other one as mere approximation...

> As a user, all printer functions are 'default-able' - i.e. you can
> create the defaults you want for the printer.  You can also change those
> defaults at time of printing (local or net printer).  It is very WYSIWYG
> if the APP is WYSIWYG.  You have color correction.  You have wide
> printer support.

Yeah, the model is realtively good.

> GETTING VENDOR SUPPORT:
> -----------------------
> Chicken and the egg time.  Windows has vendor support through coercion,
> market factors (read critical mass of users), and MS writing the drivers
> themselves.
> 
> If we could work with all those listed as needing cooperation of in the
> Mandatory section of this document, we may soon have the critical mass. 
> However, we need the infrastructure first.  We may want to get HP,
> Epson, Canon, and a few others involved in making the spec.

I do not believe, starting so will take us anywhere. We just have to
use existing and supported technologies (i.e. gs, CUPS...) and write
whatever glue code, frontends needed.

> PRINTER STATUS:
> ---------------
> Currently Windows takes the prize here.  Linux has no printer status
> even for local printers in apps.  We need to know if the printer is out
> of paper.  We need to know what the various ink levels are.  These
> should be available at a reasonable rate.  Some documents may be too big
> so, this should be every few pages.

IMHO CUPS does such things. The probelm is missing feedback with 
application.

> Preferably this status is in the queue program (local and/or remote) and
> available for apps who wish to query.  The queue should also allow
> levels to be set with an email address to send alerts to.

IMHO things like email alerts belong to spooler (sysadmin) world. Adding
such features to common desktop printing dialogs seems terrible feature
bloat to me.

> 
> QUEUE STATUS:
> -------------
> Again, Windows takes the cake. (Please note, Mac usually does well in
> all things that I credit to Windows.  Exception may be the programming
> part as I have never done Mac programming.)
> 
> We should have a hook that an app can talk to the QUEUE manager on and
> get what page we are on for printing, what document, who sent it, what
> machine it originated from.  Obviously, this means the QUEUE has to be
> semi-aware of the device and the input to it.  Either that, or our QUEUE
> protocol separates pages.  A percentage of size completed would be nice
> as well.  I am not sure Windows does the page thing anymore, but KiB and
> the percent done can easily be accomplished as well as the rest.

OK, the previous notest stand here as well.

> COMMON PROTOCOL BETWEEN PROGRAMS AND PRINTER:
> ---------------------------------------------
> Windows has its printing GDI.
> Unix and Mac seem to all have Postscript or PDF.
> 
> It would be nice to have fewer intermediary steps between the program
> and the printer than we have now.  However, if this is to work with text
> based programs as well as Desktop or GUI programs and environments
> (think Star Office, AbiWord, KOffice, KDE and GNOME), we must have a
> common preliminary output mechanism.  This mechanism could be abstracted
> even further for programming ease, such as a GDI specific to KDE and
> GNOME, or maybe one they share.

This certainly is NOT the case. We do not necessarily want fewer
intermediary steps:
- applications want print preview
- components have to render printout into master documents
- different layouting rules should be applied at different
  steps of pipeline (from rotated print to label generation)

> Unless there are some deficiencies (no Alpha blending, no anti-aliasing
> or other such majors that may or may not exist) in Postscript that we
> can't work around, maybe we should stick with the filter router between
> program and QUEUE (think GHOSTSCRIPT).  However, this having a separate
> printer defined for the same device for each paper size and difference
> in settings is CRAZY.  We need that MS Windows ease of use here.  Each
> printer MUST only have one QUEUE.  The filter can be queried and it
> should return an XML doc that the APP can use to select the settings
> (paper size, quality of output, paper tray, double sided printing...
> whatever the printer offers).  This DOC should be a data file that is
> localized.  The APP then says, QUEUE here is this DOCUMENT, please print
> it using these settings.  The QUEUE would say
> FILTER/PRINTER/DRIVER/WHATEVER here is this DOCUMENT please print it
> using these settings that you understand.

OK, this somewhat resembles preliminary gnome-2 printing configuration
system. But this cannot be restriced only as so simple communication
between queue and application. Gnome-print 2 implements it as synthetic
configuration tree, which will cover additional things, like:
- transport provider settings (i.e. the type of queue used and its conf)
- driver settings (level of PS used etc.)
- document layout settings (paper size, margins, orientations...)
- gui settings (way to add customized configuration widgets)
...
Basically - as queue can be something as simple as lpr, we need hooks
to do all processing application side. For more intelligent queues
some processing may be delegated down the pipeline.

> Those settings should be allowed to be 'defaultized' by the user so that
> they can have one they usually use always ready.  They should be able to
> select those settings within a range approved by the printer owner (net
> admin or what not).

This is terribly complex problem and IMHO the major blocker in
gnome-2 print config development. In addition to defaults, you
have to deal per-printer constraints, like:
- set default Printer A, A3, 600dpi
- set printer B
Now, it may be case, that due to memory limits, printer B can
do A3 only 300dpi.
So the configuration data happens to be extremely dynamic and
all kinds of values interconnected.

> STATUS PROTOCOL:
> ----------------
> Again, each printer driver/filter needs to provide an XML file
> describing the widgets, text describing the widget, value ranges for all
> the status it can return.  (This file is much like the settings
> available XML file the QUEUE/FILTER provided in the Printing Protocol
> above.)  An app that wishes to show status requests information from the
> LOCAL QUEUE manager.  It forwards the requests and responses between
> this app and the remote printer (in case of network printing).  In local
> cases it handles the requests and responses itself.
> 
> APP ?> Printer, what status can you tell me?
> Printer !> APP, I can tell you: Out of Paper errors, ..., ink levels,
> printing/not printing at the moment
> APP ?> Ink Level please
> Printer !> Red is 70% full, Blue is 50%, Green is 27%
> 
> Of course, the LOCAL and REMOTE QUEUE managers would be in between the
> APP and the Printer there.
> 
> The possibility on all STATUS Protocols is that the LOCAL QUEUE tells
> the APP how to talk to the REMOTE QUEUE so the LOCAL one can go to
> sleep.

Hmmm...
Actually I'd integrate status with settings into single tree
kept locally by printing library. The task of updating values
(to be more precise - to provide interface for reading updated
values) would remain to queue/printer/whatever driving modules.

> FONTS:
> ------
> However this all works, the APP should be able to define fonts and
> GNOME, KDE, the QUEUE, whatever, should translate those as necessary. 
> This is for WYSIWYG output.

Yeah, that needs XFT extension. As long as gnome has to support
older systems, it cannot be the only solution.

> WHY GNOME PRINT STINKS:
> -----------------------
> Heck, you can't even guarantee the WYSIWYG-ity of AbiWord output because
> Gnome Print doesn't use the same fonts as X.  You get pages all screwed
> up and some parts never get printed.  Evolution is in the same boat.

Even using the same physical font file does not give you too much
WYSIWYG, if target resolutions differ too much.
But the only way to get near WYSIWYG display with gnome-print are:
- use XFT extension and upload fonts by application
- implement font server inside app and provide legacy X fonts
- do rendering client-side (with aa canvas or similarly)

> APPS can't know print limitations (such as on most Epsons and many older
> HP printers, you can't print closer than .57 inches to the bottom of the
> page).

Yeah, that is one thing they should read from print config data, along
with paper size etc. (paper size is printing subsystem setting, because
available sizes depend on chosen printer).

Best wishes,
Lauris Kaplinski