GNOME.org
 

[gnome-print] [Fwd: Desktop ain't no desktop without pretty printing]

Attached is a message I sent to desktop-devel-list@gnome.org.  I really
am wanting to get involved and get printing to be on par with Mac and
Windows.  Preferably, let us surpass them.

Trever Adams



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.


WHY IT BELONGS HERE:
--------------------
Because as the topic says, no desktop is a desktop without wonderful
printing.


WHAT IS MANDATORY:
------------------
Patent Free

Simple but complete (the Einstein principle of simplicity... as simple
as possible, no simpler)

Hooks for color correction for the days it is patent free

Cooperation with Free/Open/Net BSD, Linux, HURD, and any other Unix or
Unix like system (Mac OS X included).

Cooperation with KDE, GNOME, etc.

Hooks for printer status return

Spooler

Print status, even for non-local printers (net-printing)

Printer status (for all printers currently on-line, local or not)


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.

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.


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.


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.

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.


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.


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.

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.

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


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.

PRINT STATUS PROTOCOL:
----------------------
With all the protocols already described and the needs described for
this, this section I don't think needs to be writing.


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.


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.

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


WHY THIS METHOD DESCRIBED HERE IS GOOD:
---------------------------------------
CPU/OS executable/library format aside, the printer drivers/filters are
cross platform.

Drivers/Filters are TUI/GUI/Desktop agnostic.  APPS just have to be
written to open the door for each desktop or program if it is not in a
desktop.

If many platforms follow this same standard, we have critical mass
needed for printer manufacturers to start providing documentation
(printer programming info) and/or code.


WHY I WROTE THIS DOCUMENT:
--------------------------
A while back I mentioned I was going to write some APPS for GNOME.  Some
may thing I am biting off more than I can chew etc., but I am going to
try.  I am just now learning C++ for my CS-BS degree, I have been doing
C for many years though.

I am working on a surveyish like program that needs perfect printing
support.  It probably won't be free software to begin with.  (I need to
support my family some how.)

I am looking at starting a REAL desktop publishing app for GNOME. 
Obviously I need a good printing interface.  I want this app to be
friendly like people expect or are used to from Corel WP/MS Word, but
have all the power of say Frame/Page Maker or say InDesign.  (Anyone
having a requirements document for what a DTP program should do, be
like, please provide it to me.  Anyone who wants this, tell me what you
want or like or need.)  I want this to be GPL from the word go.  If it
could be designed to be OS X compatible (through having the front end
and printing back-ends somewhat removed from most of the code), I would
like that (Mac programmers also on this list, your input on how to do
this would be WONDERFUL).

And the best reason, BECAUSE LINUX AND GNOME ROCK.  So let us make a
great printing system that everyone can use.

If we can copy Mac close enough the critical mass can be made with them
as well, let us do it.

Maybe CUPS does all this, but I don't think so.  We need to get CUPS,
LPD, etc. involved too.

Trever Adams

P.S. Always biting off more than I can chew.  I can help with the spec
for printing and some of the code, I can't do it though.  No time with
trying to wrap up my degree, getting ready to go after a D.C. degree and
other things.

P.P.S. I am now on the list, so CCing me is not necessary.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]