cancel
Showing results for 
Search instead for 
Did you mean: 

Reducing the size of xls exports that contain graphs.

Former Member
0 Kudos

I'm looking for a way to correct the sixe of xls reports that contain graphs.  I did some digging in the resultant .xls and it seems the MSODRAWINGGROUP and subsequent CONTINUE blocks are filled with mostly NULLs (0 value bytes).  To me it looks like CRJ is creating an EMF picture, compressing it to a EMZ and then storing it as if it was still the size of the EMF.  Thus tons of wasted space for every subsequent image.  (In the file I studied it had 9 graphs and 8 40-80K blocks of NULL!  So the pictures used 618K rather than 28K!

I've tried opening the resultant XLS in POI and have yet to figure a way to surgically trim this fat.  (I was able to trim maybe 1% of size by letting POI toss a few superfelous records, but not these large NULL blocks.  About the only solution I see is to use a licensed copy of excel and this adds a whole lot of issues since the application it not run on windows.  It seems POI does not support EMF format fully.  (atleast thats what the docs said, yet I was able to EXTRACT the EMF data and view it with Office viewer (OIS.exe)

I've tried ssconvert and the images are lost.  What else could I try?

I've tried 12.2.14 and 12.2.217 with no improvement.

Accepted Solutions (0)

Answers (1)

Answers (1)

former_member183750
Active Contributor
0 Kudos

As far as I know there is no way to reduce the size of any exported fily type.

-Ludek

Former Member
0 Kudos

Ludek,

  What I forgot to mention is we believe we did not see this behavior when we used 12.2.208.  Yet in 12.2.208 we had a very similar issue with PDF (PDF was much larger than it is now with 12.2.214 or 12.2.217)).  So any chance of this getting fixed in a newer version of CRJ?  This clearly looks to be a bug.

former_member183750
Active Contributor
0 Kudos

Hi Matthew

If I could be convinced that this was not an issue in SP 2... But lets back up a bit before we dig into that one.

This post being in CR for Eclipse, are you seeing this issue only when exporting in a Java app?

Can you duplicate the issue in the CR designer?

If this can be replicated in the designer, can you try with SP 6?

https://share.sap.com/a:7qm6he/MyAttachments/8b6e9d26-b5e8-426d-940f-25a795d193bb/

If this is an issue in Java "only", I can see about getting this tested. I don't deal with Java - just jump in here occasionally. Now, just to be on the same page as far as the testing, would you be able to attach report that demos this issue? It will need to have "saved data" with it.

I'm out of here in a few minutes, and back on Monday, so I'll do more investigating, etc., then.

- Ludek

Former Member
0 Kudos

Designer 2011 does not seem to have this issue.  I had already sent in a example with data via SAP support.  I could probably dummy up a new report and produce the same issue.

Former Member
0 Kudos

I have my "dummy" report but I can not attach it.  I get "The content type of this attachment is not allowed."

So I've renamed the .rpt to .txt

When I export from designer I get a .xls about the same size as this .rpt.  From CRJ I get a 1.3MB xls.  When I open that in excel and save I get a 100K file.  This completely matches the pattern I saw.. (size of uncompressed EMF: 40-80K) * (number of graphs - 1).  This report has 16 graphs.  and it this case 80K*15 = 1.2MB which is roughly the size increase due to NULL space.

Former Member
0 Kudos

Can you please have someone look at the .rpt I attached to this thread?  Thanks!

former_member183750
Active Contributor
0 Kudos

Apparently this issue has been reported to R&D. I do not have a tracking number yet, but once I do, I will post it here. I'll also at that time get the ETA for a fix.

- Ludek

Former Member
0 Kudos

Excellent!  I await the tracking number and ETA.