Apache OpenOffice (AOO) Bugzilla – Issue 75076
wrong encoding shown in preview when importing CSV even if correct charset is selected in combo-box.
Last modified: 2008-01-07 10:53:01 UTC
Debian Etch AMD64, 2.0.4 When opening a csv file through "oocalc", the default (selected) encoding is UTF-8, yet the preview (and on commencing, the import) happens in some other (ISO-8859-1?) encoding. If I re-select the selected UTF-8, it is converted correctly, so there is an easy workaround, but for unexperienced users, it may be confusing. I changed the locale since installing the package, but I am not sure if that was the cause, it was LANG=hu_HU.UTF-8 and now it is LANG=en_US eknagy@omikk.bme.hu Screenshots: https://webmail.omikk.bme.hu/~eknagy/ooobugs/
Hi, could you attach a file showing the described problem and more important, can you reproduce it with the latest stable version which is OOo2.2 which you can get from the OpenOffice.org website. Thanks for your help. Frank
Created attachment 44699 [details] example csv file
Sorry, I don't want to break my etch with installing openoffice 2.2 (available only in unstable).
Hi, this is not a bug. If you open such files, the encoding from the underlying locale is taken to preview the file. If it's set to e.g. en_US.iso88591 it will start with this encoding and you can set the correct one with the dropdown box in the dialog. The encoding isn't stored in the file, so OOo can't know that you had a UTF8 encoding in mind for this particular file. Sorry for no better reply but I've to close this as invalid. BTW 2.0.4 is somewhat outdated, please use OOo2.2 instead, it comes with some fixes for a few Security Issues. Frank
closed invalid
But UTF-8 seems to be selected in the combobox, and not ISO-8859-2, so all those users outside who don't develop OpenOffice think that it is opened in the selected encoding. It even fooled me. This results in: 1. I send them the csv file and tell them to set the encoding to UTF-8 2. They open up the file and UTF-8 is selected in the import box, so they hit OK 3. The characters are wrong. As the users experience something that is identical to a bug in behavior, I re-open this bug. What is more, they tell me to send it in tab-separated txt so they properly open it in another office suite, which is "not broken". ... Maybe, a "platform default" option could be inserted and selected as default?
Please use the latest stable Version it's 2.2 for now. I've checked it with that version and it works in the correct way. Maybe 2.0.4 had a bug for this. Frank
Maybe invalid on 2.2, but valid on 2.0.4 (as originally reported). Either patch it or mark it as wontfix. 2.2 is not an opinion for a while for Debian Etch - and Etch will be around for years. "Upgrade to the latest version" is not a viable way - plaese compare the libs on the following links. http://packages.debian.org/unstable/editors/openoffice.org-core http://packages.debian.org/stable/editors/openoffice.org-core
Sorry, but you are on the OpenOffice.org site and the problem you've reported is fixed in an OpenOffice.org build. If you do not want to install a newer version, it's your problem. OOo will not fix anything for 2.0.4 as it is fixed on 2.2. So report this problem with Debian as they have their own bugreportingsystem for their own builds. This Issue is invalid and closed as such. Frank
I'll try to nag them, then - the bug report is only there since 2006 Dec 14: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403128
.. at which time etch was already frozen so even If I had a patch for this at that time or investigated time to fix that it most probably wouldn't have been accepted. Try with 2.2.0, please. There will be a etch backport of it soon.
fst: oh, and btw, cooming with the security thing is bogus, of course the security patches were backported to the 2.0.4 Debian etch ships. As always normally done for security things.
I reproduced the bug under 2.2 - please see https://152.66.114.1/~eknagy/ooobugs/ver22/ This is under x86, btw. I already reported it to Debian. Please feel free to close it once more as invalid, as I re-opened it.
Apparently this problem is caused by some patch in Debian build (likely in Novell's too as Suse's build reportedly shows the same problem). I am closing this issue as invalid because it is not our code.
and closing.
Dear OOO, Here is a patch (hereby released into the public domain, or with the same licence as the original file(s). Please test it and integrate in releases if OOO won't - I will submit this to them as well. As far as I see (but I am a Java guy and I don't speak UNO I will not look into it further), the bug is in the OOO source tree, caused by the OOO patch "sc-preserve-imp-opts". I do not understand how you failed to find it when testing - maybe you didn't wanted to find it, maybe that this line aLbCharSet.SetSelectHdl( LINK( this, ScImportAsciiDlg, CharSetHdl ) ); beheaves differently on different platforms? Somebody might want to check this possibly different behaviour out.
Created attachment 48236 [details] Patch to fix Issue 75076 and/or Debian bug #403128
Hi Daniel, please have a look at this one. I'm pretty sure the problem is fixed and therefore this Issue is invalid, but who knows really. Frank
eknagy: this issue still in INVALID. As you noticed this is caused by sc-preserve-imp-opts.diff (-> Issue 3687) which is not yet in official OOo. I'll add the fix to ooo-build, though.
Created attachment 48241 [details] Non-reversed patch to fix Issue 75076 and/or Debian bug #403128
closed, not relevant for official OOo