[gs-devel] Let device handle overprint

[Igor V. Melichev]

Reposting a failed message.

----- Original Message ----- 
From: "Igor V. Melichev" <igor.melichev at artifex.com>
To: "Bíró Zoltán" <birozoltan at 1024studio.ro>; <gs-devel at ghostscript.com>
Sent: Friday, April 09, 2004 11:26 AM
Subject: Re: [gs-devel] Let device handle overprint


> Dear Bíró Zoltán,
>
> We're open for suggestions about the device interface improvements.
> Particularly your observation about the overprint problem looks reasonable.
> Thank you for bringing it.
>
> In same time please note that adding an additional argument to a C function
> may cause dramatic compatibility problems with some compilers,
> which use the reverse order of arguments.
> The Win32 DLL calling convention is the bright example.
>
> Therefore we can't add an arguments without rewriting all implementation of devices.
> Since the World keeps thousands of devices, being not under our control,
> practically we can't change old prototypes.
>
> Therefore please reconsider your approach so that the prototypes are not changed.
> Adding new fields to structures are allowed.
> Adding new functions are allowed but pretty undesirable.
> Thank you.
>
> Opening a bug report is useful if you can attach specific materials/samples
> to allow us to reproduce the problem with our local machines.
> Otherwise, if the discussion stays in the level of wishes/dreams,
> please continue with gs-devel.
>
> Igor.
>
> ----- Original Message ----- 
> From: "Bíró Zoltán" <zoltan at 1024studio.ro>
> To: <gs-devel at ghostscript.com>
> Sent: Wednesday, April 07, 2004 6:35 PM
> Subject: [gs-devel] Let device handle overprint
>
>
> > Hello,
> >
> >  The current approach for handling overprints may not be the best one -- at
> > least for in-rip separation devices (but for other true color devices as
> > well).
> > More specifically -- as I can see in current implementation -- GS may read
> > pixels back from the device first (in order to perform the overprint), then
> > calls the appropriate pixel-level driver procedure, e.g. fill_rectangle()
> > with the "right" color value(s).
> >
> > However, in many cases, it would be much easier to handle overprint *inside*
> > the device, resulting even in performance increasing, in particular when the
> > color planes in the page buffer are physically separated.
> > Moreover, for "pseudo-truecolor devices", when the driver expects true color
> > information for rendering, but it renders bi-level (by dithering or
> > halftoning) immediately, w/o storing the color itself (see memory saving ),
> > reading back pixels is impossible.
> >
> > In my point of view there must be a flag in the driver structure for
> > indicating
> > whether the driver has to handle the overprint or not. So, e.g.
> > fill_rectangle() may have an additional parameter, say the graphics state,
> > but better just a structure which reflects the current overprint mode,
> > including those for pdf 1.3 or higher. If gs has to handle the overprint
> > mode (instead of the driver), that is, the above mentioned flag is false,
> > the
> > additional parameter simply must be ignored.
> > Due to the flexibility of the C function calling all current devices keep
> > the compatibility, that is, there are no changes necessary in any existing
> > device.
> > I think the above mentioned idea applies mostly for pixel level driver
> > procedures, especially for fill_rectangle.
> >
> > I also want to report this issue as a "bug" (in fact, as enhancement), bu it
> > may be nice to have first a discussion about its feasibility.
> >
> > regards,
> > Zoltan
> >
> >
> >
> >
> >
> > _______________________________________________
> > gs-devel mailing list
> > gs-devel at ghostscript.com
> > http://www.ghostscript.com/mailman/listinfo/gs-devel
> >
>