Re: Summary of the LSM Free Software Printing Summit

Michael Sweet <mike@xxxxxxxxxx> writes:

> 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
>
> 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.

Sure.

> 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.

They are far better in 5.0, since you can use the "simplified"
controls in the first group which provide a whole set of sensible
defaults.  What would make things much easier to understand here is if
the advanced controls (controlled via constraints) were
inactivated/grayed out to prevent their use, since manual resolution
of conflicts could be avoided.  With the CUPS web interface, could
javascript be used to enforce constraints?

(I would volunteer, but I know nothing about javascript, sorry).

>> ...
>>   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

Is there any alternative that is compliant with the standard?

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

Is this commonly used?

>      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...

Perhaps the usual locales (fr_FR) etc. would be a better alternative?

>      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.

Agreed.  This was not part of the proposal, but was used in the
example.  If the spec is going to be cross-platform, I guess we need
to make sure it will work on every platform.

>      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 mentioned this.  I really don't want files containing mixtures of
encodings!

> 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: ""

You read my mind!  This is *exactly* what I would like.

> 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.

Yes!  It also makes the PPD generation simpler (possible) since we
don't necessarily have any knowledge of the original encoding of the
message catalogue, and we don't know the preferred output encoding
either.  This avoids all the nastiness.

> 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.

IIRC, I think it was mentioned that PPDs can be used to add PJL job
options.  Are there any other alternatives?

>> ...
>>   - 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:
>
> *cupsICCProfile ColorModel.MediaType.Resolution/Mode: "profile_location"
>
>   *cupsICCProfile CMYK.Photo.600x600dpi/LoRes Photo CMYK Profile:
> "Foo/LoRes Photo CMYK Profile.icc"

Excellent.  The only disadvantage is that the location of the profile
needs to be known in advance, so we can't (in the filter) look at all
of the selected parameters and choose the most appropriate file
ourselves, and inform the RIP of our choice (somehow).

The profiles might also have the potential to simplify our own colour
and channel code, since I believe that the channel splitting could be
done entirely by the RIP using our destination profile.

>> 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! :)

Yay!  Does this leave the parsing of the backchannel data entirely to
the filter, or does the backend process it at all?

>> Paper handling
>> - --------------

> 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...)

I'm not sure what you mean here?  I don't intend the translatable
strings to contain dimensions.  The sizes can be stored in whatever
the ISO/US/UK/whatever spec defines them in and converted to the
user's locale UoM at run-time and merged with the translations.


Regards,
Roger

-- 
Roger Leigh

                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.


-------------------------------------------------------
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