Bugzilla – Bug 114735
Digraph not displayed in configuration
Last modified: 2005-09-12 12:53:07 UTC
I installed in German mode. When installation comes to printer configuration, I noticed that some text is written in German. But the Digraphs (Umlaut) was displayed as a block character. So I saw: Gr[][][][]e in the cofiguration. Yast2 -> Hardware -> Drucker Select a printer -> Filtereinstellungen -> Bearbeiten -> Page Size And then you can see: "Benutzerspezifische Gr[][][][]e"
can you attach a screenshot, please?
Created attachment 48574 [details] screenshot of yast2
I marked the problematic Umlaut in red.
it seems translation string was in some 8-bit encoding and its trying to show it as unicode
Created attachment 48600 [details] fixed cups_de fixed corruptions in /usr/share/locale/de/cups_de
Hi Karl, the only place I could find this was in /usr/share/locale/de/cups_de which is not part of our file set. It looks like it may be generated automatically but we can't find the strings in our resources. However, we fixed the corruptions in the file and I've attached it above if this is of use to you.
Thanks for the report and fix!
This bug is not for me. But I don't know whom to assign it. /usr/share/locale/de/cups_de belongs to the package cups-client but is it really a CUPS bug? Karl, do you know more about what is going on here?
Strange. I definitely set "ke@suse.de" as info provider but somehow it was set to Klaus...
The system default encoding is UTF-8. It might help to make use of UTF-8 for /usr/share/locale/de/cups_de .
Fine that our system default encoding is UTF-8, cups default encoding is not UTF-8. :-) /usr/share/locale/de/cups_de needs to be kept as is, otherwise the webinterface and other things will break IMHO. cups is able to detect which encoding the user has, converts to the appropriate encoding, and then responds with the correct charset. Nevertheless, if it really is latin-1 encoding, then I'm asking myself, why my snapshot is displaying broken two-byte characters for every digraph and not one-byte characters? Therefore I doubt that this encoding problem is generate by the latin-9 encoding cups. Sorry guys, but I strongly think, its the fault of YaST. Assigning back to ke@suse.de
aj please to clarify what is the default encoding on SUSE Linux.
Default encoding is UTF-8. If that causes a problem with cups, we need to convert the file somehow for YaST display. Klaus, please work with the YaST team on this.
ke: please tell me, at which point of the YaST code you were reading the CUPS internal locale settings: - which functions do you use for that? - how can internal data of CUPS accessed by an external program, like YaST? Additional question: why is this the only translated text in YaST, whereas YaST is using English texts for configuration everywhere else? You might notice that the screenshot shows "Media Type", which is not translated to "Medium". But the later is also present in the cups_de translation. This is correct behavior. But why does YaST use some other locale data and not none? Very confusing. Another question: how does it happen, that a 8bit digraph (in latin9) is displayed as a two-byte digraph in YaST?
I'm not a yast hacker.
I assigned this bug to mzugec@suse.de
According to what I found out, it seems YaST tries to recode what it got from CUPS to UTF8 in src/modules/Printerdb.ycp: getPpdFileOptions but I don't understand the special handling of "PageSize" and "Custom" in this code. To test it, you must use a PPD file with a "CustomPageSize" option, e.g.: /usr/share/cups/model/Epson/Stylus_C64-gimp-print.ppd.gz
this translation comes from cups package
Michal: You are the maintainer of the appropriate YaST module. Why don't you just answer the open questions regarding YaST, so we can work on it? Instead you deliver NO answer and especially no content, but reassign the bug to me. Thats not helpful. Please do.
The problem is that /usr/share/locale/de_DE/cups_de_DE provided by cups-client is encoded in ISO-8859-15 instead of UTF-8 When I convert it by iconv it works fine! I will inform to Ines Pozzo on Monday (for RC2)
fixed