[Printing-architecture] RE: [Printing-summit] RE: where is th e info on driver directories

Petrie, Glen glen.petrie at eitc.epson.com
Mon Nov 12 08:15:04 PST 2007


< ... snip ... >

> Eh, why not just add an option to /usr/bin/pdpca to list what is
> there.  For your example:
> 
>   pdpca --dev guten --list
> 
> You could even have options to get a list of valid arguments for the
> --dev option.  Why make the user navigate the file system if a tool
> can do it for them?

[gwp] ok, there is a single 'controlling' pdpca application which can invoke
a developer specific version of a pdpca and the 'controlling' pdpca is
location in 'foo' with a actual path added to the system $PATH variable.  

Then the 'controlling' pdpca would have options as

pdpca --list 			: list the possible developers
pdpca --devel foo --list	: list the options for the developers

to actually execute, use

pdpca [-t,-h,-i,-s] --devel foo [option]

this would now locate and execute the requested/actual pdpca 

Now the user/HD does not need to know where the actual pdpca app's are but
the 'controlling' pdpca will.  But again, as you suggest, the system $PATH
variable is updated to include the developer path to their pdpca.   I can
remember if you suggested using a new system $PDPCA variable which would
have the path for the actual pdpca software or just use the system $PATH
variable (which is getting pretty long considering printing is not the only
thing needing path info).

The alternative to using system variables for each developer is to use the
directory structure I have been proposing along with the 'controlling' pdpca
(the 'controlling' pdpca does a $PATH entry).   This way printing things are
collected under one directory and there may not be a need for linking
(things are in known locations which I see a good approach for the goal of
making printing easier on Linux including all aspects for retrieving
capabilities, drivers, etc). 

< ... snip ... >

> FWIW, manufacturer, developer and supplier are three different hats.
> It just so happens that there's usually only one or two heads wearing
> them.

[gwp] Actually I would like to see use establish the definition for the
three entities in context of printing drivers and printers.  To get the
discussion rolling I suggest the following as starting points.

Manufacturer: 
-- The Company, Project, Entity or Person who Company's, Project's, Entity's
or Person's name is affixed to a hardware unit. 

----- This means that an OEM company is not the "Manufacturer".  Although an
OEM company produced the actual hardware; the OEM company name is not
affixed to the product.


Developer:
-- The Company, Project, Entity or Person who Company's, Project's, Entity's
or Person's name is affixed to a software application.

----- This means that an OEM software company is not the "Developer".
Although the OEM company produced the actual software; the OEM company name
is not affixed to the product.


Supplier:
-- The Company, Project, Entity or Person who distributes the hardware or
software but may or may not be the Company, Project, Entity or Person who
Company's, Project's, Entity's or Person's name that is affixed to the
hardware or software.

----- RedHat can be a supplier of Epson Printer Drivers but they are the
Developer or the Manufacturer.  However, when someone refers to "the Epson's
Printer Driver" which may be produced by an OEM or subcontractor for Epson
but Epson affixes their name to the driver; then, Epson is still the
Manufacturer and Developer along with be the possible Supplier.

So for the pdpca application it is not Supplier, but the Developer that is
being specified. 

If the actually printer is being specified, then it we would refer to the
Manufacturer.

Glen



More information about the Printing-architecture mailing list