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

["Trever L. Adams" <tadams-lists myrealbox com>]

Hello Lauris,

It seems we spoke a few months back.  Are you the person doing SodiPodi?

Anyway, my document described all the way from lpd (or replacements) up
to the app layer.  So, some of your comments seem to be invalid by
assuming the opposite, but that is okay.  I am going to go back through
and answer your answers.

On Fri, 2002-02-01 at 07:33, Lauris Kaplinski wrote:
> 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...
> 

Sounds great.  We can only do what we can do.  Besides, discussion can
open many doors.

> > 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...
> 

The more I thought about it the more I agree.  It should be a separate
API.  But it should be clean, well defined, and as standardized across
KDE, Gnome, Unices, etc.

Why can't apps be pretty dang close (99% or better) to WYSIWYG?  Or can
it?

> > 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.

How would it be far more than relatively?

> 
> > 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.

I can understand.  But if we start getting this going, we should try to
get support from others.  Unix has been fragmented in simple ways far
too long.  If we can get some agreed upon MODERN printing standards, it
would sure help.

> 
> > 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.
> 

Unless CUPS has 'drivers' for the printers, it can't know about ink
levels.  Ink-levels are a major part of ease of use.

> > 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.

Sorry.  Yes, this specific thing was a spooler issue.  As I tried to
make clear in the first document, this was an end to end concept
covering all layers.

> 
> > 
> > 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.

Yes, I believe all of these were meant to be the spooler.  Sorry QUEUE
was the closest thing I could get into mind at the time.  However, a
print monitory app in the panel should be able to query and receive this
information from the spooler.

> 
> > 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)
> 

Yes, I agree.  We should do this the Unix way; i.e. use layers and make
each layer do a few things very well.  The nice part I mentioned above
is only for those nuts that want break-neck to printer speed.  I don't
entirely follow that argument because most printers are fairly slow,
they will be the bottleneck anyway.

> > 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:

I only meant things were defined.  I understand that this is quickly
going to become complex.  However, it should be defined well enough new
programmers can quickly catch on.

> - 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)

Yes, these were all included in my concept of that XML file or files. 
It sounds like this is a little more complex than I initially thought,
but no new concepts really.

> ...
> 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.

Sounds excellent.  I was thinking only in a completely modern fashion
with no back-wards compatibility.  If we do this end to end right, it
should have, as you bring up, such functionality.

> 
> > 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:

The defaults were per-user, per-printer with a sysadmin per printer
restricted options set.  It wasn't meant as global at all.

> - 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.

Understood.  Again, I understood this, it is only a bit more complex
than I imagined but I believe can still be done as I suggested.

> 
> > 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.
> 

Again, I only point out such printer specific codes as needed for ink
levels.  I suppose we could split up printer 'drivers' as a filter
(ghostscript and the like) and status (ink levels and such).  This would
allow most things to be on the desktop and few things on the 'server'. 
However, settings still need to be able to have a sysadmin define limits
as well as apps (read status monitors such as the one epson has for
windows) to show ink levels and other such things.

> > 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.

XFT is what? Is this the anti-aliasing or is it the font server?  I can
understand if it can't be the only solution, but it should be a valid
well implemented one!

> 
> > 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.

Then how do the Mac and Windows do it?

> 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)
> 

Is this an and list or an or list?  I can see A and C but not B being
needed.  C being in the filter, not in the app.

> > 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
> 

I think we are largely agreeing.  It sounds like you have some solutions
going.  Anything I can do to help or to spec things out?

Trever Adams