Hi Cindy,
Find some comments on this in-line below. They are all fairly minor, or
nit-picking, so feel free to ignore them if you want to. See below ...
Cynthia Eastham wrote:
>
> I'd like to announce a new, much needed, printing project: PPD Cache
> Management. I am attaching a draft of the design document for your
> review. This is a small project which we hope to complete within the
> next month. In a nutshell, this will allow a PPD file to be added to
> the system, and the new printer information reflected in the cache file
> used by the printmgr to display available printer information the user.
>
> Thank you,
> Cindy
>
>
> ------------------------------------------------------------------------
>
> PPD Cache Manager Project Design
>
> BACKGROUND
> In order to provide support for a wide range of printers, the Solaris Print
> System has the ability to use Postscript Printer Description (PPD) files which
> can be used as a per queue configuration option. A set of gzipped PPD files
> is
> delivered with Solaris in the "system" directory under the PPD repository
> (/usr/lib/lp/model/ppd), as well a private cache
> (/usr/lib/lp/model/ppd/ppdcache) file of the printer information contained
> in each of the delivered PPD files.
>
> On the command line, a user can add, or modify, a print queue to use a PPD
> file
> using the lpadmin -n option. An unzipped copy of this PPD file is saved
> under /etc/lp/ppd and the original path of the PPD file is placed in the
> printer configuration file (/etc/lp/printers/<printer>/configuration). The
> lpadmin -n option allows users to specify PPD files not delivered with
> Solaris,
> just so long as the PPD file path is valid and the path ends with either a
> ".ppd" or ".ppd.gz" extension.
>
> With the Solaris Print Manager (printmgr) GUI, a graphical tool for managing
> printers under Solaris, printer information from available PPD files is
> displayed to assist with the addition or modification of a print queue.
> To quickly display printer information, the printmgr obtains PPD file printer
> information from the ppdcache file.
>
> With the number of printers constantly growing, the set of PPD files delivered
> with Solaris can quickly become out-of-date. While a PPD file not delivered
> with Solaris can be added to the system using the lpadmin -n option, a
> gzipped version is not added to the PPD repository, and more importantly, the
> ppdcache file utilized by the printmgr is not updated with the new PPD file
> information. Since there is currently no means to update the ppdcache file,
> users are frustrated that they are unable to add a print queue for their
> new wizbang printer using the printmgr. See CRs 6236968 "no documented way
> to add PPD file to ppdcache", and 6302561 "gimpprint drivers unavailable/PPD's
> missing/ijsgimpprint missing from release".
FYI, If I remember correctly the reason why no gimp-print ppd files were
delivered (in SUNWgimpprint) was because at the time (2+ years ago) the
gimp-print opensource project had stopped delivering them with their
package - I think the plan was that they would be delivered with
foomatics but not the version that was integrated into the wos at the
time. I think for the Companion CD (CCD) version I borrowed them from
any earlier version of the gimp-print package. I don't know where they
are now because I don't think they are still in the latest foomatic stuff.
>
> One additional note to be made is that the Free Standards Group (FSG)
> OpenPrinting Group is working on standardizing some installation locations
> for PPD files and print drivers so that printer vendors and driver suppliers
> have a common place to install regardless of print service or OS distribution.
> As of the writing of this document, the following would be the location of
> PPD files:
>
> /usr/share/ppd/{supplier}/{language}/{manufacturer}/{manufacturer}-{model}[-{extra}]-{language}.ppd
>
> where
> - {supplier} is the name of the manufacturer or project that supplied
> the files
>
> - {manufacturer} is the manufacturer (MFG) value from the
> IEEE1284 DeviceId
>
> - {model} is the model (MDL) value from the IEEE1284 DeviceId
> language is the language portion of a locale extra is supplier defined
>
> - whitespace and dash(-) are replaced with underscore(_) in {} values
>
> For example:
> /usr/share/ppd/foomatic/HP/HP-LaserJet_4050-o_pxlmono-en.ppd
Shouldn't this example path have a {language}/ dir in it
(foomatic/en/HP) as per above?
>
>
> DESCRIPTION
> This project will provide the user with a public tool (ppdmgr) to add PPD
> files to the to the PPD repository and reflect (update or rebuild) the
> PPD repository modifications in the ppdcache file. lpadmin will be
> modified to exec the new tool to add the PPD file into the PPD repository,
> allow the specification of a "label" (discussed below), and to modify the
> path to the original PPD path in the printers configuration file.
> printmgr will be modified to display the "label" information.
>
> As noted above, this project will be to provide the ability to add PPD files
> to a system running Solaris. The ppdmgr will be able to run as root or lp.
> In the future, this capability can be opened up to non-root privileged users.
> Other possible actions which can be added in the future include delete,
> and query or list actions.
>
>
> The directory tree of the PPD file repository currently delivered with Solaris
> is as follows:
>
> /usr/lib/lp/model/ppd/
> / / \ \
> / / \ \
diagram got me a bit confused to start with, it might be better as ...
/usr/lib/lp/model/ppd
|
|
-------------------------------------
| | | |
> manufacturer/ ppdcache system/ user/
> |
> |
> <Manufacturer>/
> / | \
> / | \
> <ppd_file1> <ppd_file2> ... <ppd_fileN>
>
> where Manufacturer is determined by reading the Manufacturer field from
> the PPD file and <ppd_fileN> is a gzipped PPD file with the extension
> ".ppd.gz".
> This directory structure will be modified to align with the location decided
> upon by FSG OpenPrinting Group, and to allow for package adds and deletes,
> updates, and patches, as well as to allow diskless clients to also take
> advantage the ability to add PPD files and update the ppdcache
> /usr/lib/lp/model/ppd/manufacturer, /usr/lib/lp/model/ppd/user,
> and /usr/lib/lp/model/ppd/ppdcache will no longer be needed.
>
>
> As specified by FSG OpenPrinting Group, all PPD files will now be delivered
> under /usr/share/ppd/<supplier>. Thus, the directory "system" under which
> PPD files are currently delivered with the Solaris, will now be a symlink
> to /usr/share/ppd. With this project, the directory tree of the PPD file
> repository will be modified to include 2 new repository areas: one new
> repository area, /usr/share/ppd/, will be for the delivery of PPD files
> via pkgadd or patch, cache files associated with the delivered PPD files
> (found under /usr/share/ppd/ppd/ppdcache/) as well as a new
typo I think - share/ppd/ppd/ppdcache -> share/ppd/ppdcaches/
> SUNWManufAliases file (see New Manufacturer Aliases File
> section below for more information on this new file), and the other new
> repository area, /var/lp/ppd, will be to store PPD files added using the
> new ppdmgr utility, the ppdcache file, as well as intermediary caches used
> to update the main ppdcache file more efficiently. The proposed directory
> tree
> of the PPD file repository delivered with Solaris is as follows:
>
> /usr/lib/lp/model/ppd/system----
> /
> /
I assume this means symbolic link ?
> /
> /
> /
> `--> /usr/share/ppd/
>
> / / / \ \
> / / / \ \
> <supplier1>/ ... <supplierN>/ ppdcaches/ SUNWManufAliases
> | \ \
> | \ \
> <language>/ <language>/ <supplier1>...<supplierN>
How will a manufacturer's package that delivers a ppdcaches/<supplier>/
cache file append this to the main /var/lp/ppd/ppdcache file used by
printmgr?
Also I assume these ppdcaches/<supplier>/ cache files are fixed and will
not change during run-time (that goes into /var/lp/ppd/cache/<label>/ ?
> | |
> | |
> <Manufacturer>/ <Manufacturer>/
> / | \ / | \
> / | \ / | \
> <ppd_file1>...<ppd_fileN> <ppd_file1>...<ppdfileN>
>
>
>
> /var/lp/ppd/
> / / | \ \ \
> / / | \ \ \
> caches/ ppdcache user <label1> ... <labelN>
> / | \ | \ ...
> / | \ | \ ...
> <label1> ... <labelN> <Manufacturer>/ <Manufacturer>/
> / | \ / | \
> / | \ / | \
> <ppd_file1>...<ppd_fileN> <ppd_file1>...<ppdfileN>
>
>
>
> A directory "user" will be added under /var/lp/ppd to store PPD files
> added by users where no label is specified. In addition, user specified
> label directories will be created under /var/lp/ppd when a user adds a
> PPD file using the ppdmgr with a specified label. For more information
> on "label", see the Introduction of "label" section below.
> The ppdcache file, used by the printmgr, will now be maintained under
> /var/lp/ppd/ppdcache, as well as intermediary cache files used to
> update /var/lp/ppd/ppdcache. These intermediary cache files will be
> maintained under a directory, /var/lp/ppd/caches, for each labeled grouping
> of PPD files.
>
> The following sections provide a more detailed description of the new label
> grouping of PPD files, a new file containing known manufacturer aliases,
> new cache files, new ppdmgr utility, as well as modifications to lpadmin
> and printmgr.
>
> Introduction of "label"
> -----------------------
> With this project, a new term "label" will be used to describe a grouping of
> PPD files. The label refers to a user selected directory name in the PPD
> repository. Thus, every <supplier> directory delivered under
> /usr/share/ppd will automatically become a label. Labels allow
> users to organize their PPD files under a label of their own choosing, and
> to easily identify their label when adding or modifying a printer using
> the printmgr. When a user chooses to add a PPD file under a specified
> label that does not exist yet on the system, a new directory will be created
> under /var/lp/ppd/user with the specified label name. The PPD file will be
> added under the directory with the specified label name.
>
> As stated above, every <supplier> directory under /usr/share/ppd will
> automatically be considered a label name. For example, for foomatic supplied
> PPD files delivered under /usr/share/ppd/foomatic, the label is considered
> to be "foomatic". When choices are provided to the user when adding or
> modifying a printer using the printmgr, the label can be displayed along
> with the PPD file selection to allow the user to distinguish from possible
> duplicate manufacturer entries.
>
> With this project, any labels begining with the string "SUNW" are reserved,
> and may not be specified by users with the ppdmgr utility. In addition,
> the label "all" is also reserved, and only selectable under certain
> conditions. These conditions are discussed in the description of each of
> the options for the new ppdmgr utility below.
>
>
> New Manufacturer Aliases File
> -----------------------------
> In addition, this project will introduce a new private file,
> /usr/share/ppd/SUNWManufAliases, which will be used to keep track of
> possible aliases used in PPD files for the Manufacturer entry. A one
> line entry for each manufacturer in which multiple aliases exist is added to
> this file. Each line will have the form
> <Manuf>|<alias1>[[|<alias2>]...[|<aliasN]]
> For example, the following will be the contents of the ManufAliases file
.... shouldn't that be SUNWManufAliases (and elsewhere)
> to be delivered with this project.
>
> tamarisk# cat SUNWManufAliases
> HP|hewlett-packard
> Okidata|oki
> Minolta|minolta-qms
>
> If a case insensitive search for the Manufacturer entry from a PPD file
> indicates it has an alias in the ManufAliases file,
> then the first entry on the line will be used instead of the alias. If a
> PPD file contains a Manufacturer name of HEWLETT-PACKARD, then the actual
> Manufacturer name used is HP. Note: this is only used to store PPD files
> added to a label using the ppdmgr utility.
Is there going to be a utility the user (printer manufacturer, etc) can
use to update this SUNWManufAliases file to add their own stuff? If so
maybe the file should be in /var
>
> New Caches Directory and Cache Files
> ------------------------------------
> The format of the ppdcache file used by the printmgr will remain the
> same as delivered today, however will be moved from
> /usr/lib/lp/model/ppd/ppdcache to /var/lp/ppd/ppdcache. Suppliers can
> deliver a cache of the PPD files they deliver in
> /usr/share/ppd/ppdcaches/<supplier>. Cache files delivered from suppliers
> will be used to update and rebuild the ppdcache file used by the
> printmgr. If a cache file is not delivered with a supplier's PPD files,
> then one will be generated and located in /var/lp/ppd/caches/<supplier>.
> All labeled cache files which are generated to reflect the printer
> information for all PPD files associated with the label in the PPD
> repository.
Not really sure I understood the above sentence
> In order to update the ppdcache file, intermediary cache files,
> of the same format, will be maintained in a private directory
> /var/lp/ppd/caches. For each labeled grouping of PPD files a cache file
> with the same label will exist under the cache directory. Each <supplier>
> of PPD files will be considered a label. For example, a cache file for the
> supplier "foomatic" PPD files will be maintained under
> /var/lp/ppd/caches/foomatic. The location of the ppdcache file used by
> the printmgr, and updated via the ppdmgr, will be /var/lp/ppd/ppdcache.
> When the ppdcache file needs to be updated or rebuilt, the intermediary
> cache file under /var/lp/ppd/caches are used to update or build the ppdcache
> file efficiently.
>
> PPD Manager
> -----------
> The PPD Manager (ppdmgr) tool will be delivered as /usr/lib/lp/bin/ppdmgr with
> a symlink from /usr/sbin/ppdmgr to /usr/lib/lp/bin/ppdmgr. With this project,
> the user may add a PPD file to the system, optionally supply a label to
> associate the PPD file with, request an update of the cache associated with
> a specific (or all) label, or request an rebuild of cache associated with
> a specific (or all) label.
>
> In general, if an error message is displayed, it will be displayed on stderr,
> and the ppdmgr will exit with and error code. Thus, no logging will be
> performed.
what state will the cache file(s) be left in if an error occurs while it
is updating them?
>
> The proposed synopsis for ppdmgr:
>
> ppdmgr [ -a <ppd_path> | -r | -u ] [ -l <label> ] [-w]
>
>
> The following is a more in depth description of each of the proposed
> options:
>
> To add a PPD file to the system
> -------------------------------
> -a <ppd_file_path>
Just wonder if it would be better to use the same option letter (-n)
that lpadmin uses for this?
>
> Copies the PPD file specified in ppd_file_path to the PPD
> repository, then updates the cache to reflect the change.
> Unless the -l option is also specified, the default
> label the PPD file will be associated with is "user".
>
> Label verification will be performed.
>
> If a reserved label name "all" or beginning with "SUNW" is
> specified, an error message will be printed and ppdmgr will
> exit.
>
> Path verification will be performed.
>
> If the specified ppd_file_path is not accessible, an
> error message will be printed and ppdmgr will exit.
>
> If ppd_file_path does not end in either ".ppd", or
> ".ppd.gz" (gzipped) extension, then an error message
> will be printed and ppdmgr will exit. In the future,
> support for other extensions such as .ppd.bz (bzipped)
shouldn't that be .ppd.bz2
> can be provided.
>
> PPD file verification will be performed.
>
> If the first line of ppd_file_path does not begin with
I assume you mean the first line of the contents of <ppd_file_path> here?
> *PPD-Adobe: "4.3",
> then an error message will be printed and ppdmgr will exit.
Are we sure they will always have this in the first line?
>
> Other PPD file verification/validation tests can be added
> in the future.
>
> The destination path for the copied PPD file will be determined
> by the label (-l) name and Manufacturer name contained within
> the specified PPD file.
>
> The Manufacturer name will be read from the PPD file
> specified with ppd_file_path. If unsuccessful, an
> error message will be printed and ppdmgr will exit.
Are we sure that PPD files will always have 'Manufacturer' defined in them?
>
> Since the Manufacturer name can have multiple aliases,
> the Manufacturer name is an alias in
> /usr/share/ppd/SUNWManufAliases, the actual Manufacturer
> name will be used instead.
>
> The destination path determined from the above steps is
> /var/lp/ppd/<label>/<Manufacturer>/<ppd_file>,
> where <ppd_file> is the basename of ppd_file_path.
>
> Parent directories of the destination path are created,
> if needed. If unsuccessful, an error message will be
> printed and ppdmgr will exit.
>
> If a gzipped version (.ppd.gz extension) of
> the PPD file already exists in the PPD file repository,
> and the gzipped versions are not duplicates,
> a message will be printed, and ppdmgr will exit.
>
> ppd_file_path is copied to the destination path. If
> unsuccessful, an error message will be printed and
> ppdmgr will exit.
>
> The update action (see -u) is then applied to reflect the
> change in the ppdcache file.
Can a user add a ppd file into /var/lp/ppd that is already in
/usr/share/ppd with the same name?
>
>
> To specify a PPD repository label
> ---------------------------------
> -l <label>
>
> The label is used to group PPD files in the PPD repository.
> Opaque to the user, <label> is actually the name of
> the <supplier> directory under /var/lp/ppd, i.e.,
>
> /var/lp/ppd/<label>
>
> or is the associated intermediary cache file under
> /var/lp/ppd/caches/<label> associated with the labeled
> grouping of PPD files in /var/lp/ppd/<label>.
>
> For example, with the following PPD file:
>
> /usr/share/ppd/foomatic/en/HP/HP-LaserJet_4050-o_pxlmono-en.ppd.gz
>
> the ppdmgr would consider "foomatic" to be the label.
> The intermediary cache file associated with the "foomatic"
> label would be maintained in
>
> /var/lp/ppd/caches/foomatic
>
> The specified label must a valid directory name (i.e.,
typo "label must a valid" -> "label must be a valid"
> mkdir() would succeed). However, a label must not be either
> "." or "..", and must not contain a slash '/' character.
> If an invalid label is specified, then an error message
> will be printed, and the ppdmgr will exit.
>
> Reserved label names include any label beginning with "SUNW",
> and may not be specified with -a, -r, or -u.
>
> Another special reserved label "all" may only be specified with the
> -r or -u options.
>
> If reserved label is specified with the -l option, then an error
> message will be printed, and the ppdmgr will exit.
>
>
> To request a cache update
> -------------------------
> -u
>
> Updates the cache to reflect the printer information from
> PPD files in the PPD file repository. This action is also
> performed by default after a PPD file is added to the system with
> the -a option, or after a cache file was removed when a rebuild
> was requested with the -r option.
>
> The label is used to determine which cache to update.
>
> If the -l is also specified, and the label is not
> a reserved label beginning with "SUNW", then only
> the PPD file modifications associated with the
> specified label are reflected in the ppdcache file.
> Entries associated with other labels will remain
> as-is in the ppdcache file.
>
> If the "all" label is specified with the -l label, then
> all PPD file modifications associated with all labels,
> with the exception of any labels beginning with "SUNW",
> in the PPD repository will be reflected in the ppdcache file.
>
> If the -l is not specified, then, by default, only the
> PPD file modifications associated with the "user" label are
> reflected in the ppdcache file.
>
> Cache files associated with the label are updated.
>
> To update a cache, any unzipped PPD files in labels under
> /var/lp/ppd, are gzipped. If a differing gzipped version
> of the file already exists, an error message is printed,
> but continues.
>
> The cache is then sync'd with the list of PPD files
> associated with a label.
>
> A list of PPD files under the label name
> either in /var/lp/ppd/<label>
> or /usr/share/ppd/<label>,
> as well a list of PPD files contained in the
> associated labeled cache file in
> /var/lp/ppd/caches/<label>
> are generated.
>
> These two lists are compared against each other.
>
> If a PPD file is associated with the label, but
> isn't in the cache file list, then a cache entry for
> that PPD file is added to the label cache file.
>
> If a PPD file is listed in the ppdcache, but no longer
> is in the list of PPD files associated with the label,
> then the cache entry is deleted from the label cache.
>
> If a PPD file associated with the label is in
> the cache file list, but the ppdcache file entry
> information is out-of-date, then the cache
> entry is deleted from the label cache and a cache entry
> for the newer cache entry is added to the label
> cache file.
>
> All label cache files associated in the PPD repository are
> concatenated to produce the ppdcache file.
>
> To request a cache rebuild
> --------------------------
> -r
>
> Rebuilds cache. The rebuild is actually made up of two steps:
> remove a cache file associated with a label, then regenerate the
> cache file using update (see -u).
>
> A rebuild is very similar to an update, however, can take quite a bit
> more time a cache file associated with a label are totally regenerated.
> When the cache file regeneration is complete, then the cache files
> associated with all labels in the PPD repository are concatenated
> to produce the ppdcache file.
>
> The label is used to determine which cache to rebuild.
>
> If the -l is also specified, and the label is not a
> reserved label beginning with "SUNW", then the cache
> entries for the specified label are totally rebuilt
> to reflect the PPD information from all the PPD files
> associated with the specified label.
>
> If "all" is specified with the -l option, then cache entries
> for all PPD files associated with all labels in the PPD
> repository are rebuilt except for any labels beginning with
> "SUNW".
>
> If -l is not specified, the default label is "user".
>
> Delete the label cache.
>
> Update the label cache (see -u).
>
> Display Full Path of PPD File in the Repository
> -----------------------------------------------
> -w
>
> If specified with the -a option, and the -a option is
> successful, then the full path of the PPD file that was
> added is displayed on stdout. Otherwise, -w has no affect.
>
> Other ppdmgr notes:
>
> Users will be encouraged to add PPD files to the system using
> either the lpadmin
maybe you should add "(see 'lpadmin Modifications' below)" next to
lpadmin as this is new for lpadmin.
or the ppdmgr utilities. However, if a
> PPD file is copied to the PPD file repository under a
> non-reserved label, then the next time a ppdmgr update action is
> requested, the printer information from the copied PPD file will
> be reflected in the cache.
>
> lpadmin Modifications
> ---------------------
> The ability to specified a label, as well as to copy a file in the PPD
> file repository and update the ppdcache file will be added to lpadmin.
>
> A new command line option, -y, will be added to lpadmin to allow the
> user to specify a label name to associate the PPD file with. The
> same rules that apply for the ppdmgr -l option apply for the
> lpadmin -y option.
if '-y' is not given does it go into label 'user'?
What if the user does not want to add the ppd file into the repository
(eg. it's a very special unique bodged ppd for a unique print q), can
they still do that?
>
> lpadmin will be modified to call the new ppdmgr utility to add the
> new PPD file to the PPD repository in /var/lp/ppd,
> with the associated label and to reflect the addition in the
> ppdcache file. If the call to the ppdmgr utility fails, lpadmin
> will exit with an appropriate message for the exit status received.
>
> The PPD path reflected in the /etc/lp/printers/<printer>/configuration
> file will now be the path of the copied PPD file on the system. This
> path is determined by the combination of the basename of the specified
> PPD file, the label, and the Manufacturer name in PPD file (i.e.,
> the destination path will be
> /var/lp/ppd/<label>/<Manufacturer>/<ppd_file>.
>
>
> printmgr Modifications
> ----------------------
> Since the location of the ppdcache file used by the printmgr will be
> moved from /usr/lib/lp/model/ppd/ppdcache to /var/lp/ppd/ppdcache,
> the printmgr will be updated to get it's PPD file information from
> this new location.
>
> The ability to display label information will be added in the printmgr
> to eliminate the possibility of having seemingly duplicate entries for the
> Printer Driver field when adding or modifying a printer. This label will
> be displayed along with the printer driver. For example, if multiple
> entries exist under the same Manufacturer but different labels, i.e.,
> the a Brother DCP-1200 printer model, then the basename of the label within
> parenthesis will be prepended to the Printer Driver field:
> (foomatic) Foomatic/hl1250 (recommended)
> (Photo) Foomatic/hl1250 (recommended)
>
1. Will there be a GUI tool to do the functionality of ppdmgr? Maybe it
could be part of printmgr.
2. When is the printmgr going to be updated so that a given print q's
ppd file options can be changed, eg. paper size A4, etc.? The CUPS web
admin tool can do this.
>
> In addition, the help application documentation will be updated.
>
> DOCUMENTATION
> The following documentation will be updated to reflect the changes associated
> with this project:
> lpadmin(1M)
> Advanced system administration guide
>
> The following man page will be added for the ppdmgr:
> ppdmgr(1M)
>
As a said all minor and wit-picking stuff, so it looks good to me.
Hope that helps
Paul :-)
