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

[Chema Celorio <chema celorio com>]

Michael Sweet wrote:
> "Corporate" users want accounting, security, quotas, encryption, etc.

When talking about "Corporate" needs, I find a big problem.
( the "iguana" issue )

It seems to me that is is not being solved in any free printing
Unix api except for gnome-print. ( well, I can only speak for Linux,
since that's all the unix I know )

+++ *** Please correct me if I am wrong,
since I might have overlooked something.*** +++

Here is the scenario :
Office, network, 36 ppm PCL printer conected to a box acting as a
print server.
Joe, the user wants to print a database report or a worksheet.
[ which is a VERY common scenario ]

Ghostscript drivers as well as other printer drivers can only
talk raster data to PCL printers. And in this scenario, with a 
printer that is doing 36 ppm, we can't print at 600 dpi's because
of the bottle neck between the printer and the print server.
The only way I see that we can talk to a printer at this
speed (and quality ), is if we download whatever font we need and
then send data as vectors (goto's, lines, text).

On the other hand, it doesn't make sense to develop a PCL driver
that translates from Postscript to PCL, since it will be very
hard to have full Postcript support. I am thinking of 
"for loops"
and complex definitions of definitions of definitions, plus the parsing
involved.

I make such a big issue out of this, because I can't imagine
an office with this problem using Linux. I haven't made any
tests yet to meassure the speed problems this creates, but we 
need to be able to support this scenario at the optimal speed.

Even some apps that send raster data to the printer in the 
Windows world, can't be used at medium or high speed;
ie Adobe Acrobat Reader. My HP LJ 6P stopps between
each page because of this when using AAR.

> Sending raw print data to the printing system prevents that
> functionality from being realized, making wider acceptance of GNOME,
> Linux, etc. more difficult.
> 

about this, we have a Meta-driver that can talk non-raw data to 
a print server. And the print server can generate the raw data.

Chema