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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: users-h...@openoffice.apache.org
