Re: Summary of the LSM Free Software Printing Summit

Roger Leigh wrote:
> ...
> Patrick proposed a (backward-compatible) solution which would allow
> all PPD properties to be translated within the same file using a
> special fieldname extension to specify the locale, and also have
> comments describing what all of the available options actually do
> (which are also translatable).  He also criticised the lack of use of
> nested option groups and constraints in PPDs, and the lack of support
> of many popular user interfaces to allow easy use of constraints

Subgroups have been abused by vendors like Xerox, who ships PPDs
containing a subgroup for each option.  It would probably be more
useful to get general use of *groups*, as currently most vendors
and driver packages only use the installable option group.

There are other UI things that can be done for existing PPDs as
well, and IMHO we need to concentrate on providing the basics
first (media, orientation, resolution, duplex, copies) so that
the typical usage is as easy as possible.

In short, lets focus on tasks/workflow and not on functionality
and controls.  The current Gimp-Print options are an example of
options that focus on functionality and control, and as such it
can be totally overwhelming for the casual or first-time user.

> ...
>   Note that for the translations of the main keyword it is used
>   as option keyword:
>
>   *InputSlot.French InputSlot/Papier source: ""
>   *InputSlot.German InputSlot/Papiereinzug: ""
>
>   This way it seems to work well for me - i.e. it passes cupstestppd
>   without any warning and it seems not to cause problems for
>   existing tools (i.e. the existing tools like xpp work exactly
>   as before - i.e. the added main keywords with the language
>   qualifiers are simply ignored).

This sounds like a reasonable solution, however there are two
potential issues with it:

    1. InputSlot and InputSlot.language share a common prefix;
       while this doesn't cause problems with CUPS, it *is* a
       violation of the spec - it just happens that the cupstestppd
       program doesn't test attributes for common prefixes at the
       moment...  I'm of the opinion that this is not a serious
       issue, and even if cupstestppd starts checking for common
       prefixes for attributes it can

    2. The spec does not prevent a main keyword (option name)
       from having an option keyword (option choice) of the
       same name.

    3. Using a dotted notation limits the maximum length of an
       option keyword.  Assuming that "Japanese" is the longest
       language name, you go from a maximum of 40 characters to
       31.  This is an issue with some PPD files...

    4. Using the Adobe language names is somewhat limiting in
       that you can't express locales properly, e.g. French is
       not the same in all locales, and so on.

    5. Unless you use UTF-8 (which is not officially supported
       by Adobe in PPD files), you will also want to define the
       encoding for the translation strings in other languages.

I'd like to propose a similar solution which would resolve most
of these issues, namely:

    1. The LanguageVersion is English.

    2. The LanguageEncoding is ISOLatin1

    3. Main and option keywords may not exceed 34 characters (subset
       of what the PPD spec allows)

    4. Translations are specified using a locale suffix of the
       form ".ll_CC" where "ll" is the 2-letter ISO language
       code and "CC" is the 2-letter ISO country code.

    5. Translation strings are encoded using UTF-8.

    6. Main keywords are translated using the following
       form:

       *Translation.ll_CC MainKeyword/translation text: ""

    7. Option keywords are translated using the following
       form:

       *MainKeyword.ll_CC OptionKeyword/translation text: ""

This would update the previous example to look like:

    *LanguageVersion: English
    *LanguageEncoding: ISOLatin1
    *ModelName: "HP LaserJet 9999"
    *Translation.fr_FR ModelName/La HP LaserJet 9999: ""
    *Translation.de_DE ModelName/HP LaserDrucken 9999: ""
    ...
    *OpenUI *InputSlot/Paper Source: PickOne
    *OrderDependency: 10 AnySetup *InputSlot
    *DefaultInputSlot: Auto
    *Translation.fr_FR InputSlot/Papier source: ""
    *Translation.de_DE InputSlot/Papiereinzug: ""
    *InputSlot Auto/Default: "<</ManualFeed false>>setpagedevice"
    *InputSlot.fr_FR Auto/Par Defaut: ""
    *InputSlot.de_DE Auto/Standard: ""
    *InputSlot Manual/Manual Feed: "<</ManualFeed true>>setpagedevice"
    *InputSlot.fr_FR Manual/Manuel mecanisme de alimentation: ""
    *InputSlot.de_DE Manual/Manueller Einzug: ""
    *CloseUI: *InputSlot

Notice that this scheme allows for other main keywords, such as
ModelName, to be translated as well.  We need localized model and
product names for devices like the Epson inkjet printers...

By using UTF-8 as the translation encoding, we can transcode to
whatever locale encoding is needed when presenting the human-
readable text to the user.

> PDF and Free Software
> - ---------------------
>
> Lastly, Ralph Giles talked about "PDF and Free Software".  PDF is set
> to replace Postscript as the common output format of applications in
> the future.  PDF is the default output format for MacOS X
> applications, and PDF printers are now available.  PDF offers a number
> of advantages over Postscript, such as transparency, support for
> images with larger bit depths and embedded colour profiles.  It is

Level 3 PostScript also supports these things, just in a less
convenient way...

> also simpler and more reliable to parse and manipulate than
> Postscript.  For example, counting the number of pages in a Postscript
> document is not trivial, but is very simple for the corresponding PDF.
> Other features such as n-up printing and page rearrangements should
> also be much more reliable than the current psutils--they just need
> writing!

I agree, and I think that the availability of several free PDF
creation libraries in multiple languages (programming, that is)
as well as the toolkit-level support in GNOME and KDE should make
document creation a lot more consistent and simpler for the
developer than to create PS files.

The major downside of PDF is that the support for printer-specific
job tickets is not standardized - that is something that PostScript
can do today.

> ...
>   - CUPS pstoraster and a CUPS filter driver, e.g. rastertogimpprint
>     (currently only a unidirectional pipe).

The current scheme in place (already in use for MacOS X 10.3, and
part of CUPS 1.2 in development) is to define ICC profile attributes
in the PPD file of the form:

    *cupsICCProfile ColorModel.MediaType.Resolution/text: "filename"

where "ColorModel", "MediaType", and "Resolution" are the
corresponding option keyword or blank for "wildcard" usage.
Normally the RIP will automatically select a matching profile,
however the user can also specify the profile manually.

Here is an excerpt from the pending Apple technote:

ColorSync Profiles

 A PPD can specify ColorSync profiles to be associated to the PPD. The 
 system will load and register the profiles when the printer queue is 
created. The profiles would then be used by the system at various times 
 including PDF document spooling, during the printing of remotely 
queued  print jobs, and so forth. Each profile is specified by a line in 
the  PPD in the following form:

*cupsICCProfile ColorModel.MediaType.Resolution/Mode: "profile_location"

where the qualifier ColorModel is one of your PPD's ColorModel option 
values, the MediaType qualifier is one of the available MediaType 
option values and the Resolution qualifier is one of the available 
resolutions. If any of the qualifiers are missing, the PPD file will 
treat the missing qualifier as a wildcard value and will match the 
profile for ALL possible values of the missing qualifier.  Mode is a 
human-readable string that will appear in the ColorSync Utility. The 
profile_location is either an absolute or relative path to the icc 
file. If a relative path is used, the path will be relative to 
/usr/share/cups/profiles/. The ColorSync Utility is the best tool to 
verify that your printer profiles have been correctly registered.

Here are a few examples:
 (1)

 *cupsICCProfile CMYK.Photo.600x600dpi/LoRes Photo CMYK Profile: 
"Foo/LoRes Photo CMYK Profile.icc"

specifies a CMYK profile to use when the selected ColorModel is CMYK, 
printing to a MediaType called "Photo" and at "600x600dpi" Resolution 
mode. A relative path was given for the profile location, therefore the 
 profile is located at /usr/share/cups/profiles/Foo/.
 (2)

 *cupsICCProfile CMYK..600x600dpi/LoRes CMYK Profile: "Foo/LoRes CMYK 
Profile.icc"

specifies a CMYK profile to use when the selected ColorModel is CMYK, 
printing to ALL possible MediaType values and at "600x600dpi" 
Resolution mode.
 (3) If you would like to match color profiles only by ColorModel 
values, your PPD file may have the following:

 *cupsICCProfile Gray../Gray Profile: 
"/Library/Printers/Foo/Profiles/Test Gray Profile.icc"
*cupsICCProfile CMYK../CMYK Profile: 
"/Library/Printers/Foo/Profiles/Test CMYK Profile.icc"

specifies two profiles for Gray and CMYK color models that match ALL 
possible MediaType and Resolution values, with an absolute path to the 
profile.
 (4) Profile matching in the PPD file is done by matching the following 
 qualifiers :ColorModel, MediaType, and Resolution from the most 
specific to the least. Therefore, if examples 1-3 were the ONLY 
cupsICCProfile lines included in the same PPD file, the PPD file will 
match profiles in the following manner:

    1.       (LoRes Photo CMYK Profile.icc) is used if the print job 
options  are CMYK, Photo, and 600x600dpi.
    2.       (LoRes CMYK Profile.icc) is used if the print job options 
are  CMYK, any other media type, and 600x600dpi.
    3.       (Test CMYK Profile.icc ) is used if the print job options 
are  any other CMYK color model print job.
    4.       (Test Gray Profile.icc) is used if the print job option 
has Gray  as the color model, regardless of the other options.

 (5)

 The default qualifiers are ColorModel, MediaType, and Resolution, in 
that order. Developers have the option of changing the second and third 
 qualifiers that would replace the default values. To indicate an 
alternative to MediaType, a PPD needs to use the cupsICCQualifier2 
keyword. To indicate an alternative to Resolution, the 
cupsICCQualifier3 keyword is used. For example, if you would like to 
use the OutputMode keyword instead of Resolution to change the third 
qualifier, you would set the value of the cupsICCQualifier3 keyword to 
OutputMode. For example:

 *cupsICCQualifier3: OutputMode

 If the cupsICCQualifier3 keyword did not exist, the result in the PPD 
 file would have been equivalent to:

*cupsICCQualifier3: Resolution

> Due to the nature of the protocol, which requires bidirectional
> communications, the current unidirectional filter pipeline in CUPS is
> unsuited to this type of driver.  The status feedback from the printer
> indicates how much data may be sent; if this is ignored, the printer
> will not have enough available memory to store the data being sent.
> Having the CUPS backend and filter being able to communicate would be
> very useful, and also has other applications (such as checking the
> printer has enough ink before printing a page).

Backchannel support is in CUPS 1.2, coming soon to a server near
you! :)


> Paper handling
> - --------------
>
> OpenPrinting defines a set of paper sizes and standardised names based
> upon the ISO and US paper sizes, amongst others.  libpaper could be
> enhanced to support the additional metadata and paper sizes.
>
>   ftp://ftp.pwg.org/pub/pwg/standards/pwg5101.1.pdf and
>   ftp://ftp.pwg.org/pub/pwg/candidates/cs-pwgmsn10-20020226-5101.1.pdf
>   (available in a few weeks)
>
> In particular, the support for standardised names, aliases and storing
> the paper sizes in any common unit of measure (while allowing for
> conversion into the type required by the user) are desirable.  For
> each paper, a "legacy name", multiple aliases, and a "self-describing
> name" (including dimensions and units) are defined.  We should
> probably also provide a human-readable name for aesthetic and
> internationalisation purposes.

I would recommend a local message catalog with "generic" unit
strings as well as the standard sizes so that custom sizes can
be correctly expressed in multiple languages (e.g. 8.5x11" for
NA sizes and 210x297mm for the rest of the world...)

--
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Printing Software for UNIX                       http://www.easysw.com


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click