Apache OpenOffice (AOO) Bugzilla – Issue 20899
PDB import/export filter doesn't support non ISO-8859-1 characters
Last modified: 2013-08-07 14:38:26 UTC
Based on czech user expirience I have found, that there are several problems with pdb (artistic) import and export filter. First, there is no source code for any java based filters in OOo source tree. There are only .jar and .class files with no source and no licence. Second, ater decompiling .class files I have found, that there is hardcoded ISO-8859-1 encoding, but Palm's devices are using in any coutry another encoding, for example in Czech Windows-1250 and ISO-8859-2. There should be possible specifing encoding while the file is imported and exported. Similiar to .txt filter. I can help with this, but I need at least source code of the filters code.
Confirmed - no source, no license, iso-8859-1 is hardcoded.
Reassigned to US
SBA->JA: Please take over. Reassigned to Joost.
I can fix the problem, at least partially, for Czech users. But I need to know which licence is on the code, if I can modifi it and redistribute and I need the source code, which is not in the souce tree. Who is author of them?
Joost->Martin: Could you please take-over this issue and give Dan the information to get the fix into the jar file ? Reassigned to you
OK, i have now all the files needed and I have sucessfully compiled new version of the import filter. So closing. URL for the project is: http://xml.openoffice.org/xmerge/plugins/aportisdoc.html
Is this really fixed in 2.0 (e.g. in 20040225)? I do not think so. Please close only when proper fix is included.
This bug was about finding sources of filters which are in ordinary build tree in binary form and about licensing. This part is solved, we alreadny know which licence is it and we know which project provides binary filter files for OOo. So the encodings problem is mainly problem of xmerge project and not about word processor. The bug can be reopened, but should be moved into xmerge project. (Or probably xml project because I don't see any xmerge component in issuezilla.)
Could someone change OS tag from Linux to All? Do you think this bug can have a change in priority to P3, because only western languages are supported in PDB import/export? The bug makes this advertised feature more of a setback - you try it and it doesn't work. Oo.o is very strong in localizations and it is a shame that features are not written/tested with all codepages in mind. Maybe it can be specified on Oo.o site that PDB import/export works only with English and other western languages, but not with Central European and such... Or maybe this feature shouldn't be mentioned in specifications until this bug gets fixed...
MM: Will not be fixed for OO 2.0
MM: moving to MRU so it can be re-targetted
If this thing won't be fixed for 2.0 then stop lying on the "promotional" pages of Oo.o; instead of writing "Support for mobile device formats like AportisDoc (Palm), Pocket Word and Pocket Excel." under features of Oo.o 1.1.1 on page http://www.openoffice.org/dev_docs/features/1.1/features-text.html you should change that to: Support for mobile device formats like AportisDoc (Palm), Pocket Word and Pocket Excel (works only for Western European languages). If you don't change this, then you are just plain lying about Oo.o functionality and maybe some journalist can pick up from there. With the decision of going multilingual a feature works when it works for all languages that Oo.o is built in, unless stated otherwise. So all features and other documentation of 1.1.1, 1.1.x and 2.x must be changed that it reflects true state of this feature: not working for a lot of Oo.o users!
New target "OO later"
Can a localizing team replace the Aportis doc filter in the official localized build with a different build of the filter (provided by the maker of the Aportis import/export filter for OO.o) that supports i.e. Central European characters, until you solve this bug properly? If not then you must fix this bug immediately, if yes, we can wait.
I have also found a clean solution which won't need big changes in UI. There can be environment variable called for example PALM_CHARSET and the filter can switch the encoding according this variable. It is not posible to set it according locales, becouse at least in Czech there are two diferent encodings used (windows-1250 and ISO-8859-2) and linux users are using mostly ISO but Windows users Windows-1250.
Wow, Dan! Could you then retarget this for 2.0 instead of "OOo Later"? It would be great if this would be included in the 2.0!!!! The sooner the better! If it introduces just one single environment variable that is set during installation/use and only the filter is changed to act accordingly to its value then this is not an obtrusive code change for ooo and could be implemented and properly tested in a very short period! I don't have to stress that this variable could be of use for other filters or import/export issues, for other devices and formats as well. Please make it happen! Thanks!
I am playing with it some hours today. I have problem that security manager won't allow access to environment. Only one variable for all the filers won't work. In Czech Republic are used Palms with ISO-8859-2 and CP1250, linux users are using mostly ISO, windows users are using CP1250. But I am using CP1250 even under linux, becouse I need sometimes exchange records with peoples which are using Windows. Other hand Windows CE filters are using only CP1250, there is no version of windows CE with ISO encoding. Best solutions is to change the interface and give user the encoding combo box inside import file dialog, but it won't be ready for 2.0, so I will try to figure out some other solution.
Great! Whatever will do better than having to install extra filter over the included one, like now!
mmaher->flr: Your's methinks
So, any news on this one?
*** Issue 59933 has been marked as a duplicate of this issue. ***
Two years ago it was posted as OOo Later, so how much later is this going to take?
Dan, now that 2.x has what you required: ... change the interface and give user the encoding combo box inside import file dialog, but it won't be ready for 2.0 ... - now would be a great time to finally implement this feature (especially because you already have the required backbone code). I agree, there should be an option of selecting any of those two code-pages for Slovenian, maybe even more other codepages (cyrillic, japanese?). And really, this is the only localization issue which makes OO.o for Slavic (and maybe some other, too) languages NOT fully localizable. I also urge you to change priority to P3, so that this issue gets tackled in the very near future ...
This bug has been also reported in Debian against version 2.0.4 and 2.2. The user also says he could reproduce this with 3.0 beta. See more info at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387452 Thanks.
Reset assignee on issues not touched by assignee in more than 1000 days.