Menu
▾
▴
[Octave-cvsupdate] SF.net SVN: octave:[8576] trunk/octave-forge/main/io/doc
|
From: <prn...@us...> - 2011-09-21 18:06:47
|
Revision: 8576
http://octave.svn.sourceforge.net/octave/?rev=8576&view=rev
Author: prnienhuis
Date: 2011-09-21 18:06:41 +0000 (Wed, 21 Sep 2011)
Log Message:
-----------
Text adapted (layout, some note on UNO limitations)
Modified Paths:
--------------
trunk/octave-forge/main/io/doc/READ-ODS.html
trunk/octave-forge/main/io/doc/READ-XLS.html
Modified: trunk/octave-forge/main/io/doc/READ-ODS.html
===================================================================
--- trunk/octave-forge/main/io/doc/READ-ODS.html 2011-09-21 11:48:47 UTC (rev 8575)
+++ trunk/octave-forge/main/io/doc/READ-ODS.html 2011-09-21 18:06:41 UTC (rev 8576)
@@ -314,7 +314,7 @@
<p align="center"><font face="Arial, sans-serif"><font size="4"><u><b>COMPARISON
OF INTERFACES</b></u></font></font></p>
- <p><font face="Arial, sans-serif"><font size="2">The ODFtoolkit is
+ <p><font face="Arial, sans-serif"><font size="2">The <b>ODFtoolkit</b> is
the one that gives the best (but slow) results at present. However,
parsing xml trees into rectangular arrays is not quite
straightforward and the other way round is a real nightmare;
@@ -329,7 +329,7 @@
rebuilding possibly large parts of the tree in memory - nothing for
the faint-of-heart. Only with ODFToolkit (odfdom) 0.8.6 and 0.8.7 things have
been simplified for developers.</font></font></p></dt>
-<dt><p><font face="Arial, sans-serif"><font size="2">The jOpenDocument
+<dt><p><font face="Arial, sans-serif"><font size="2">The <b>jOpenDocument</b>
interface is more promising, as it does shield the xml tree
details and presents developers something which looks like a
spreadsheet model.<br>However, unfortunately
@@ -342,7 +342,7 @@
do sympathize with this business model but for octave needs this may
hamper progress for a while.</font></font></p></dt>
<dt><p><font face="Arial, sans-serif"><font size="2">The (still experimental)
- UNO interface, based on a Java/UNO bridge linking a hidden OpenOffice.org
+ <b>UNO interface</b>, based on a Java/UNO bridge linking a hidden OpenOffice.org
invocation to Octave, is the most promising:
</font></font>
<ul><li><font face="Arial, sans-serif"><font size="2">
@@ -368,6 +368,7 @@
Octave) while the ODF Toolkit and jOpenDocument classes also reside in the
JVM.
</font></font></li></ul>
+ <font face="Arial, sans-serif"><font size="2">However, UNO is not stable yet (see below)</font>.
</p></dt>
</dl>
@@ -477,12 +478,16 @@
<font face="Arial, sans-serif"><font size="2">Speeding up (ODS is 10 X
slower than e.g. OOXML !!!). jOpenDocument is much faster but still
immature.<br>
- UNO *is* MUCH faster than jOpenDocument but starting up OpenOffice.org
+ <b>UNO</b> *is* MUCH faster than jOpenDocument but starting up OpenOffice.org
for the first time can take tens of seconds...<br>
Note that UNO is still experimental. The issue is that odsclose() will simply
kill ALL other OpenOffice.org invocations, also those that were not opened
- through Octave! This is related to UNO-Java limitations. A way out is in
- development stage.
+ through Octave! This is related to UNO-Java limitations.<br>
+ The underlying issue is that when Octave starts an OpenOffice.org invocation,
+ OpenOffice.org must be closed for Octave to be able to exit; otherwise Octave will
+ wait for OOo to shut down before it can terminate itself. So Octave must kill
+ OOo to be able to terminate.<br>
+ A way out hasn't been found yet.
</font></font></p></li><li><p align="left">
\x93<font face="Arial, sans-serif"><font size="2">Passing function
handle\x94 a la Matlab's </font></font><font face="Arial, sans-serif"><font size="2"><b>xlsread</b></font></font></p></li><li><p align="left">
Modified: trunk/octave-forge/main/io/doc/READ-XLS.html
===================================================================
--- trunk/octave-forge/main/io/doc/READ-XLS.html 2011-09-21 11:48:47 UTC (rev 8575)
+++ trunk/octave-forge/main/io/doc/READ-XLS.html 2011-09-21 18:06:41 UTC (rev 8576)
@@ -212,23 +212,25 @@
</DL>
</FONT></FONT><B><U><FONT FACE="Arial, sans-serif" SIZE=4><FONT FACE="Arial, sans-serif" SIZE=4><P ALIGN="CENTER">COMPARISON OF INTERFACES & USAGE</P>
</B></U></FONT></FONT><FONT FACE="Arial, sans-serif" SIZE=2><FONT FACE="Arial, sans-serif" SIZE=2><DL>
-<DT>Using Excel itself (through COM / ActiveX on Windows systems) is probably the most robust and versatile and especially FAST option. There's one gotcha: in case of some type of COM errors Excel will keep running invisibly; you can only end it through Task Manager. <BR>
+<DT>Using Excel itself (through <b>COM / ActiveX</b> on Windows systems) is probably the most robust and versatile and especially FAST option. There's one gotcha: in case of some type of COM errors Excel will keep running invisibly; you can only end it through Task Manager. <BR>
A tiny problem is that one cannot find out easily through COM what file types are supported; xls, wks, wk1, xlsx, etc. <BR>
Another -obvious- limitation is that COM Excel access only works on Windows systems where Excel is installed. <BR>
<BR>
-JExcelAPI (Java-based and therefore platform-independent) is proven technology but switching between reading and writing is quite involved and memory-hungry when processing large spreadsheets. As the docs state, JExcelAPI is optimized for reading and it does do that well - but still slower than Excel/COM. The fact that upon a switch from reading to writing the existing spreadsheet is overwritten <B>in place</B> by a blank one and that you can only get the contents back wen writing out all of the changes is worrying - and any change after the first write() is lost as a next write() doesn't seem to work, worse yet, you may completely loose the spreadsheet in question. The first is by JExcelAPI design, the second is probably a bug (in octave-forge/Java or JExcelAPI ? I don't know). Adding data to existing spreadsheets does work, but IMO undue user confidence is needed.</DT>
+<b>JExcelAPI</b> (Java-based and therefore platform-independent) is proven technology but switching between reading and writing is quite involved and memory-hungry when processing large spreadsheets. As the docs state, JExcelAPI is optimized for reading and it does do that well - but still slower than Excel/COM. The fact that upon a switch from reading to writing the existing spreadsheet is overwritten <B>in place</B> by a blank one and that you can only get the contents back wen writing out all of the changes is worrying - and any change after the first write() is lost as a next write() doesn't seem to work, worse yet, you may completely loose the spreadsheet in question. The first is by JExcelAPI design, the second is probably a bug (in octave-forge/Java or JExcelAPI ? I don't know). Adding data to existing spreadsheets does work, but IMO undue user confidence is needed.</DT>
<DT>JExcelAPI supports BIFF5 (only reading) and BIFF8 (Excel 95 and Excel 97-2003, respectively). Upon overwriting, BIFF5 spreadsheets are converted silently to BIFF8.</DT>
<DT>JexcelAPI, unlike ApachePOI, doesn't evaluate functions while reading but instead relies on cached results (i.e. results computed by Excel itself). Depending on Excel settings ("Automatic calculation" ON or OFF) this may or may not yield incorrect (or expected) results. <BR>
<BR>
-Apache POI (Java-based and platform-independent too) is based on the OpenOffice.org I/O Excel r/w routines. It is a more versatile than JExcelAPI, while it doesn't support BIFF5 it does support BIFF8 (Excel 97 \x96 2003) and OOXML (Excel 2007).</DT>
+<b>Apache POI</b> (Java-based and platform-independent too) is based on the OpenOffice.org I/O Excel r/w routines. It is a more versatile than JExcelAPI, while it doesn't support BIFF5 it does support BIFF8 (Excel 97 \x96 2003) and OOXML (Excel 2007).</DT>
<DT>It is slower than native JXL let alone Excel & COM but it features active formula evaluation, although at the moment (v. 3.7) not all Excel functions have been implemented. I've made the relevant subfunction (xls2jpoi2oct) fall back to cached formula results (and yield a suitable warning) for non-implemented Excel functions while reading Excel files. <BR>
<BR>
-OpenXLS (an open source version of Extentech's commercial Java-xls product) is still experimental. It seems to work faster than JExcelAPI, but it has other issues - i.e., it locks the .xls file and the unlocking mechanism is a bit wonky. Sometimes xls files keep being locked until Octave is shut down. <BR>
+<b>OpenXLS</b> (an open source version of Extentech's commercial Java-xls product) is still experimental. It seems to work faster than JExcelAPI, but it has other issues - i.e., it locks the .xls file and the unlocking mechanism is a bit wonky. Sometimes xls files keep being locked until Octave is shut down. <BR>
<BR>
-UNO (invoking OpenOffice.org or clones behind the scenes, a la ActiveX) is experimental. It works FAST (i.e., once OOo itself is loaded which can take some time) and can process much larger spreadsheets than the other Java-based interfaces because the data are not entered in the JVM but in OOo's memory.<BR>
-A big stumbling block is that odsclose() on a UNO xls struct will kill ALL OpenOffice.org invocations, also those that were not related to Octave! This is due to UNO-Java limitations. A fix is under development.<BR><BR>
+<b>UNO</b> (invoking OpenOffice.org or clones behind the scenes, a la ActiveX) is experimental. It works FAST (i.e., once OOo itself is loaded which can take some time) and can process much larger spreadsheets than the other Java-based interfaces because the data are not entered in the JVM but in OOo's memory.<BR>
+A big stumbling block is that odsclose() on a UNO xls struct will kill ALL OpenOffice.org invocations, also those that were not related to Octave! This is due to UNO-Java limitations.<br>
+The underlying issue is that when Octave starts an OpenOffice.org invocation, OpenOffice.org must be closed for Octave to be able to exit; otherwise Octave will wait for OOo to shut down before it can terminate itself. So Octave must kill OOo to be able to terminate.<br>
+A way out hasn't been found yet.<br><br>
All in all, of the three Java options I'd prefer Apache POI rather than OpenXLS or JexcelAPI. But the latter is indispensable for BIFF5 formats. Once UNO is stable it is to be preferred as it can read ALL file formats supported by OOo (viz. wk1, ods, xlsx, sxc, ...)</DT>
-<DT>Some notes on the choice for Java:</DT>
+<DT><br>Some notes on the choice for Java:</DT>
</DL>
<OL>
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
