Bug 138317 - foomatic-ppdload ignores LanguageEncoding
Summary: foomatic-ppdload ignores LanguageEncoding
Alias: None
Product: Fedora
Classification: Fedora
Component: foomatic   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
Whiteboard: bzcl34nup
Keywords: i18n
Depends On:
TreeView+ depends on / blocked
Reported: 2004-11-08 06:39 UTC by Nakai
Modified: 2008-08-02 23:40 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-07 03:39:47 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch to fix UI language in printer properties (1.31 KB, text/plain)
2004-11-08 21:00 UTC, Dan Williams
no flags Details
Screenshot (8.97 KB, image/png)
2004-11-09 05:32 UTC, Nakai
no flags Details
Screenshot (20.45 KB, image/png)
2004-11-09 05:36 UTC, Nakai
no flags Details
as in fc3's 1.1.3 update (7.92 KB, image/png)
2005-02-01 18:11 UTC, Caolan McNamara
no flags Details
as in fc2 updates 1.1.3 (8.98 KB, image/png)
2005-02-01 18:12 UTC, Caolan McNamara
no flags Details
ppd file (179.70 KB, application/octet-stream)
2005-06-21 03:41 UTC, Akira TAGOH
no flags Details
ultrasimple test code (169 bytes, text/x-csrc)
2005-06-21 15:45 UTC, Caolan McNamara
no flags Details
the output ppd that OOo gets from cups (40.08 KB, application/octet-stream)
2005-06-21 15:47 UTC, Caolan McNamara
no flags Details

Description Nakai 2004-11-08 06:39:17 UTC
Description of problem:
ooffice printer property setting is scrambled in Japanese

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Japanese environment
2. oowriter
3. Ctrl+P
4. Press the property button in the dialog
Actual results:
Human unreadable

Expected results:
Sane Japanese

Additional info:
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.

Comment 1 Dan Williams 2004-11-08 20:43:17 UTC
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.

Comment 2 Dan Williams 2004-11-08 20:47:51 UTC
It may be that padmin/source/helper.cxx:PaResId(ULONG nId) is the
culprit and is failing to find the current language correctly.

Comment 3 Dan Williams 2004-11-08 21:00:09 UTC
Created attachment 106301 [details]
Patch to fix UI language in printer properties

Comment 4 Dan Williams 2004-11-08 21:03:46 UTC

Can you download this file and drop it into /usr/lib/ooo-1.1/program
directory and see if it fixes your problem?



Comment 5 Nakai 2004-11-09 05:32:50 UTC
Created attachment 106308 [details]

Great. The dialog is translated now.

Comment 6 Nakai 2004-11-09 05:36:46 UTC
Created attachment 106309 [details]

But the printer setting part is still human unreadable.

Comment 7 Caolan McNamara 2005-02-01 18:11:31 UTC
Created attachment 110508 [details]
as in fc3's 1.1.3 update

Comment 8 Caolan McNamara 2005-02-01 18:12:13 UTC
Created attachment 110509 [details]
as in fc2 updates 1.1.3

Comment 9 Caolan McNamara 2005-02-01 18:17:09 UTC
looks ok now, no ?

Comment 10 Akira TAGOH 2005-02-23 08:56:14 UTC
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.

Comment 11 Caolan McNamara 2005-06-15 00:24:38 UTC
how about the recent 1.9.104 FC4 or 1.9.109-5 rawhide/fc4-update-candidate ?

Comment 12 Akira TAGOH 2005-06-20 09:57:06 UTC
still appears in 1.9.109-5.2.0.fc5.

Comment 13 Akira TAGOH 2005-06-20 10:05:35 UTC
ppd file for this printer that was setup on another server, seems to be EUC-JP.

Comment 14 Caolan McNamara 2005-06-20 14:33:26 UTC
no attachment for "ppd file for this printer..."

Comment 15 Akira TAGOH 2005-06-21 03:41:07 UTC
Created attachment 115729 [details]
ppd file

Sorry, attached the euc-jp ppd file.

Comment 16 Caolan McNamara 2005-06-21 11:58:36 UTC
*LanguageEncoding: JIS83-RKSJ
might be the key to this.

Comment 17 Caolan McNamara 2005-06-21 12:19:31 UTC
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.

Comment 18 Caolan McNamara 2005-06-21 15:45:28 UTC
Created attachment 115752 [details]
ultrasimple test code

Comment 19 Caolan McNamara 2005-06-21 15:47:23 UTC
Created attachment 115753 [details]
the output ppd that OOo gets from cups

Comment 20 Caolan McNamara 2005-06-21 15:57:44 UTC
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

Comment 21 Akira TAGOH 2005-06-22 07:03:30 UTC
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.

Comment 22 Tim Waugh 2005-06-28 10:27:03 UTC
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.

Comment 23 Caolan McNamara 2005-06-28 10:45:24 UTC
well I just used /usr/bin/printconf-gui and the action->import ppd from there.
Where does the ppd get installed to ?

Comment 24 Tim Waugh 2005-07-01 10:55:36 UTC
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.

Comment 25 Tim Waugh 2005-07-01 11:02:54 UTC
Could you attach a PPD with the correct encoding so that I can see what is

Comment 26 Caolan McNamara 2005-07-01 11:21:04 UTC
From my side comment #15 was the original PPD I took.

Comment 27 Tim Waugh 2005-07-01 11:45:37 UTC
But comment #21 indicates that this file is in the wrong encoding for its
LanguageEncoding tag.

Comment 28 Akira TAGOH 2005-07-01 12:26:39 UTC
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.

Comment 29 Tim Waugh 2005-07-06 13:56:59 UTC
We need a better mechanism in foomatic for storing and retrieving third party
PPD files.

Comment 30 Bug Zapper 2008-04-03 15:45:12 UTC
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.

Comment 31 Akira TAGOH 2008-04-07 03:39:47 UTC
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:


Thanks again!

Note You need to log in before you can comment on or make changes to this bug.