[Printing-architecture] Meeting notes for 2006-05-17 / LSB 3.2 recommendation

[Printing-architecture] Meeting notes for 2006-05-17 / LSB 3.2 recommendation

[Norm Jacobs]

We spent the vast majority of our meeting time discussing what we would 
like to
recommend for LSB 3.2.  We are also planning on meeting next week at our
normal Wednesday time.

<RECOMMENDATION>

    ESPgs 8.15.1 or later with the following drivers compiled in
             ijs    - InkJet Server
             cups   - CUPS raster
             opvp   - OpenPrinting Vector
  
    Installation Locations
       PPD
          /usr/share/ppd/{supplier}/{manufacturer}-{model}.ppd
             where whitespace and dash(-) are replaced with with 
unserscore(_)
             supplier is the ppd file supplier (gutenprint, hplip, cups, 
epson,
                                                hp, ...)
             manufacturer is the print manufacturer name from the IEEE 1284
                          Device ID
             model is the printer model from the IEEE 1284 Device ID
          Eg.
             
/usr/share/ppd/gutenprint/Hewlett_Packard-hp_color_LaserJet_4650.ppd
             /usr/share/ppd/HP/Hewlett_Packard-hp_color_LaserJet_4650.ppd

       Driver
          /usr/lib/printerdriver/{supplier}/...
             where whitespace and dash(-) are replaced with with 
unserscore(_)
             supplier is the ppd file supplier (gutenprint, hplip, cups, 
epson,
                                                hp, ...)
          /usr/lib/printerdriver/bin/{supplier-executable(s)}
             links to executables in the {supplier} directory

          Eg.
             /usr/lib/prinerdriver/gutenprint/...
             /usr/lib/printerdriver/bin/gutenprintijs-5.0 -> 
../gutenprint/gutenprintijs-5.0

    Installation scripts should be bourne shell and be careful about 
portability.
    mindful of (sed/awk/...) use lsb tools.

    Printer identification
       use IEEE 1284 Device Id.  In particular, the MFG, MDL, and CMD values
       are what we most want to see used (and correctly provided by printer
       vendors).  This should be the EXACT same value for 1284 parallel,
       USB, SNMP, and ultimately IPP query.
             MFG - Manufacturer
             MDL - Model
             CMD - Command Set (PJL, MLC, BIDI_ECP, PCLXL, PCL, PDF, 
PJL, MIME,
                 POSTSCRIPT, ...)

    Possibly require/recommend foomatic for LSB 3.2

</RECOMMENDATION>

    We discussed including PAPI v1.0 in LSB 3.2, but the issue is that 
it needs
    to be shipping in a couple of Linux distros before it can be considered.
    It's likely that this will have to wait for the next LSB.  In the 
meantime,
    Till is working on including it in the Mandrake cooker.

    Norm needs to get some configuration related instructions to Till 
for the
    PAPI and needs to put the Solaris foomatic-filters changes that he 
put into
    the CVS main trunk into the stable branch (foomatic-3_0-branch)

    Till mentioned filters running as an unprivileged user (lp) and 
making sure that
    filters didn't use absolute paths in filter chains.


That's about all I remember and the highlights of Wendy's notes.

       -Norm

Re: [Printing-architecture] Meeting notes for 2006-05-17 / LSB 3.2 recommendation

[Till Kamppeter]

Norm Jacobs wrote:
> <RECOMMENDATION>
> 
>    Installation Locations
>       PPD
>          /usr/share/ppd/{supplier}/{manufacturer}-{model}.ppd
>             where whitespace and dash(-) are replaced with with
> unserscore(_)
>             supplier is the ppd file supplier (gutenprint, hplip, cups,
> epson,
>                                                hp, ...)
>             manufacturer is the print manufacturer name from the IEEE 1284
>                          Device ID
>             model is the printer model from the IEEE 1284 Device ID
>          Eg.
>            
> /usr/share/ppd/gutenprint/Hewlett_Packard-hp_color_LaserJet_4650.ppd
>             /usr/share/ppd/HP/Hewlett_Packard-hp_color_LaserJet_4650.ppd
> 

As some suppliers could have more than one PPD file for the same
printer, for example Foomatic PPDs can exist for one printer used with
different drivers, I suggest to add the driver or whatever is different
in the PPD after the model, separated by another dash. This should
optional but not required. In addition, there should be a directory
level between supplier and PPD for the language:

/usr/share/ppd/{supplier}/{lang}/{manufacturer}-{model}-{extra info}.ppd
/usr/share/ppd/{supplier}/{lang}/{manufacturer}-{model}.ppd

          extra-info can be the driver name or anything else which
          distiguishes PPDs for the same printer model. Spaces have
          to be replaced by underscores, as usual.

Examples:

/usr/share/ppd/foomatic/en/HP-LaserJet_4-hpijs.ppd
/usr/share/ppd/foomatic/en/HP-LaserJet_4-ljet4.ppd
/usr/share/ppd/foomatic/en/HP-LaserJet_4-opvp_pcl5e.ppd
/usr/share/ppd/HP/en/Hewlett_Packard-hp_color_LaserJet_4650.ppd
/usr/share/ppd/HP/de/Hewlett_Packard-hp_color_LaserJet_4650.ppd

[...]
>    Possibly require/recommend foomatic for LSB 3.2
>

Another question: What is "Linux Standards Base" really about? Only
LINUX or also BSD, Solaris, ...

In case of only Linux we could even require CUPS ...

> </RECOMMENDATION>

   Till

Re: [Printing-architecture] Meeting notes for 2006-05-17 / LSB 3.2 recommendation

[Michael Sweet]

Till Kamppeter wrote:
> ...
> optional but not required. In addition, there should be a directory
> level between supplier and PPD for the language:
> 
> /usr/share/ppd/{supplier}/{lang}/{manufacturer}-{model}-{extra info}.ppd
> /usr/share/ppd/{supplier}/{lang}/{manufacturer}-{model}.ppd
> ...
> /usr/share/ppd/HP/en/Hewlett_Packard-hp_color_LaserJet_4650.ppd
> /usr/share/ppd/HP/de/Hewlett_Packard-hp_color_LaserJet_4650.ppd

IMHO, the focus should be on "globalized" PPD files; the DDK will
(soon) provide a ppdmerge utility to make this process trivial.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Publishing Software        http://www.easysw.com

Re: [Printing-architecture] Meeting notes for 2006-05-17 / LSB 3.2 recommendation

[Michael Sweet]

Norm Jacobs wrote:
> 
> 
> We spent the vast majority of our meeting time discussing what we would 
> like to
> recommend for LSB 3.2.  We are also planning on meeting next week at our
> normal Wednesday time.
> 
> <RECOMMENDATION>
> 
>    ESPgs 8.15.1 or later with the following drivers compiled in
>             ijs    - InkJet Server
>             cups   - CUPS raster
>             opvp   - OpenPrinting Vector
>  
>    Installation Locations
>       PPD
>          /usr/share/ppd/{supplier}/{manufacturer}-{model}.ppd
>             where whitespace and dash(-) are replaced with with 
> unserscore(_)
>             supplier is the ppd file supplier (gutenprint, hplip, cups, 
> epson,
>                                                hp, ...)

Don't bother listing CUPS here; we will only be using
/usr/share/cups/model for PPD files supplied with CUPS.

> ...
>       Driver
>          /usr/lib/printerdriver/{supplier}/...
>             where whitespace and dash(-) are replaced with with 
> unserscore(_)
>             supplier is the ppd file supplier (gutenprint, hplip, cups, 
> epson,
>                                                hp, ...)
>          /usr/lib/printerdriver/bin/{supplier-executable(s)}
>             links to executables in the {supplier} directory
 > ...

What kind of printer drivers are to be supported by this?  I don't
see what you are trying to do here?

>    Printer identification
>       use IEEE 1284 Device Id.  In particular, the MFG, MDL, and CMD values
>       are what we most want to see used (and correctly provided by printer
>       vendors).  This should be the EXACT same value for 1284 parallel,
>       USB, SNMP, and ultimately IPP query.

FWIW, device ID information is not standardized in IPP, at least not
yet.  Some vendors put the device ID string in printer-info, but that
gets truncated too easily.

 > ...
>    Possibly require/recommend foomatic for LSB 3.2

-1 from me on that one, we've seen too many problems over the years,
and you really only need Foomatic to support legacy Ghostscript
drivers...

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Publishing Software        http://www.easysw.com

Re: [Printing-architecture] Meeting notes for 2006-05-17 / LSB 3.2 recommendation

[Till Kamppeter]

Michael Sweet wrote:
> Norm Jacobs wrote:
> 
>>    Installation Locations
>>       PPD
>>          /usr/share/ppd/{supplier}/{manufacturer}-{model}.ppd
>>             where whitespace and dash(-) are replaced with with
>> unserscore(_)
>>             supplier is the ppd file supplier (gutenprint, hplip,
>> cups, epson,
>>                                                hp, ...)
> 
> 
> Don't bother listing CUPS here; we will only be using
> /usr/share/cups/model for PPD files supplied with CUPS.
>

On systems with CUPS installed we will set a symbolic link:

ln -s /usr/share/ppd /usr/share/cups/model/vendor-ppd

>> ...
>>       Driver
>>          /usr/lib/printerdriver/{supplier}/...
>>             where whitespace and dash(-) are replaced with with
>> unserscore(_)
>>             supplier is the ppd file supplier (gutenprint, hplip,
>> cups, epson,
>>                                                hp, ...)
>>          /usr/lib/printerdriver/bin/{supplier-executable(s)}
>>             links to executables in the {supplier} directory
> 
>> ...
> 
> What kind of printer drivers are to be supported by this?  I don't
> see what you are trying to do here?
>

IJS drivers like hpijs for example, filters like pnm2ppa, OpenPrinting
vector driver libraries or executables. Extra files of printer drivers,
like ICC profiles for example. This way we especially avoid cluttering
/usr/bin with executables which are not supposed to be started from the
command line. The user "lp" will then have /usr/lib/printerdriver/bin/
in his $PATH (and GhostScript wrappers can also add
/usr/lib/printerdriver/bin/ to the $PATH before running GhostScript.

This is also done with BSD and Solaris in mind where CUPS is not the
default printing system.

CUPS driver scripts and backends must go into /usr/lib/cups/filter and
/usr/lib/cups/backend, either physically or as a symbolic link from
files in /usr/lib/printerdriver/{supplier}/.

>>    Printer identification
>>       use IEEE 1284 Device Id.  In particular, the MFG, MDL, and CMD
>> values
>>       are what we most want to see used (and correctly provided by
>> printer
>>       vendors).  This should be the EXACT same value for 1284 parallel,
>>       USB, SNMP, and ultimately IPP query.
> 
> 
> FWIW, device ID information is not standardized in IPP, at least not
> yet.  Some vendors put the device ID string in printer-info, but that
> gets truncated too easily.
> 
>> ...
> 
>>    Possibly require/recommend foomatic for LSB 3.2
> 
> 
> -1 from me on that one, we've seen too many problems over the years,
> and you really only need Foomatic to support legacy Ghostscript
> drivers...
> 

For a Linux with CUPS one really does not need Foomatic for new drivers.
Raster drivers can be done based on CUPS raster and so they do not need
any wrapper scripts, only a driver executable and a PPD file. Vector
drivers have to be done with OpenPrinting vector (GhostScript built-in
is deprecated). They need a GhostScript wrapper. But a wrapper for only
interfacing a GhostScript/opvp driver with CUPS, a simpler script than
foomatic-rip would serve.

So If we really say LSB is the LINUX Standards Base, we can let the LSB
3.2 require CUPS 1.2.x or newer, ESP GhostScript 8.15.2 or newer (to
serve pswrite, pdfwrite, cups, ijs, opvp), KDE Print, GTK Print, PAPI

If we want the LSB standard to be a standard for all Unixes (then they
should rename to USB perhaps) then we can only require more abstract
standards, especially PAPI, so that ISVs do not need to care about the
spooler used on the destination system. In that case also Foomatic
should be required by the standard, as it interfaces the same driver
(including CUPS raster drivers) to many different spoolers, including
CUPS, BSD LPD, and Solaris LP.

By the way, I have finished making an initial Mandriva RPM. More in a
separate posting.

   Till

Re: [Printing-architecture] Meeting notes for 2006-05-17 / LSB 3.2 recommendation

[Michael Sweet]

Till Kamppeter wrote:
> ...
> CUPS driver scripts and backends must go into /usr/lib/cups/filter and
> /usr/lib/cups/backend, either physically or as a symbolic link from
> files in /usr/lib/printerdriver/{supplier}/.

That's actually not necessary.  You can (and most vendors do, on
MacOS X) put a full path to the filter in the PPD file.

> ...
> So If we really say LSB is the LINUX Standards Base, we can let the LSB
> 3.2 require CUPS 1.2.x or newer, ESP GhostScript 8.15.2 or newer (to
> serve pswrite, pdfwrite, cups, ijs, opvp), KDE Print, GTK Print, PAPI

Agreed.

> If we want the LSB standard to be a standard for all Unixes (then they
> should rename to USB perhaps) then we can only require more abstract
> standards, especially PAPI, so that ISVs do not need to care about the
> spooler used on the destination system. In that case also Foomatic
> should be required by the standard, as it interfaces the same driver
> (including CUPS raster drivers) to many different spoolers, including
> CUPS, BSD LPD, and Solaris LP.

Does Foomatic do file type detection and conversion (i.e. the whole
CUPS filter chain)?

I'm thinking more along the lines of a Solaris-specific interface
script (and a BSD-specific filter script) which emulates/provides
the CUPS, IJS, and OPVP driver interfaces.

We did the equivalent of the CUPS raster path via Solaris interface
scripts and a helper program for 5 years before we released CUPS -
I'm happy to donate the code to the cause.

The CUPS testmime program could also serve this function as well.
I believe that is what Codehost, one of our OEMs, does to support
copiers on Solaris and other commercial UNIX's when running with
the native spooler...

All that said, keep in mind that the functionality of printing
with older print spoolers can be quite limited - that's one of
the reasons we developed CUPS in the first place.  IMHO we should
concentrate on print spoolers that can provide a good user
experience...

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com

Re: [Printing-architecture] Meeting notes for 2006-05-17 / LSB 3.2 recommendation

[Till Kamppeter]

Michael Sweet wrote:
> Till Kamppeter wrote:
> 
>> ...
>> CUPS driver scripts and backends must go into /usr/lib/cups/filter and
>> /usr/lib/cups/backend, either physically or as a symbolic link from
>> files in /usr/lib/printerdriver/{supplier}/.
> 
> 
> That's actually not necessary.  You can (and most vendors do, on
> MacOS X) put a full path to the filter in the PPD file.
> 
>> ...
>> So If we really say LSB is the LINUX Standards Base, we can let the LSB
>> 3.2 require CUPS 1.2.x or newer, ESP GhostScript 8.15.2 or newer (to
>> serve pswrite, pdfwrite, cups, ijs, opvp), KDE Print, GTK Print, PAPI
> 
> 
> Agreed.
> 
>> If we want the LSB standard to be a standard for all Unixes (then they
>> should rename to USB perhaps) then we can only require more abstract
>> standards, especially PAPI, so that ISVs do not need to care about the
>> spooler used on the destination system. In that case also Foomatic
>> should be required by the standard, as it interfaces the same driver
>> (including CUPS raster drivers) to many different spoolers, including
>> CUPS, BSD LPD, and Solaris LP.
> 
> 
> Does Foomatic do file type detection and conversion (i.e. the whole
> CUPS filter chain)?
> 

It delegates file type conversion to a2ps (or another converter, it is
configurable). Norm, feel free to add more sophisticated file type
conversion functionality.

   Till

Re: [Printing-architecture] Meeting notes for 2006-05-17 / LSB 3.2 recommendation

[Michael Sweet]

Till Kamppeter wrote:
> ...
> It delegates file type conversion to a2ps (or another converter, it is
> configurable). Norm, feel free to add more sophisticated file type
> conversion functionality.

Hmm, well, if we mandate CUPS driver support then we'll have the
CUPS APIs around for a CUPS-based file converter, and the amount
of code required for that is extremely small...  I'll see if I can
put together an example along with a System V interface script that
uses it...

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com

Re: [Printing-architecture] Meeting notes for 2006-05-17 / LSB 3.2 recommendation

[Ian Murdock]

On 5/17/06, Norm Jacobs <Norm.Jacobs@sun.com> wrote:
> We spent the vast majority of our meeting time discussing what we would
> like to
> recommend for LSB 3.2.  We are also planning on meeting next week at our
> normal Wednesday time.

I'll be on the call Weds. Sorry I couldn't make the last one.

-ian
-- 
Ian Murdock
317-863-2590
http://ianmurdock.com/

"Don't look back--something might be gaining on you." --Satchel Paige