Re: PPD files and /etc/papersize (Was: Question about arch-independent packages and dependencies)
Christian Hudon writes:
> > Another question is: is it possible to ask (or recommend) that after a
> > package is installed/configured, one of my script is run? The case here
> > is that my PPD package does not depend on gs (the PPD files may be useful
> > even without a local gs) but if gs is installed I can arrange them to
> > reflect the gs config (paper size, for example); I can do that in my postinst,
> > but what if gs is installed *after*?
>
> Hmm. My solution:
>
> Create a script called 'ppdconfig' that does just that and place it in
> /usr/sbin.
>
> [...]
That's what I did, in fact (though it's called update-ppd because it will
update all PPD files found on the system). This script is called by the
postinst script if the user allows configuration, and warns that it has to
be called after a gs installation if gs is not present.
About this problem, Guy Maor wrote:
> Not really. Regarding papersize, your program should read the contents
> of /etc/papersize.
I disagree. I think that /etc/papersize really do indicate what kind of
paper size you want to output to. In no case does it necessarily reflect
the default paper size you use. And in fact, one can have a configuration
where say your printer default tray is letter though one wants to produce
a4-sized files. It is then the job of either the tool generating the PS
to try to select the correct size (cf. what dvips does in config.ps---*not*
what PageMaker does!) or to the document manager (in Adobe's sense) or
the printing tool to ensure that the correct paper size/tray will be
selected for the document at print time. This is something that psplpr,
which is what I will distribute, does.
I am wrong on this topic?
> > P.S.: I think the two packages will belong to section 'text'. I am right?
>
> <shrug> Sounds like a plausible guess. But I don't have a clue whatsoever
> as to what a PPD file is.
A PPD (PostScript Printer Description) file describes all features available
on a PS device, conflicts between these features (e.g. you cannot print in
black and white with a depth of 32 bits per pixel with my Canon bubblejet
drivers), and how to select features (i.e. what PS code does select a given
feature).
Given that, a tool can automate the transformation of DSC-conformant
documents so that the features it request will be satisfied at printing
time (or the job will be refused because the features are not available).
If a correctly structure document selects CMYK for my bjc driver, I can
print it on a QMS color printer too, the tool replacingh the bjc-specific
code by QMS-specific instructions before printing.
It is also possible to use a PPD file to present a user interface of
available options to the user, which selects them (say dithering, 24 bits
per pixel and A3 or short-edge binding of pages on a double-sided printer),
the system/printing tool inserting the necessary PS in the document.
This is exactly what NEXTSTEP does with its printing panel. (BTW, I'm
looking for a volunteer to make such a printing panel in Tk by parsing
the output of my psplpr's tool listing the printer features...)
Yves.
Reply to: