View Issue Details

IDProjectCategoryView StatusLast Update
0012484mantisbtcsvpublic2016-12-06 08:58
Reporterbasil.mathew Assigned To 
PriorityhighSeverityminorReproducibilityhave not tried
Status confirmedResolutionfixed 
Product Version1.2.2 
Summary0012484: CSV and Excel exporting issue...

CSV and Excel exporting issue...

Excel Export is not working in linux os(openOffice 3.2.0) Actulally the file is got downloaded with xml extension but not shows anything while opens.the file contains xml nodes i see but not open in OpenOffice or in a browser.

Also The CSV export is not opening in windows (excel).Same issue is there.

Where CSV export is working in linux and Excel export is working in Windows client.

Is this becoz of any platform related issue?How to solve this issue?



related to 0013370 closedrombert CSV export specifies incorrect MIME type 




2010-10-29 05:29

developer   ~0027192

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:

AFAIK OpenOffice doesn't support this format.



2011-10-05 18:59

reporter   ~0029916

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



2012-01-27 17:31

reporter   ~0031067

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



2012-01-29 10:26

developer   ~0031074

Reminder sent to: grangeway

I don't see any format difference between 1.2 and 1.3
Are you talking about non commited changes?



2012-02-04 11:48

developer   ~0031121




2012-03-14 18:06

developer   ~0031461

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.



2012-10-20 20:00

reporter   ~0033294

this is fixed in the mantis-2.x branch



2012-10-21 07:04

reporter   ~0033296

0012484:0031461 is still valid, reopening



2013-04-07 10:45

reporter   ~0036532

Atrol's comment is still valid, reopening.



2013-04-07 13:15

reporter   ~0036535

see the master-2.0.x branch for fix



2015-01-18 22:51

manager   ~0042192

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



2015-01-19 03:28

developer   ~0042197

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.




2016-11-15 15:57

developer   ~0054530

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



2016-12-05 17:18

developer   ~0054684

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 (

  • 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


2016-12-06 05:35

developer   ~0054690

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.


  • 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 ?


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.


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 ;)




2016-12-06 06:15

developer   ~0054693

Last edited: 2016-12-06 06:16

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



2016-12-06 08:54

developer   ~0054698

Last edited: 2016-12-06 08:58


In this order:
Mantis-csv Mantis-excel Spout-xlsx PHPexcel-xlsx

time in seconds, memory in MB

2400 bugs
time 4,2 4,9 6,1 12,5
memory 10,00 8,19 10,00 38,50

10k bugs
time 19,9 17,5 25,7 56,8
memory 10,00 13,94 10,00 127,83

50k bugs
time 194,7 81,3 120,9 NA
memory 20,80 56,75 12,00 NA

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.