mantisbt-help mailing list Comment from David (dhx)
The "Excel Export" feature uses the deprecated (and completely useless)
Excel XP-2003 format as described here:
http://en.wikipedia.org/wiki/Microsoft_Office_XML_formats

AFAIK OpenOffice doesn't support this format.

Can you retry CSV export with latest 1.2.x code from Git? It should open in Excel just fine.

1.3 will generate excel files in office 2007/2010 format so should resolve this issue - I too used to have the same problem in the 1.2.x releases

Reopened

Reopened, the issue is not fixed in master branch at the
official repository.
There is no patch / changeset attached. This will confuse any user who has a look at this issue.

this is fixed in the mantis-2.x branch

0012484:0031461 is still valid, reopening

Atrol's comment is still valid, reopening.

see the master-2.0.x branch for fix

This is reproducible on 1.3.x release on other platforms as well.

Grangeway wrote code [1] to fix the Excel/CSV exports using PHPExcel library. I have not tested it, although I've used PHPExcel for other purposes and found it to be a good tool.

The commit does not apply cleanly on master, but it's probably worth using that rather than writing something from scratch. I did not check whether there are any follow-up commits in the master-2.0.x branch [2] either.

[1] https://github.com/mantisbt/mantisbt/commit/69456d94bf93196e97b624258259f084b9993fa3
[2] https://github.com/mantisbtarchive/mantisbt/tree/master-2.0.x

Until recently i could open the xml generated files with librOffice.
But now i cant...

Anyway, maybe it's time to work a better solution...

I have tried a quick implementation with PHPExcel but i see some downsides:

• very easy to work with.
• A quite big include library. It has a lot of functionality, of which we would only use a small part of it: just the excel writer, and using only simple formats
• Relatively high memory usage. As it writes an in memory object before outputting as a final document, memory increases linearly with data size.
• Slow, due to the complex features (which are not actually needed)

Another library that i reviewed: Spout (https://github.com/box/spout)

• Seems to be active and well supported.
• Simple xlsx/ods writer, no in-memory buffer, but uses filesystem to stream and zip the xml as part of the format specification.
• very low memory usage, constant usage.
• very fast
• licensed as Apache 2, which is not suitable to be included in GPL project

Having looked at various other Excel libraries for PHP in the past for another project, PHPExcel was the only one I found that has good, active support and keeps evolving. I also tried one called SimpleExcel (on Github) which is more lightweight, but has not been updated since 2013.

PHPExcel

• A quite big include library.

Is that really an issue ? Disk space is cheap...

It has a lot of functionality, of which we would only use a small part

True, but not really relevant IMO

Relatively high memory usage

I have never used PHPExcel for very large exports (the biggest files I ever generated were a few hundred rows at most) so I did not experience any issues with memory usage or performance.

Did you reach any limits performing large exports ?

Slow

What is the definition of "slow" ? When extracting a large amount of data, I believe it is acceptable to have to wait a few seconds for the file to be generated.

Spout

licensed as Apache 2, which is not suitable to be included in GPL project

I think you got that backwards... My understanding, which seems to be confirmed by FSF [1][2] is that it is acceptable to include an Apache2 library into a GPL (v3) project, but the reverse is not true. MantisBT is released under GPL "version 2 of the License, or (at your option) any later version." so I think we should be OK - but IANAL ;)

[1] http://www.gnu.org/licenses/license-list.html#apache2
[2] https://www.apache.org/licenses/GPL-compatibility.html

Did you reach any limits performing large exports ?
What is the definition of "slow"

I don't have a benchmark atm. But "very noticeable" slower.
Memory is linear so it will grow with size, i reached limits at some-10ks, iirc

if interested i can refresh with actual numbers.

it is acceptable to include an Apache2 library into a GPL (v3) project

True, but not into a GPL2. As far as i know, current license is GPL2

@dregad

time in seconds, memory in MB

PHPExcel breaks when reaching 128MB at ~30k bugs, but i'm not sure that after 10k it's actually working, since at that point the memory has reached maximum and stops growing.

The memory increase is due to output buffering and/or library overhead.
Bug cache is constant in memory usage, as seen with Spout since this library use filesystem to buffer the output.

EDIT (dregad): convert benchmark data to markdown table

The original spout library mentioned by @cproensa in 0012484:0054684 is no longer maintained (archived by the owner on May 26, 2022).

A MIT-licensed, community-maintained fork is available at https://github.com/openspout/openspout