Re: RFC: A draft proposal for the future of the GNOME printing system.

[Lauris Kaplinski <lauris ariman ee>]

On Tue, 18 Apr 2000, Derek Simkowiak wrote:

> > Ghostscript rasterizing system is not THAT good. Raph has some sample
> > prints which prove this.
> 
> 	I never meant to suggest that Ghostscript is a great rasterizer.  
> (I own an HP 69x, I know that Ghostscript sucks compared to MS-Windows
> drivers from HP).
> 
> 	However, it can be improved upon, and furthermore, it currently
> works with many printers.
> 
> 	I guess I'd ask you to compare it to an alternative--is there an
> alternative?

IMHO much more useful than extending GhostScript would be general-purpose,
standalone PS command language (forth?) interpreter with pluggable
extension modules. Then we can translate back and forth between
gnome-print and PS with relative ease (currently we can do only
gnome-print -> PS)

> > > of the box.
> > 
> > which is NOT the case for most low-cost printers which most people buy.
> 
> 	True.  It was only a minor point.  But I can't think of any other
> widely adopted printer language that is supported by printers out of the
> box.
> 
> > > 	Also, using Postscript is a proven model.  If Postscript works for
> > > GNUStep, I don't see why it shouldn't work for Gnome.
> > 
> > Postscript imaging model misses some stuff. First one to come to my mind
> > is transparency (ie: alpha compositing) which can be simulated in PS 
> > though, I know.
> 
> 	So other than transparency, which can be simulated, what does
> Postscript miss?

Transparency cannot be simulated within the PS, but has to be done
externally anyway (maybe in DPS it can?)

Generally I cannot see much point using PS internally in printing
architecture. PS is GREAT programming language, but only mediocre in its
graphics capabilities (not transparency, no 3D, sucking font-handling
etc.). Its main reason to existence is being the Lingua Franca for
controlling thousands of different printers (via GS, of course) - and it
should remain there - it makes no point using it everywhere. Java
or Python or SVG or whatever other language would do exactly well in
high-level printing architecture. How about printing client sending
JavaScript to backend?

Lauris