Thank you so much for you comments Paul!
Paul Cunningham wrote:
> 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
> ...
>
I would never ignore your comments... all are very much appreciated!
:) Although, seeing as this is my first time posting to this alias, I'm
not sure how to actually display the latest version of the document. I
have the design doc under sccs control. I could send out an updated
version containing any updates to your comments, but would everyone want
to see change bars? I'm not quite sure how to do this with ascii text
files. Suggestions would be welcome. For now, I'll just (or at least
try to) respond in-line.
>
>
> 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.
>
Thank you for the info Paul... good history to know. I believe this
will be helpful information to know as we are thinking of redoing the
packaging.
>>
>> 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?
Yep! I'll add it in. From the latest discussions, it sounds like the
{language} directory may go away. I'll wait until official notice has
gone out to update the document to take out the {language} directory.
>
>>
>>
>> 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
> |
> |
> -------------------------------------
> | | | |
Good suggestion. I'll redo the diagrams with your suggested method.
>> 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/
Yes... my fingers got carried away with typing "ppd" :) I'll take out
the extra "ppd".
>
>> 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 ?
Yes, didn't quite know how to make it look like a symbolic link. I
believe I mention that it's a symbolic link in the text. Perhaps I
should just take it out of the diagram all together?
>> /
>> /
>> / `-->
>> /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>/ ?
>
If there is a ppdcaches/<supplier>/cache file, then this file, or we
might make a copy of it in /var/lp/ppd/caches/<label>, will be used to
updated the golden ppdcache (/var/lp/ppd/ppdcache) file used by the
printmgr. Yes, the ppdcaches/<supplier>/cache files are fixed. Only
cache files under /var/lp/ppd/caches (in addition to the golden ppdcache
file) can change during run-time. It's my undertanding that with
diskless clients, /var is writeable, /usr is not.
>> | |
>> | | <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)
Yes.
>
>> 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
I originally assumed this would only be a Sun delivered thing. Maybe we
can think about this one. If a <supplier> delivers a new alias entry,
then it could possibly collide with another... this would probably only
happen in the case there is a new <Manuf>. Maybe this is a problem,
maybe it's not. We could treat the manufacturer aliases just as we do
caches by providing a ManufAliases directory where suppliers can deliver
entries. A ManufAliases file could then reside under /var/lp/ppd which
combines all the different supplier entries.
>
>>
>> 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
Yeah, lots of words but no real meaning :) I think what I was trying
to get across was that when a cache file is generated, the golden
ppdcache file will also be updated to reflect the new cache file entries.
>
>> 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?
A temporary cache file will be created to maintain all new changes to a
cache. When all changes to the temporary cache file are complete, then
the new version will replace the original version. If any errors occur,
the original version will be maintained.
>
>>
>> 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?
I'm not married to -a. I just thought it made more sense. To me -a
stands for "add". Perhaps a description for -n could be "new ppd"?
>
>>
>> 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
Eagle eye! Yep again!
>
>> 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?
Yes.
>
>> *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?
According to the current spec, yes, otherwise, they aren't a valid PPD file.
>
>>
>> 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?
>
Again, I believe this is part of the spec. PPD files must contain a
Manufacturer name.
>>
>> 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?
Yes, this where labels come in though. A user can add a ppd file which
is under /usr/share/ppd, but it will be added under /var/lp/ppd/user if
a label isn't specified with -a, or under /var/lp/ppd/<label> if it is.
When the printmgr is brought up and detects multiple instances, they are
displayed with the label 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"
Ah yes.
>
>> 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
I can do that. Although, users already use the lpadmin -n interface to
add a PPD file to the system, so it's not really new. Only the fact
that the PPD file information can now be seen with the printmgr, as well
as the fact that a copy of the PPD file will now be place in the PPD
file repository is new.
>> 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?
Yes, the default is 'user'.
If the ppd file is not copied into the repository, then we cannot
reliably access that ppd file's information. I think this is exactly
why label are so good... it allows a user to specify a unique label to
store there special unique bodged ppd for a unique print queue in their
own special place by specifying a new label. Maybe I'm missing what you
are trying to say.
>
>>
>> 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.
There could be. That's something we want to think about for the
future. Do we supply a new GUI, or just add on to the printmgr. I
could see a tool (ppdsurfer) which would go out and surf the known
resources for a PPD file to match a specific printer.
For now though, this project is just to allow a user to add a PPD file,
and have it reflected in the golden ppdcache file.
>
> 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.
This is a project Wendy is currently looking at.
>
> >
>
>> 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 :-)
Phew. Hope I didn't miss responding to any of your comments! Sun has a
mandatory shutdown the week of July 4th, so this alias might go quiet.
That said, I plan on spending some time catching up on this project, so
will most likely be around anyways.
Thank you again Paul! It definitely helps.
Cindy
