Issue 20899 - PDB import/export filter doesn't support non ISO-8859-1 characters
Summary: PDB import/export filter doesn't support non ISO-8859-1 characters
Alias: None
Product: Writer
Classification: Application
Component: code (show other issues)
Version: OOo 1.1
Hardware: All All
: P4 Trivial with 4 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
: 59933 (view as issue list)
Depends on:
Reported: 2003-10-08 16:58 UTC by dan
Modified: 2013-08-07 14:38 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description dan 2003-10-08 16:58:29 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.
Comment 1 pavel 2003-10-08 17:50:42 UTC
Confirmed - no source, no license, iso-8859-1 is hardcoded.
Comment 2 h.ilter 2003-10-09 10:22:55 UTC
Reassigned to US
Comment 3 stefan.baltzer 2003-10-23 15:49:24 UTC
SBA->JA: Please take over.
Reassigned to Joost.
Comment 4 dan 2003-10-23 16:01:49 UTC
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? 
Comment 5 Joost Andrae 2003-10-27 10:21:38 UTC
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
Comment 6 dan 2004-01-05 19:16:21 UTC
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:
Comment 7 pavel 2004-02-29 21:34:03 UTC
Is this really fixed in 2.0 (e.g. in 20040225)? I do not think so.

Please close only when proper fix is included.
Comment 8 dan 2004-02-29 21:59:59 UTC
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.)
Comment 9 miles 2004-03-15 15:01:30 UTC
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...
Comment 10 martin_maher 2004-05-05 11:23:39 UTC
MM: Will not be fixed for OO 2.0
Comment 11 martin_maher 2004-05-05 11:25:05 UTC
MM: moving to MRU so it can be re-targetted
Comment 12 miles 2004-05-05 12:04:36 UTC
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 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!
Comment 13 michael.ruess 2004-05-05 12:08:54 UTC
New target "OO later"
Comment 14 miles 2004-11-13 09:37:11 UTC
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.
Comment 15 dan 2004-11-13 10:40:03 UTC
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.
Comment 16 miles 2004-11-13 15:34:29 UTC
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!
Comment 17 dan 2004-11-13 16:21:55 UTC
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.
Comment 18 miles 2004-11-13 16:47:02 UTC
Great! Whatever will do better than having to install extra filter over the
included one, like now! 
Comment 19 martin_maher 2005-05-05 10:38:45 UTC
mmaher->flr: Your's methinks
Comment 20 miles 2005-11-02 15:51:48 UTC
So, any news on this one?
Comment 21 dan 2006-03-05 18:00:25 UTC
*** Issue 59933 has been marked as a duplicate of this issue. ***
Comment 22 miles 2006-05-02 21:07:59 UTC
Two years ago it was posted as OOo Later, so how much later is this going to take?
Comment 23 miles 2006-06-06 10:31:23 UTC
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 ...
Comment 24 kaplanlior 2008-05-11 22:36:17 UTC
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

Comment 25 Rob Weir 2013-07-30 02:38:46 UTC
Reset assignee on issues not touched by assignee in more than 1000 days.