[cups.development] cups filter Xpdf/pdftops seems to produce

Helge Blischke h.blischke at srz.de
Wed Jan 19 05:27:18 PST 2005


Michael Sweet wrote:
> 
> Helge Blischke wrote:
> > ...
> > The setpagedevice operator as used by the said procedure is not
> > device specific but standard in all PS interpreters that support
> > language level 2 and above. But I must admit, since you still support
> > level 1 devices, you have to take a different approach.
> 
> Actually, that setpagedevice command may will not work with several
> Level 2/3 printers from Xerox, which have their own interface for
> printer-specific commands...
> 

Yes and no. Yes in the sense that (by a JobPatchFile statement in the
PPDs)
they set up a page device dictionary configured with a bunch of default
values
(mostly with null values) and collect other key/value pairs in that
dictionary
until the PageSize or PageRegion is requested. This then causes a single
invocation of the setpagedevice operator with the said dict containing
the
collected data.

This is a well known trick to prevent repeated setpagedevice invocations
(think of a BeginPage procedure, which would be called at *every*
setpagedevice
invocation ...), but this only works if this stuff is generated
exclsively by PPD
evaluation *and* the page/media size is configured last.

As for CUPS (at least up to now), I can't see any problems, as 
the defaulst stuff inserted by the pstops filter is emitted at the
beginning of the
setup section, and the pdfSetup procedure is called at the very end of
this section.
Thus, all the defaulting/resetting stuff as defined by the PPD is done,
and the
single setpagedevice afterwards does no harm.

But, never mind, evaluating the BoundingBox or DocumentMedia comment
instead
is certainly a valid approach.

Helge

-- 
Helge Blischke
Softwareentwicklung
SRZ Berlin | Firmengruppe besscom
http://www.srz.de
tel: +49 30 75301-360




More information about the cups mailing list