Closed Bug 156302 Opened 22 years ago Closed 17 years ago

Unable to use DBCS for print-to-file file name

Categories

(Core :: Printing: Output, defect)

Product:
Core
Component:
Printing: Output
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9alpha8

People

(Reporter: kasumi, Assigned: roland.mainz)

References

(Blocks 1 open bug)

Details

(Keywords: intl)

Attachments

(1 file)

Hacked(!!) prototype patch for 2002-09-29-08-trunk
5.56 KB, patch
Details | Diff | Splinter Review 
tested on 2002-07-02-07-1.0
Linux RedHat 7.1 JA

1. Launch Navigator
2. Select File/Print
3. Select Printer region/Print to/File
4. Click Coose File button then type file name having DBCS then
   click Save button
   You will see the corrupted file name or balnk file name for .ps 
   file
I am using our own file dialog for this, and I will need some L10N help with this...
Summary: Unable to use DBCS for .ps file name → Unable to use DBCS for .ps file name
What can I do for you ?
rods:
I "guess" that we do not convert the unicode filename string to the
users/machines current locale/encoding...
Reporter:
Which encoding does your japanese linux use (e.g. PCK, UTF-8) ?

AFAIK we convert the file name from UCS2 to UTF-8 in some places instead of UTF2
to the platform's encoding...
correction:
s/UTF2/UCS2/
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.1alpha
Roland, where are we do the UTF-8 conversions? Is it in the printing code or in
other file dialog code?
Target Milestone: mozilla1.1alpha → mozilla1.2beta
charset is EUC-JP. This is default.
rods wrote:
> Roland, where are we do the UTF-8 conversions? Is it in the printing code or 
> in other file dialog code?

In printing code, shattered over the whole gfx/ code. The problem is that we
don't have a simple NS_ConvertUCS2toFilesystemEncoding() (or similar) ...
somewhere I found that NS_ConvertUCS2toUTF8() was used and I followed the
example (which means all *.UTF-8 locales will work, but now locales like
ja_JP.PCK).

I can take the bug when someone tells me which macro I should use instead...
darin:
We can't use |NS_CopyUnicodeToNative| from
http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsNativeCharsetUtils.h , right
?
NS_CopyUnicodeToNative is currently only implemented for XP_UNIX.  I've been
meaning to complete its implementation (not hard).  See bug 166612.  One thing
about nsNativeCharsetUtils: it should only be used on file paths.

for the time being, i would recommend using nsIFile/nsILocalFile to do your
charset conversions.  sounds crufty, and it is, but it will do the trick.  once
NS_CopyUnicodeToNative is implemented, you'll be able to simplify your code. 
add some XXX comments, file a bug and mark it dependent on bug 166612 ;-)
Darin Fisher wrote:
> NS_CopyUnicodeToNative is currently only implemented for XP_UNIX. 

The code we're talking about is Unix/Linux-only... :)

> I've been
> meaning to complete its implementation (not hard).  See bug 166612.  One thing
> about nsNativeCharsetUtils: it should only be used on file paths.
> for the time being, i would recommend using nsIFile/nsILocalFile to do your
> charset conversions.  sounds crufty, and it is, but it will do the trick.  
> once NS_CopyUnicodeToNative is implemented, you'll be able to simplify your 
> code. 
> add some XXX comments, file a bug and mark it dependent on bug 166612 ;-)

nsIFile/nsILocalFile cannot be used in this case (or we'll endup in rewriting
much code) since we are feeding pathnames to some APIs which want file _names_.

Since this issue is Unix/Linux-only I'd like to use NS_CopyUnicodeToNative()
(which is implemented on these platformss). Is that OK for you ?
in that case, using NS_CopyNativeToUnicode and NS_CopyUnicodeToNative should be
fine.
Darin Fisher wrote:
> in that case, using NS_CopyNativeToUnicode and NS_CopyUnicodeToNative 
> should be fine.

Thanks!

----

rods:
Should I take this one ?
Yes, please do.
Taking per comment #14 ...
Assignee: rods → Roland.Mainz
Status: ASSIGNED → NEW
kasumi@netscape.com:
Can you check whether printing to file in a *.UTF8 locale (like ja_JP.UTF-8
etc.) works correctly ?
Target Milestone: mozilla1.2beta → mozilla1.3alpha
tested on 2002-09-30-06-1.0
locale = ja-JP.utf8

Doesn't work. A file having ascii as file name can't save in a folder having
DBCS as folder name either.
Kasumi wrote:
> tested on 2002-09-30-06-1.0

Can you test it with "trunk", please ?

> locale = ja-JP.utf8

On which OS are you working on ?

> Doesn't work.

Weired. Are you sure that you've only used a file name with no path in front of
it ?

> A file having ascii as file name can't save in a folder having
> DBCS as folder name either.

OK, maybe we have two independant problems here... the conversion and maybe a
problem that |fopen()| doesn't like the input...
Accepting bug...
Status: NEW → ASSIGNED
Target Milestone: mozilla1.3alpha → mozilla1.4alpha
xpcom/io/nsNativeCharsetUtils.h isn't exported yet (bug 166612 ("implement
NS_CopyNativeToUnicode / NS_CopyUnicodeToNative on all platforms") will fix
that...) ...
Depends on: 166612
5min hack patch for testing

ToDo:
- Bug 166612 ("implement NS_CopyNativeToUnicode / NS_CopyUnicodeToNative on all
platforms) needs to be fixed to get |NS_CopyNativeToUnicode()| and
|NS_CopyUnicodeToNative()| exported
- Bug 171809 ("RFE: Create |NS_ConvertUnicodeToNative| and
|NS_ConvertNativeToUnicode|") needs to be implemented to get rid of the hacked
versions in this patch
- Xlib toolkit needs to be patched
- PostScript and Xprint modules should use the unicode<-->native functions
where required, too
Kasumi:
Can you test the patch if it fixes your problem (using both *.UTF-8 locale+UTF-8
filenames and the the same procedure with DBCS), please ?
Roland:
Could you show me how to integrate this patch to test?
Kasumi wrote:
> Could you show me how to integrate this patch to test?

Do you build yourself on Unix/Linux ?

If the answer is "yes" then you can simply apply the patch to your tree like
this:
1. Verify that the patch applies cleanly to the tree:
% gpatch -p0 --dry-run <attachment_cgi_id_101197_action_view
2. If [1] was successfull then remove the "--dry-run" switch and do the gpatch
again
3. Build the Zilla as usual
4. Test it
Unfortunately my answer is "No".
How about in the case of "No"?
Kasumi wrote:
> Unfortunately my answer is "No".
> How about in the case of "No"?

Well, I could make a build for you, but only for Solaris/SPARC (or the older
SuSE Linux 6.4/x86 - but I have no clue if such an old Linux build works with
DBCS) ...
Does anyone else here have a DBCS-enabled Linux and can help testing the patch
(or knows someone who can help or knows someone who knows someone who can help ?
:) ?
cc Brian and Shanjian who may can help.
Keywords: intl
For printing issues would you kindly also cc: in the Sun developers:

Louie.Zhao@sun.com and pete.zha@sun.com
Summary: Unable to use DBCS for .ps file name → Unable to use DBCS for print-to-file file name
Blocks: 204013
Depends on: 171809
Target Milestone: mozilla1.4alpha → mozilla1.9beta
The patch for bug 193001 should have rendered this moot. Gecko now uses the GTK printing system for print dialogs. If this is an issue with the GTK dialog, please open a new bug.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: