On 11/05/2010 04:10 AM, Luca Capello wrote:
Hi there! On Wed, 13 Oct 2010 02:21:35 +0200, Luca Capello wrote:On Mon, 27 Sep 2010 23:16:49 +0200, Till Kamppeter wrote:On 09/27/2010 06:53 PM, Luca Capello wrote:4) I am not sure debian/local/ is the right place for non-upstream files, but I should admit that this is the first time I heard about it and I can not find any documentation about that. Nevermind, I have added the two non-upstream PPDs. BTW, conceptually speaking, Ubuntu debian/rules misses the command to compress these two files, given that this action is hidden in the 'Add "*cupsFilter" line to accept PDF input data to the PPDs' block.Please go ahead and correct also this. I will overtake the version with your corrections to Ubuntu.Given that I still have not understood what the 'Add "*cupsFilter" line...' does, no corrections on this matter have been made yet.Still valid.
This makes the PPD files allow PDF as input format. This way the print queues integrate with the PDF-based printing workflow which is implemented in Debian and Ubuntu. PDF-based printing workflow means that applications send PDF (and not PostScript any more) to CUPS when the user prints his document. CUPS uses PDF as standard file format. Everything coming in which is not PDF (like PostScript output of legacy applications) is turned to PDF at first, then a pdftopdf filter does rearrangement of the pages (if the user selected N-up, reverse order, selected pages, ...), and after that PDF is sent to the driver. See
https://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdfasstandardprintjobformat I have seen may packages which use debian/local/ to add non-upstream files.
5) - debian/foo2zjs.postinst: Automatically update the PPD files for existing queues to the versions supplied with this package. - debian/control: Add dependency on cups and cups-client to ensure that automatic update of the PPDs of existing print queues works. I do not understand the purpose of this action, but I should admit that I am not a CUPS expert and I do not know how other drivers behave. However, given that in Debian the PPDs are configuration files (see <http://bugs.debian.org/549673>), I would expect dpkg to prompt for any modification, is it so in this case?Still valid.
Often the driver has changes which require also changes in the PPD files, for example if options are added or additional settings for an option. If you simply update the package, the driver executables get replaced by the new version and also the PPD files under /usr/share/ppd/, but not the PPD files of already existing print queues in /etc/cups/ppd/. Rick Richardson, the upstream author of foo2zjs simply tells in his ChangeLog to remove and recreate the print queues. Typical distro users neither read the upstream ChangeLog of a package, nor do they not know that their queues need to get manually recreated to make the update complete. They even often do not know that the foo2zjs package is their printer driver. Therefore I let the package do the dirty work as doing a really complete update by letting the postinst script updating the PPDs of the already configured queues in /etc/cups/ppd/. The only configuration in these files are the default settings (lines starting with "*Default..."), The rest of the files are printer-specific and no user configuration. The automatic update is done with CUPS' "lpadmin" command line utility which preserves the default settings. This way the user has always the correct PPD for his driver (works on both up- and downdate of the package) and his default settings do not get lost. Printing will "just work" for him.
10) - debian/rules: Add /etc/papersize support, and modify all /usr/bin/foo2*-wrapper scripts to handle custom page sizes correctly in the PDF-based printing workflow. - debian/rules: Add "*cupsFilter" line to accept PDF input data to the PPDs. - Support for the PDF printing workflow: o "*cupsFilter:" lines for PDF input in the PPDs o Let wrapper scripts read custom page sizes also from the command line and not only from embedded PostScript commands. I do not understand these modifications, would you mind explaining them, please? I do not feel comfortable in applying something I do not understand, sorry...Still valid.
There are awkward foo2...-wrapper scripts, all identical except a few lines. Why did Rick not make one file with function definitions, source it into all the foo2...-wrapper scripts and use the functions? This way it is awkward to make patches doing the same change in each of the scripts. Especially more or less once a year (every second Ubuntu release) there is a new driver with a new foo2...-wrapper script in the package. Easy to overlook when having patches. Therefore I use Perl magic in the debian/rules file to do these identical changes on all the scripts. Also doing the same change on all PPD files is rather awkward by a patch and I do also this by Perl Magic in the debian/rules file.
1. Add /etc/papersize support: This change on the foo2...-wrapper scripts makes the default page size being taken from /etc/papersize, like all programs which use libpaper do, too. This way one has a reasonable default paper size and not Letter which is used only in two countries on the world.
2. The changes foir the custom page size handlin in the foo2...-wrapper scripts got already accepted upstream, therefore these are not done any more in the debian/rules file. So ignore the phrases
and modify all /usr/bin/foo2*-wrapper scripts to handle custom page sizes correctly in the PDF-based printing workflow. and Let wrapper scripts read custom page sizes also from the command line and not only from embedded PostScript commands. in the list of Ubuntu-specific changes.About the insertion of "*cupsFilter:" lines to the PPDs see the section about the PDF printing workflow above.
I hope everything is clear now. Till