on 04-04-2014 10:06 PM
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.
As far as I know there is no way to reduce the size of any exported fily type.
-Ludek
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
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
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.
User | Count |
---|---|
93 | |
10 | |
10 | |
9 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.