Description of problem:
ooffice printer property setting is scrambled in Japanese
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Japanese environment
4. Press the property button in the dialog
kprinter has a similar bug.
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
Can you download this file and drop it into /usr/lib/ooo-1.1/program
directory and see if it fixes your problem?
Created attachment 106308 [details]
Great. The dialog is translated now.
Created attachment 106309 [details]
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]
Sorry, attached the euc-jp ppd file.
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
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
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
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
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
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
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:
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: