Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Filenames containing accented characters do not open | ||||||
---|---|---|---|---|---|---|---|
Product: | General | Reporter: | kendy | ||||
Component: | code | Assignee: | AOO issues mailing list <issues> | ||||
Status: | CONFIRMED --- | QA Contact: | |||||
Severity: | Trivial | ||||||
Priority: | P3 | CC: | issues, stephan.bergmann.secondary | ||||
Version: | OOH680m5 | ||||||
Target Milestone: | --- | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||
Developer Difficulty: | --- | ||||||
Attachments: |
|
Description
kendy
2008-01-31 10:56:19 UTC
Created attachment 51287 [details]
The test files.
This issue slipped off my attention - sorry for that. This is a general problem. Our API (UNO as well C++ in sal) assumes that file names are given as Strings. This either can be a URL (always encoded in UTF-8) or a system file path (always assumed to have the system encoding). Though this assumption is very limiting, as you example shows, it could work if we didn't touch file names, but we convert between URLs and system file paths back and fourth in several places, and the same assumptions about encodings are applied. A fix would require to change the sal file API to work with types that somehow preserve the original file system path notation and also rethink our handling of URLs and file paths in general. There already is an issue for this: issue 66973 If you agree that your problem is as I described it, we can close this as a duplicate. Reset assigne to the default "issues@openoffice.apache.org". |