[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: oct2xls write symbols and Non - standard ascii letters

From: Andrew Janke
Subject: Re: oct2xls write symbols and Non - standard ascii letters
Date: Fri, 24 May 2019 13:54:42 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0

On 5/23/19 1:43 PM, Nicholas Jankowski wrote:
> On Thu, May 23, 2019 at 11:22 AM Karin <address@hidden
> <mailto:address@hidden>> wrote:
>     Hi!
>     I am new to octave, but used to MATLAB. From another program I have
>     results.
>     With this I do some maths with octave without problems. For a nicer
>     form in
>     my report, I want to write these results to a EXCEL worksheet. In
>     MATLAB I
>     can write units like mikrogramm per cubicmeter with a greek letter for
>     'mikro' and the 'cubic' after m a "3" as a superscript to an EXCEl
>     Worksheet
>     without problems as long as a variable contains these characters.
>     This script runs with octave without an error:
>     file_name='test1.xlsx';
>     xls=xlsopen(file_name,1);
>     A=cell(2,5);
>     A(1,:)={'Spalte1','Spalte2/','µg/m³','Spalte4','test'};
> non-standard characters are a known issue with Octave, but they usually
> comes from using non-ascii characters. trying to recreate your inputs I
> noticed that I am unable to enter the µ and ³ characters in the
> interpreter, even though they are ASCII characters (by using ALT-0181
> for µ for example).  If I save it to a chartest.m file, I'm able to
> create the same cell array as you with those characters. How are you
> inputting those characters to octave? are they ascii or Unicode characters?
> All that said, using ascii characters, whether I use xlswrite or
> oct2ods, I'm able to create xlsx files without any problem that contain
> the characters in your column headings.  I get no errors on opening the
> files. 
> A=cell(2,5);
> A(1,:)={'Spalte1','Spalte2/','µg/m³','Spalte4','test'};
> A(2,1)=1;
> A(2,2)=2;
> A(2,3)=3;
> A(2,4)=4;
> A(2,5)=5;
>>> status = xlswrite('test1.xlsx',A)
> status =  1
> similarly:
>>> XLS = xlsopen ('test2.xlsx',1);
>>> [XLS,status] = oct2xls(A,XLS,'Tab_1','A5:E6');
>>> XLS = xlsclose(XLS);
> both the test1.xlsx and test2.xlsx files contain the column headings
> with µ and ³ characters with no errors.  same behavior whether I have
> the windows package open.  
> Octave 5.1.0
> Windows 10
> MS Offic 2013
> io package 2.4.12
> windows package 1.3.1

Nicholas, when you say "ASCII" here, do you actually mean "ANSI"? The
ASCII characters are just the 7-bit set and don't include µ or ³; those
are in the extended part of the ANSI/Windows-1252/ISO-8859-1 character set.

I'm also running Octave 5.1.0 on Windows 10, io 2.4.12, and MS Office
365 (I don't know how to tell what version I have). When I copy and
paste Karin's script from the original email into a new "german_excel.m"
file and run it, it produces an Excel file with no errors, and with the
µ and ³ in the column headers and they look fine. The Octave editor says
the file is in "SYSTEM" encoding, which I think means Windows 1252?

I get this:
>> chk_spreadsheet_support
ans = 0
And I have the io but not windows packages loaded. I guess that means
I'm using the native code interface?

Karin, maybe because you're running a German version of Windows, it's
creating or interpreting the .m file in a different encoding, and that's
resulting in messed-up strings getting passed into Excel. Could you
attach your .m script as a file attachment for us, instead of copying
its contents into the email body? That way we can see exactly what
encoding it's in and what bytes it contains, without any encoding
translations introduced by your email program. For that matter, could
you also attach the bad test1.xlsx file that you're getting? That way we
can see what bytes are making it into the actual Excel file.

I'm attaching my version of the script so you can see the exact contents
of the script that worked for me.

I think what's supposed to happen is that the strings get converted to
UTF-8 by the time they make their way into the .xlsx file contents, but
I don't know where encoding conversion might happen along the way in
these APIs. If raw ISO-8859-1 (or other non-Unicode-encoded) strings
were getting included in the .xlsx's /xl/sharedStrings.xml contents
without being converted to UTF-8, that sounds consistent with the error
message that Karin is seeing.

And Karin, what version of Octave and the io package are you using? (The
"ver" command will tell you.)


Description: Zip archive

reply via email to

[Prev in Thread] Current Thread [Next in Thread]