openoffice-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From shd <>
Subject Re: [dev] Performance of exporting through open office
Date Mon, 15 Jul 2013 15:10:53 GMT
Apache POI is exactly what i needed. Thanks for your advice.

2013/7/15 Mariusz `shd` Gliwiński <>

> 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.
>> <>
> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message