Re: Summary of the LSM Free Software Printing Summit

Patrick, there seem to be some problems with your i18n concept for PPDs.

   Till


Roger Leigh wrote:
> 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



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