openoffice-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mariusz `shd` Gliwiński <alienballa...@gmail.com>
Subject Re: [dev] Performance of exporting through open office
Date Mon, 15 Jul 2013 13:03:35 GMT
15.07.2013 12:28, Dennis E. Hamilton said:
> If what you want to *produce* is xls or xlsx, you might want to look into the Apache
POI project.  That project provides Java libraries for manipulating and producing such documents.
> <http://poi.apache.org/>
Thank you for your answer. We need to both - read and write, most of 
data can be processed row-by-row though. Looks like i initially expected 
too much convenience. I'll probably read more about stream-based java 
libraries (originally our software is php). I don't know how realistic 
is to have formulas and colors *stream-based*, however if someone knows 
about it - i'd be glad to hear about solutions like that.
> Otherwise, I think the best option is the OpenOffice SDK.
I tried to fill cells manually and import from database (both using 
UNO). Unfortunately both ways are much slower than what we've had 
before. If there are any other methods to fill the sheets and export, 
i'd love to try them out.
> There is, of course, document model and library access available within Microsoft Office
and Visual Studio extensions for Microsoft Office.  I assume that is not an option for you,
although I would think the performance of consuming the documents you are producing might
be an issue to address as well, and that might be a better place to address it.
I've been thinking about using C# on MS Windows + Office, but is it 
worth to setup and maintain the whole new server for it? Is the 
performance difference that big?
> PS: CSV is always an option.  It doesn't work for formulas and cell coloring, etc., though.
 There is a form of single-file Excel spreadsheet in XML that might be suitable.  There are
also HTML formats for XML spreadsheets that might be easier to emit.  Your document might
be too complicated or too large for these cases.  One way to find out is to make a small version
having the essential features you need, in Excel, and then see whether and how well those
are produced in flat XML and HTML.  Then you can examine them for the structure that you need
to replicate with greater-sized documents.  Scaling experiments can be conducted to determine
if these are feasible to produce at your size and also to consume by the intended recipients.

We already have separate code-path for CSV exports, however the client 
insists on XLS. Of course we can make one export for small files (with 
colors and formulas), and another one for simple but large exports. I'll 
still look a bit more for unified solution though.

Thanks,
Mariusz Gliwiński

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@openoffice.apache.org
For additional commands, e-mail: users-help@openoffice.apache.org


Mime
View raw message