[Octave-bug-tracker] [bug #49222] octave-io 2.4.3: xls2oct with "OCT" interface lost the ability to read german umlauts or °

[Philip Nienhuis]

Follow-up Comment #20, bug #49222 (project octave):

Markus,
I'm not so sure the patches do the wrong thing.

With what I know now, after some experimenting, is that what is explained in
the wiki is not so much that Octave uses UTF-8 encoding, but is merely
"transparent" - it just conveys string contents to lower level functions and
often that works out well. I get the impression all of that is more
accidental.

As stated in bug #46855, writing w/o converting non-alphanumeric chars to file
gives problems when opening the file in LO or Excel. With your patches, that
issue is solved.

On Windows everything works fine now.
On Linux it is different. If I read Andreas' test file I get  before your
patch the proper characters in the terminal (Konsole), but in the Variable
Editor (patch #8656) I see garbage. With your patch I get garbage in the
terminal but proper text in the Variable Editor. So also on Linux there's a
problem, or at least something going on, with encoding and/or codepages in the
GUI terminal, I guess.
So it could well be that Andreas was just lucky that things worked well for
him with io-2.4.0

I just pushed a next step, as also the Java based interfaces couldn't properly
display Andreas' test .xlsx file contents in the Octave terminal on Windows.
So I expanded the call to tidyxml to all non-COM interfaces.

I think the various Java spreadsheet I/O interfaces all have methods to assess
the file encoding. I do not know about COM/ActiveX.
.xlsx, .gnumeric and .ods indicate the encoding in the top line of each
individual XML file, as stated in comment #1.

Maybe we should transfer the discussion to the maintainers ML?

BTW I uploaded an io-2.4.4a dev snapshot to my dropbox. If you want you can
have a try with it:
https://www.dropbox.com/s/0vchnxamjavkfwu/io-2.4.4a.tar.gz?dl=0
Note that in that dev snapshot there's a new option field in
oct2xls/xls2oct/oct2ods/ods2oct "retain_nonascii" to bypass the encoding
steps.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?49222>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/