Bug 138317 - foomatic-ppdload ignores LanguageEncoding
foomatic-ppdload ignores LanguageEncoding
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: foomatic (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
bzcl34nup
: i18n
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-08 01:39 EST by Nakai
Modified: 2008-08-02 19:40 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-06 23:39:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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 16:00 EST, Dan Williams
no flags Details
Screenshot (8.97 KB, image/png)
2004-11-09 00:32 EST, Nakai
no flags Details
Screenshot (20.45 KB, image/png)
2004-11-09 00:36 EST, Nakai
no flags Details
as in fc3's 1.1.3 update (7.92 KB, image/png)
2005-02-01 13:11 EST, Caolan McNamara
no flags Details
as in fc2 updates 1.1.3 (8.98 KB, image/png)
2005-02-01 13:12 EST, Caolan McNamara
no flags Details
ppd file (179.70 KB, application/octet-stream)
2005-06-20 23:41 EDT, Akira TAGOH
no flags Details
ultrasimple test code (169 bytes, text/x-csrc)
2005-06-21 11:45 EDT, Caolan McNamara
no flags Details
the output ppd that OOo gets from cups (40.08 KB, application/octet-stream)
2005-06-21 11:47 EDT, Caolan McNamara
no flags Details

  None (edit)
Description Nakai 2004-11-08 01:39:17 EST
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.
Comment 1 Dan Williams 2004-11-08 15:43:17 EST
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 15:47:51 EST
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 16:00:09 EST
Created attachment 106301 [details]
Patch to fix UI language in printer properties
Comment 4 Dan Williams 2004-11-08 16:03:46 EST
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!
Comment 5 Nakai 2004-11-09 00:32:50 EST
Created attachment 106308 [details]
Screenshot

Great. The dialog is translated now.
Comment 6 Nakai 2004-11-09 00:36:46 EST
Created attachment 106309 [details]
Screenshot

But the printer setting part is still human unreadable.
Comment 7 Caolan McNamara 2005-02-01 13:11:31 EST
Created attachment 110508 [details]
as in fc3's 1.1.3 update
Comment 8 Caolan McNamara 2005-02-01 13:12:13 EST
Created attachment 110509 [details]
as in fc2 updates 1.1.3
Comment 9 Caolan McNamara 2005-02-01 13:17:09 EST
looks ok now, no ?
Comment 10 Akira TAGOH 2005-02-23 03:56:14 EST
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-14 20:24:38 EDT
how about the recent 1.9.104 FC4 or 1.9.109-5 rawhide/fc4-update-candidate ?
Comment 12 Akira TAGOH 2005-06-20 05:57:06 EDT
still appears in 1.9.109-5.2.0.fc5.
Comment 13 Akira TAGOH 2005-06-20 06:05:35 EDT
ppd file for this printer that was setup on another server, seems to be EUC-JP.
Comment 14 Caolan McNamara 2005-06-20 10:33:26 EDT
no attachment for "ppd file for this printer..."
Comment 15 Akira TAGOH 2005-06-20 23:41:07 EDT
Created attachment 115729 [details]
ppd file

Sorry, attached the euc-jp ppd file.
Comment 16 Caolan McNamara 2005-06-21 07:58:36 EDT
hmm... 
*LanguageEncoding: JIS83-RKSJ
might be the key to this.
Comment 17 Caolan McNamara 2005-06-21 08:19:31 EDT
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 11:45:28 EDT
Created attachment 115752 [details]
ultrasimple test code
Comment 19 Caolan McNamara 2005-06-21 11:47:23 EDT
Created attachment 115753 [details]
the output ppd that OOo gets from cups
Comment 20 Caolan McNamara 2005-06-21 11:57:44 EDT
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.
Comment 21 Akira TAGOH 2005-06-22 03:03:30 EDT
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 06:27:03 EDT
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 06:45:24 EDT
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 06:55:36 EDT
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 07:02:54 EDT
Could you attach a PPD with the correct encoding so that I can see what is
happening?
Comment 26 Caolan McNamara 2005-07-01 07:21:04 EDT
From my side comment #15 was the original PPD I took.
Comment 27 Tim Waugh 2005-07-01 07:45:37 EDT
But comment #21 indicates that this file is in the wrong encoding for its
LanguageEncoding tag.
Comment 28 Akira TAGOH 2005-07-01 08:26:39 EDT
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 09:56:59 EDT
We need a better mechanism in foomatic for storing and retrieving third party
PPD files.
Comment 30 Bug Zapper 2008-04-03 11:45:12 EDT
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.
Comment 31 Akira TAGOH 2008-04-06 23:39:47 EDT
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!

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