Bug 131710 - word doc with chinese file name can not be openend by ooo in gnome
Summary: word doc with chinese file name can not be openend by ooo in gnome
Status: RESOLVED WONTFIX
Alias: None
Product: SUSE LINUX 10.0
Classification: openSUSE
Component: GNOME (show other bugs)
Version: Stable Snapshot 2
Hardware: Other Other
: P5 - None : Normal
Target Milestone: ---
Assignee: E-mail List
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-11-01 05:22 UTC by James Li
Modified: 2006-03-22 12:13 UTC (History)
1 user (show)

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description James Li 2005-11-01 05:22:36 UTC 
When double click a word doc with chinese file name in gnome, it start an openoffice to open it. But the openoffice reports that the file can not be found. 

But when using openoffice open it directly by selecting "open" in menu, the doc can be opened correctly.
Comment 1 JP Rosevear 2006-03-19 16:40:08 UTC 
Adding meeks as CC.  Either this is gnome launching with a bad URI or OO not getting it from the command line properly.
Comment 2 Michael Meeks 2006-03-20 09:34:54 UTC 
Well - this is most interesting; sadly I don't have any samples of chinese names to use for test documents; but using the only piece of Japanese I have: 日本語 and naming a file <that>.doc - I can launch it jut fine from nautilus - and from the console. [ of course this is with SL 10.1 ].

Any chance if you repeat this in 10.1 ?

Thanks.
Comment 3 JP Rosevear 2006-03-20 13:46:02 UTC 
Maybe Zhe Su can help us out here.
Comment 4 James Li 2006-03-22 11:17:30 UTC 
I see, This problem occurs when I use GBK locale . But UTF8 locale is ok
Comment 5 Michael Meeks 2006-03-22 12:13:16 UTC 
The use of non-UTF8 locales simply cannot be supported.

I assume your file-name is in UTF-8 (or GNOME wouldn't handle it) but your locale is non-UTF8 ?

It's important that both are UTF8. Of course, we could clobber the OO.o internal char-set detection code (that is trying to be too clever) to always use UTF-8 - that is perhaps a solution, but an ugly one.