Filesize in PDF Export 4.9 vs 4.9.51
Hi,
after installing the newest version of FR the file size of an exported PDF of the same report increases from 37KB in stable version 4.9 to 181KB in current version 4.9.51 without any other change. Because I create automatically hundreds of PDFs, zip them and send them via mail this is a great problem, because my customer cannot receive such big messages. What has changed, what can I do against this?
Michael
after installing the newest version of FR the file size of an exported PDF of the same report increases from 37KB in stable version 4.9 to 181KB in current version 4.9.51 without any other change. Because I create automatically hundreds of PDFs, zip them and send them via mail this is a great problem, because my customer cannot receive such big messages. What has changed, what can I do against this?
Michael
Comments
Just delete line 1761 "and TfrxCustomMemoView(Obj).WordWrap".
A solution if you not have the source is maybe to set WordWrap in all CustomMemoViews to TRUE; if I understand source right the new version exports CustomMemoViews with WordWrap = FALSE as bitmap, which results in the large file size.
I cannot go back to stable version 4.9, because there I get an error about system resources, I think its a memory leak which is fixed in current version.
Michael
Also in v4.9.64 I found another size issue (I've only just moved up from v4.7 so cant say exactly when the problem arrived). In function TfrxPDFExport.Start: Boolean; if FProtection is true (any passwords defined) then FEmbedded is forced true - which takes a 35k file using Arial and Times New Roman up to 903kb!
The choice to force embedded fonts with protected PDFs seems to be deliberate which makes me wonder if there is some PDF standard reason for doing so... but all the browsers I have tried are quite happy with the PDFs I create without forcing FEmbedded to true. Note that I often create PDFs with an owner (not a user) password in order to allow printing but not alteration - and like Michael I send out hundreds of PDFs by email and want to keep the size as small as possible.
Even worse though is the situation mentioned by "qworboys" above relating to the Fonts being embedded if you put a password on the PDF file. I didn't even realize this. I just tested it in V4.9 (Stable) and the same report (which uses only Arial) went from 15KB to 1MB !!
This is ridiculous. How can I expect my clients to mail out 200 reports of 1MB each? This is a deal-breaker for me. I can't use the PDFs like this, and I can't tell my clients not to put passwords on the file.
@FR : I seriously hope that you guys come up with some solution to this. The PDF exports are one of the main reasons I use FR, but in it's current state the PDF export is unusable (for me at least).
It seems they have installed the change suggested by blackflag so that part of the problem is now gone.
In regard to file size issues with encrypted/protected files. They have created a new property called EmbedFontsIfProtected which defaults to true (ie. it defaults to generating humongous files). Internally this is stored as FEmbedProt.
BEWARE: If you set EmbedFontsIfProtected to false (ie. telling the processor NOT to embed fonts even if protected) then the resulting file will have trouble with Adobe Acrobat Reader (v8 and v9 tested and both gave problems). The file reads fine inside the PDF X-Change Viewer.
The files I was generating uses Arial, Arial-bold and Arial-Italic (and I think some times new roman). When I use EmbedFontsIfProtected=false and set an Owner password (no user password) then Adobe reports "Cannot find or create the font 'Arial,Bold'. Some characters may not display or print correctly." And that is one big under-statement. Not even the non-bold characters print, all characters come out as dots.
For now I am reverting back to the old PDF processor. The other thing I noticed as a result is that Adobe is really slow opening the files produced by the new pdf processor, now I am back with the old and everything is nice and fast again.
What exactly do you mean as 'old pdf processor'?
Which version is working best for you?
Thanks
In the ExportPack subdirectory is a file called frxExportPDF_old.pas. I rename the existing frxExportPDF.pas file (not being as polite as a I could be) and then rename the "old" file to frxExportPDF.pas. Voila, you have the old 4.7 and before PDF processor.
I guess it is missing some of the features being introduced by the new processor but at least it has been working fairly reliably for me. The new processor just hit one too many problems for me to keep trying to use it.
Hmm... I did just notice something in the changes.txt file (under 4.8 section). It talks about the new processor being for Delphi 7 and above. I am still building this particular app with Delphi6 (I am still working on getting other code changed over to D2010), so I guess the problem could be specific to building under Dephi6.