Report with EMF's eksports to PDF at huge file size

Petter S.

We're having two problems with file size when exporting to PDF.

We have several form-like reports where the forms are read from .EMF files, an put into Picture-objects if FR. The EMF's contains vectorized data. The reports works fine in preview and print, but when exporting to the PDF we are having problems with the file sizes. It seems like the problem are caused by the EMF's beeing exported as bitmap. To get a aceptable quality in the PDF we have to check 'Print optimized, causing a 4-page report to export to PDF as 3 mb.
If I prints the same report to my Bullzip PDF-printer, I get vectorized forms, and a file size of 100 kb for the same report. And if I go back to our previous version using Rave, I get vectorized PDF and 50 kb.

Attached to this post there is av simple one-page example. FR exports this at 778 kb when checked 'Print optimized'. Bullzip exports the same at 53 kb.

This is a huge problem for our customers, as they need to email good quality PDF to their customers, typical 5-6 reports in one e-mail.

The second problem we have is that the PDF's does not seem to be readable on Apple (iPhone etc) if we dont check 'Embedded fonts'. We use only font Arial in our reports, and without embedded fonts, Apple does not show bold text at all. To solve this we check embedded, causing each file to increase 1600 kb... The difference from Rave (our Bullzip PDF-printer) is the same here: They produce small PDF's, readable for Apple.

Is there anything we can do to fix this in FR4? Will FR5 fix this? Does anybody know if eDocEngine from Gnostice is a good alternative for PDF-export from FR4?

Thanks!

Petter

technisoft

That the PDF export filesizes are huge has been the subject of numerous threads. Part of it is that FR4 embeds the whole character set in the PDF, no matter whether the characters are used or not.
It has been reported that FR5 will correct this an only embed the actual characters used.

I can't comment on the problems with the pictures.

The lack of offical comments, and that FR5 is now overdue by a year, based on early notifications, and if some other post are to be believed has a low priority even after this time, is really becoming a serious issue.

I think it is high time that the FR team comes clean with what they are planning to do, including the new capabilities upgrades will offer. History is however not on the FR customer's side.

Petter S.

technisoft wrote: »

That the PDF export filesizes are huge has been the subject of numerous threads. Part of it is that FR4 embeds the whole character set in the PDF, no matter whether the characters are used or not.
It has been reported that FR5 will correct this an only embed the actual characters used.

Thanks!

We have now solved our problems, by using PDF-export from eDocEngine instead of the native one in FR. Now we get comfortable file sizes with embedded fonts, end EMF's exported as vectordata (instead of bitmap).

Petter

pellelil

Petter S. wrote: »

Petter S. wrote: »

That the PDF export filesizes are huge has been the subject of numerous threads. Part of it is that FR4 embeds the whole character set in the PDF, no matter whether the characters are used or not.
It has been reported that FR5 will correct this an only embed the actual characters used.

Thanks!

We have now solved our problems, by using PDF-export from eDocEngine instead of the native one in FR. Now we get comfortable file sizes with embedded fonts, end EMF's exported as vectordata (instead of bitmap).

Petter

Thinking about the same solution, can I generate the print in FR and then simply export it to PDF using eDocEngine (have they made an exporter for FR) ?

Pelle

Petter S.

pellelil wrote: »

Thinking about the same solution, can I generate the print in FR and then simply export it to PDF using eDocEngine (have they made an exporter for FR) ?

Pelle

Yes, eDocEngine adds more export filters to FR. PDF is one of them. We have simply removed the native FR PDF-export, and added the one from eDocEngine.

Andy2012

Well we also tried using eDocEngine but we have a few customers reporting about wrong papersizes ... well the Report is scaled to much .. so it is to huge for the paper format .. wrong paper-sizes are listed in the pdfs ... (no exceptions or stuff .. gnostice tells us *g* "We cannot reproduce it ... " doh ..

Petter S.

Andy2012 wrote: »

Well we also tried using eDocEngine but we have a few customers reporting about wrong papersizes ... well the Report is scaled to much .. so it is to huge for the paper format .. wrong paper-sizes are listed in the pdfs ... (no exceptions or stuff .. gnostice tells us *g* "We cannot reproduce it ... " doh ..

Been there...

This is related to the screen ppt-settings on the customers computer. A setting of 120 ruins your PDF-export.

We got this solution from Gnostice:

Please add the following code under FormCreate event and try once.

if Screen.PixelsPerInch <=120 then
  begin
  gtPDFEngine1.InputXRes :=Screen.PixelsPerInch ;
  gtPDFEngine1.InputYRes :=Screen.PixelsPerInch;
  end
  else
  begin
      gtPDFEngine1.InputXRes :=96 ;
  gtPDFEngine1.InputYRes :=96;
  end;