Description of problem: ooffice printer property setting is scrambled in Japanese environment. Version-Release number of selected component (if applicable): openoffice.org-1.1.2-10 How reproducible: Everytime Steps to Reproduce: 1. Japanese environment 2. oowriter 3. Ctrl+P 4. Press the property button in the dialog 5. SCRAMBLED Actual results: Human unreadable Expected results: Sane Japanese Additional info: kprinter has a similar bug. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130417 And the OOo's printer dialog itself is not translated. That's another problem. Sun is never responsible for Red Hat or Ximian customized part translation, and Ximian is nothing for i18n.
I see this. We are delivering the spa645*.res file for japanese translations, and I see the translations in the source. Not sure why its not getting into the dialog though. Note that the values in that properties dialog come directly from the PPD, which comes from CUPs. We may have to translate the PPDs if that can be done.
It may be that padmin/source/helper.cxx:PaResId(ULONG nId) is the culprit and is failing to find the current language correctly.
Created attachment 106301 [details] Patch to fix UI language in printer properties
Yukihiro: Can you download this file and drop it into /usr/lib/ooo-1.1/program directory and see if it fixes your problem? http://people.redhat.com/dcbw/libspa645li.so Thanks!
Created attachment 106308 [details] Screenshot Great. The dialog is translated now.
Created attachment 106309 [details] Screenshot But the printer setting part is still human unreadable.
Created attachment 110508 [details] as in fc3's 1.1.3 update
Created attachment 110509 [details] as in fc2 updates 1.1.3
looks ok now, no ?
tried 1.1.3-6.7.0. but it still looks bad. You have to look at the CUPS printer rather than the Generic Printer.
how about the recent 1.9.104 FC4 or 1.9.109-5 rawhide/fc4-update-candidate ?
still appears in 1.9.109-5.2.0.fc5.
ppd file for this printer that was setup on another server, seems to be EUC-JP.
no attachment for "ppd file for this printer..."
Created attachment 115729 [details] ppd file Sorry, attached the euc-jp ppd file.
hmm... *LanguageEncoding: JIS83-RKSJ might be the key to this.
I can see the problem now which is great. Now just to reassure me that this is really an OOo specific bug, can you attach a screenshot from /usr/bin/printconf-gui. Click on the printer queue and choose edit and click on "Driver Options" and confirm that the strings are not broken there as well.
Created attachment 115752 [details] ultrasimple test code
Created attachment 115753 [details] the output ppd that OOo gets from cups
twaugh: OOo calls cupsGetPPD (like test.c) on this printer that has the original PPD that akira attached but OOo (and test.c) actually get the PPD like I attached above The thing seems to be that the ppd originally had LanguageEncoding: JIS83-RKSJ and localized strings in an asian encoding and now has LanguageEncoding: ISOLatin1 and the localized strings are now a sequence of ascii "?"s so OOo honours this and shows what it was given by CUPS for its options. I'm not sure of cups internals at all, but I suspect that fundamentally the problem may be that the original PPD's localised strings appear to not actually be in shift-jis, but instead are in euc_jp. If cups converts from one encoding to another perhaps checking for failure during and discarding the results is an option.
Well, I asked our IS guy that difference between LanguageEncoding's value and the real encoding. he seems to convert it from shift-jis to euc-jp because CUPS seems not to understand LanguageEncoding at all -- it was done for RHEL3. it used EUC-JP for Japanese. Although I looked at the PPD File Format Specification, it's mentioned only about ISOLatin1, ISOLatin2, ISOLatin5, JIS83-RKSJ, MacStandard and WindowsANSI. so no specification of that for EUC-JP ATM. For the testcase of this problem, the PPD file I attached should be reconverted to shift-jis, and CUPS needs to be fixed to handle LanguageEncoding properly, I suppose.
If I understand correctly, this bug report is that CUPS modifies the LanguageEncoding value of the PPD. cupsGetPPD() does not modify the PPD at all as far as I can see -- in which case, the modification happened when the PPD was installed. How was the PPD installed? Please attach a test case in the correct encoding, along with instructions for reproducing the problem.
well I just used /usr/bin/printconf-gui and the action->import ppd from there. Where does the ppd get installed to ?
The PPD gets translated into XML. Then, when you set up a queue for that printer model, it is reconstructed. This process will be changed in future to store a copy of the PPD within foomatic and produce exactly that PPD when required. So it sounds like this is a foomatic bug.
Could you attach a PPD with the correct encoding so that I can see what is happening?
From my side comment #15 was the original PPD I took.
But comment #21 indicates that this file is in the wrong encoding for its LanguageEncoding tag.
You can try iconv -f euc-jp -t sjis with https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=115729. it was converted to euc-jp from shift-jis by iconv.
We need a better mechanism in foomatic for storing and retrieving third party PPD files.
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
Thanks for giving a chance to test this again. Japanese PPD seems working fine on Rawhide now. just tried to import Japanese PPD from s-c-printer. the related package version are: system-config-printer-0.7.82.1-3.fc9 foomatic-3.0.2-59.fc9 Thanks again!