Hi Benjamin,
sorry for a long answer.
Your question made me review & update some of the scripts and I also
found & fixed a few more bugs. Please use the svn version of the io
package, notably odsopen, xlsopen & odswrite.
(I cc'd [email protected])
Read on...
Benjamin Lindner wrote:
Philip Nienhuis wrote:
Benjamin Lindner wrote:
I am using have JRE 1.6.0_13, odfdom-0.9, jOpenDocument-1.2b2 and
^^^^^^^^^^
this should of course read odfdom-0.8
anyway, FTR it seems this is triggered by version 0.8 of odfdom
It works correctly with odfdom-0.7.5.
I suppose it should work with any odfdom jar >= 0.7.5 so I need to
look into it anyway.
Thanks for the heads up on the new odfdom version.
No need to hurry on my behalf :)
I'd like to distribute all the jars with the mingw32 installer so I did
some testing on your xls/odf code. There is a working version of odfdom
available and that's fine with me.
Shipping all jars means that the size of the installer might almost
double... That said, Mathworks also ships a big number of jars with ML
(IIRC about 60 or maybe even more).
I'm still waiting for an updated jOpenDocument version; the developers
told me that a new version with much desired features was almost
finished. I really hope that will happen soon as it gives a chance to
perhaps eliminate the odfdom & xercesImpl jars and replace it by one
significantly smaller jar file, and jOpenDocument is probably (much)
faster too.
So perhaps you can leave out the jOpenDocument jar this time (it's only
2.5 MB anyway).
I am thinking on how to enable the xls/odf interface with minimal
requirements for the user, so I'd like to have the jars added to
classpath automatically. Currently io does not depend on java, so I
can't really put it in io's PKD_ADD, rather in java's PKD_ADD.
It was on purpose that io is kept independent of java. On Windows there
can also be a COM/ActiveX interface but io shouldn't be dependent on the
Windows package either.
Can't the jars simply live in .\bin or .\lib? (in octave's installation
directory?)
Btw (I'm no java expert...) is is essential to add jars to the
classpath?In other words, it is not sufficient to have them in PATH? Is
there an environment variable that acts as supplement to java's classpath?
Well, I'm no java guru either. AFAIK Java does need a separate search
path for its class files (the jars). Michael might have an authorative
answer.
Octave's javaclasspath only returns the dynamic java classpath (i.e.
loaded by javaaddpath). Perhaps the jars can be placed in the static
classpath. But I don't know how to uncover that.
For one, the rt.jar in the java installation (jre) must be in that
static classpath as it doesn't need to be in the dynamic javaclasspath.
Same goes for octave.jar in the .\share\octave\packages\java-<version>
directory.
BTW this observation made me remove the check for rt.jar in xlsopen /
odsopen - new versions are in svn. Please try those (+ new odswrite.m)
According to "help javaaddpath", it would suffice to have all the needed
jars in one directory and javaaddpath would only be needed to add that
directory to the class path. But on my Windows box that doesn't work as
advertised. I'll post separately about that.
The spreadsheet function files only worked for me if fully qualified
paths to + including the individual jars had been specified explicitly.
I've put the javaaddpath statements in my octaverc file. I'll attach a
template for it, which helps to ensure that errors in one statement
don't screw up processing of the next statements.
It's great to have this feature implemented - it was something I missed
for quite some time. Thanks again :)
My pleasure!
But, there's still much left to be desired.
*Speed* for one thing - especially writing ods is currently painfully
slow; transferring a 1024x500 array of random floats takes in the order
of 35 mins on my Core Duo box (OpenOffice.org itself only needs 7 secs
to copy "=rand()" to A1:AMJ500 + 12 secs for saving it to disk).
That's partly due to the complexity of the ods file format - lots of
if-then-else constructs are needed. Perhaps it would become faster if
more code could be ported from octave script to java itself. That's
exactly what the jOpenDocument project is about.
Philip
## Set up javaclasspath
unwind_protect
# Basic POI
javaaddpath ('/path/to/poi/poi-3.6-20091214.jar')
javaaddpath ('/path/to/poi/poi-ooxml-3.6-20091214.jar')
unwind_protect_cleanup
end_unwind_protect
unwind_protect
# POI+OOXML
javaaddpath ('/path/to/poi/poi-ooxml-schemas-3.6-20091214.jar')
javaaddpath ('/path/to/poi/xbean.jar')
javaaddpath ('/path/to/poi/dom4j-1.6.1.jar')
unwind_protect_cleanup
end_unwind_protect
unwind_protect
# JExcelAPI
javaaddpath ('/path/to/jxl/jxl.jar')
unwind_protect_cleanup
end_unwind_protect
unwind_protect
# ODS Toolkit
javaaddpath ('/path/to/otk/odfdom-0.7.5.jar')
javaaddpath ('/path/to/otk/xercesImpl.jar')
unwind_protect_cleanup
end_unwind_protect
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Octave-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/octave-dev
