I have been considering putting in the ability to use PPD files. However, I once again come up with the copyright problem.
Question: is anybody, anywhere, setting up an archive for PPD files that allows unhidered access to them? No copyright, redistribution, etc., problems? If so, then I will add the magic to ifhp:
Yes, me. Surf to
http://www.linuxprinting.org/download/PPD/
up to now I got the PPDs from HP and Kyocera under free licenses and I am already in contact with several other manufacturers. Everyone is welcome to help me convincing manufacturers to cooperate. Please tell me if you are knowledgeable of other free PPDs and I will add them.
[ printer ] ppd_file /path_to_ppd_file
For making ifhp PPD-aware you should not re-invent the wheel. If there is above directive for the use of a PPD file, you could pass the data stream through foomatic-rip and the stream gets massaged in all settings automatically. One then can even use Foomatic PPDs (they are free under GPL as Foomatic is) and so get all out of all free software printer drivers for non-PostScript printers without starting to build another database about all printers and how the drivers have to be called. So one has one effort of PPD and driver integration for all spoolers and with ifhp wrapped around foomatic-rip one has still the bi-di support of ifhp. And all non-PostScript printers (and so all printers) have PPDs for OpenOffice.org, GIMP, Windows clients (see http://www.linuxprinting.org/ppd-doc.html) and such.
Integration should not be difficult. In the config file for an ifhp-controlled queue could be a section like
[ printer ] ppd_file /usr/share/ppds/HP/HP_LaserJet_4050_Series.ppd PageSize A4 InputSlot Tray3
The option settings here in the configuration are to set individual defaults and should override the "*Default..." lines in the PPD file but not override settings supplied by the user with "-Z ..." or embedded in the POstScript stream.
To do so, ifhp should simply do the following call (when the user does "lpr -Z InputSlot=Tray2 -Z Resolution=1200dpi file.ps"):
foomatic-rip --ppd /usr/share/ppds/HP/HP_LaserJet_4050_Series.ppd -o PageSize=A4 -o InputSlot=Tray2 -o Resolution=1200dpi [tmpfile]
where [tmpfile] is the name of a temporary file containing the incoming data (can even be other than PostScript, then a2ps converts the data). Leave out [tmpfile] to use standard input. More than one [tmpfile] is also allowed. The result goes onto standard output, but you can do the usual re-direction if you prefer another destination. Let this go to the printer without further filtering and the job is printed with all option settings taken into account.
The option settings are supplied with "-o", these settings override the "*Default..." lines in the PPD, but commands embedded in the PostScript stream (for example from OpenOffice.org) override the command line options, so stuff which the user sets in his desktop application has always absolute priority.
So ifhp must add the options which the user supplies with "-Z" on the "lpr" command line with "-o" on the foomatic-rip command line, as "InputSlot" and "Resolution" in our example. "PageSize" was not supplied by the user, so we hand the default setting from the ifhp configuration to "foomatic-rip".
See also http://www.linuxprinting.org/direct-doc.html for calling foomatic-rip stand-alone or out of a script.
foomatic-rip and Foomatic PPDs are absolutely transparent and Adobe-conforming:
- foomatic-rip works with both Foomatic and manufacturer-supplied PPDs.
- due to the compatibility with manufacturer-supplied PPDs all PostScript Level 2 and 3 printers work "Perfectly", independent whether they are listed as such on linuxprinting.org, and (important!) independent of what spooler is used.
- All spoolers get PPD-aware, including LPRng.
- Option settings of PPD-aware applications and clients are correctly executed by foomatic-rip.
- Not only embeddable PostScript commands, but also options for the GhostScript/filter command line and PJL options are fully supported, even if the client is only able to embed settings into the PostScript data stream.
- A bug in the PostScript creation in OpenOffice.org is worked around by foomatic-rip.
- Options can also be set only for selected pages, both via the command line or via embedding of commands in the PostScript data.
- Neither temporary files nor having the whole job in memory is needed by foomatic-rip. All is running as a data stream and in parallel.
- Full support for Adobe-compliant definition of custom paper size support in PPDs.
A lot more, see
http://www.linuxprinting.org/foomatic-db-engine/README
for an overview (in the beginning of the file) and
http://www.linuxprinting.org/foomatic-filters/README
for how foomatic-rip works. And see also the numerous comments in foomatic-rip.
Till
----------------------------------------------------------------------------- YOU MUST BE A LIST MEMBER IN ORDER TO POST TO THE LPRNG MAILING LIST The address you post from MUST be your subscription address
If you need help, send email to [EMAIL PROTECTED] (or lprng-requests or lprng-digest-requests) with the word 'help' in the body. For the impatient, to subscribe to a list with name LIST, send mail to [EMAIL PROTECTED] with: | example: subscribe LIST <mailaddr> | subscribe lprng-digest [EMAIL PROTECTED] unsubscribe LIST <mailaddr> | unsubscribe lprng [EMAIL PROTECTED]
If you have major problems, send email to [EMAIL PROTECTED] with the word LPRNGLIST in the SUBJECT line. -----------------------------------------------------------------------------
