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



On Sat, 3 Jun 2000, Robert L Krawitz wrote:

>    Date: Sun, 4 Jun 2000 01:04:57 +0200 (CEST)
>    From: Lauris Kaplinski <lauris@ariman.ee>
> 
>    On Sat, 3 Jun 2000, Michael Sweet wrote:
> 
>    > Miguel de Icaza wrote:
>    > > ...
>    > > Hence, reinventing a little piece of Postscript every time.
>    > 
>    > Actually, it sounds like you've already done that!
> 
>    But we reinvent it in library. According to your approach, every app
>    should reimplement it separately.
> 
> Having a Caanvas that applications -- even just GNOME applications --
> can draw to that then generates Postscript is very much a worthy
> goal.  Likewise a layer that interprets PPD files to provide an
> abstract interface for applications.  The problem that Mike and I have
> is with your insistence on doing the final rendering yourselves.  Mike
> and I have been trying to explain just why doing the rendering
> yourselves is a bad idea.

The main point in discussion really is:
- whether PS is reasonable metafile format
gnome-print advogates: no
CUPS advogates: yes

Having PS as metafile often results in need to transfer HUGE bitmap twice:
- first - from app to printing system
- second - from printing system to printing device
Huge bitmaps are needed every time, PS does not have necessary functions,
so everything should be rendered in client-side.
AFAIK, even single alpha graphic on top of pageful of text results in need
of sending full page as bitmap - because we cannot guarantee exact font
(pixel-by-pixel) matching between client and server.

On the other side - there will always be software rendering in gnome-print
libs, for:
- overcoming PS shortcomings
- generating pixmap print-previews
The only way to leave this rendering out, would be to create CUPS
driver?, accepting gnome-print metafile, as input. But this driver would
need renderer, closely matched with other gnome-print. So I am not sure,
if it would make things easier at all.

Lauris






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