Comment 17 for bug 303273

The problem lies in the gutenprint package. This can be seen by running the PPD driver directly:

$ LC_ALL=fr_FR.UTF-8 /usr/lib/cups/driver/gutenprint.5.2 cat "gutenprint.5.2://bjc-MULTIPASS-MP150/expert" |egrep -e '(Encoding)|(OpenUI.*StpQuality)'
*LanguageEncoding: ISOLatin1
*OpenUI *StpQuality/Qualité d'impression: PickOne

or by using the cupsGetServerPPD() function:

$ LC_ALL=fr_FR.UTF-8 python -c 'from locale import *; setlocale(LC_ALL,''); import cups, os; c=cups.Connection(); ppdfile=c.getServerPPD("gutenprint.5.2://bjc-MULTIPASS-MP150/expert"); ppd=cups.PPD(ppdfile); os.unlink (ppdfile); print ppd.findOption("StpQuality").text'
Qualité d'impression
(note that we did *not* call ppd.localize() here)

i.e. it is breaking rule 6 of the globalized PPD rules. The gutenprint PPD driver needs to be fixed so that it does not use 8-bit characters in option descriptions for globalized PPDs except in translated descriptions added as part of the extension.

Whether it does this by providing untranslated option descriptions, leaving it to applications to use the ppdLocalize() function to get translations, or by "breaking" its translated strings in the main part of the PPD so that they are 8-bit clean, one way or the other it needs to be fixed.

Regarding reading out a full PPD and writing it back: no, it is not necessary to do this. Please file bugs for whichever cases you can find where this occurs, and it can be looked at later. However, it is not causing the problem at hand.

Regarding keeping PPDs consistent when writing them back: indeed, I realise this, and am working on a fix for this. However, I don't believe it is the entire cause of the bug at hand -- although it may have been the cause for this particular instance (we don't know).