I wanted to use the DejaVuLGCSans.ttf font from
http://dejavu-fonts.org/wiki/Download
http://sourceforge.net/projects/dejavu/files/dejavu/2.35/dejavu-lgc-fonts-ttf-2.35.zip

The created PDF is corrupt. Adobe Acrobat Reader shows:

Adobe Illustrator:

Opera opens the file without problems, though.

If I change the font to FreeSans.ttf, the generated PDF is OK.

See the test project (with included font file):
https://drive.google.com/open?id=0Bx-flYubOTroOTVudTAxYkJkTW8

Am I doing something wrong or is this a bug in fpPDF?

Ondrej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160413/455685b1/attachment.html> -------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 5778 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160413/455685b1/attachment.png> -------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 4444 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160413/455685b1/attachment-0001.png>

Ondrej Pokorny wrote

Am I doing something wrong or is this a bug in fpPDF?

It's a bug. The BaseFont, FontName and FontFamily names (in fact any PDFName elemens) may not contain spaces and should be escaped (or encoded). I've fixed it locally, and the patch should be in FPC hopefully some time today.

Thanks for reporting the issue.

Regards,
- Graeme -

Patch is in FPC svn: rev 33495.

The support for compressed images and embedding of raw JPEG is in SVN too, sample program adapted to demonstrate this (-i -j command line options).

Michael.

Great, thank you. Please also take a look at the next project that uses FreeSansBoldOblique.ttf. If range checking is ON, the project fails with a range error in TPDFDocument.CreateFontDescriptor line FDict.AddInteger('ItalicAngle',Fonts[EmbeddedFontNum].FTrueTypeFile.ItalicAngle); (The LongWord ItalicAngle property is out of Integer bounds).

#0 HANDLEERRORADDRFRAME(201, 0x4358ee, 0x15bfd9c) at ..\inc\system.inc:1133 #1 HANDLEERRORADDRFRAMEIND(201, 0x4358ee, 0x15bfd9c) at ..\inc\system.inc:1152
#2 fpc_rangeerror at ..\inc\system.inc:746
#3 CREATEFONTDESCRIPTOR(0x1881628, 0) at
..\..\..\..\..\..\..\software\FPC\trunk_src\packages\fcl-pdf\src\fppdf.pp:3415 #4 CREATETTFDESCENDANTFONT(0x1881628, 0) at
..\..\..\..\..\..\..\software\FPC\trunk_src\packages\fcl-pdf\src\fppdf.pp:3376 #5 CREATETTFFONT(0x1881628, 0) at
..\..\..\..\..\..\..\software\FPC\trunk_src\packages\fcl-pdf\src\fppdf.pp:3352 #6 CREATEFONTENTRIES(0x1881628) at
..\..\..\..\..\..\..\software\FPC\trunk_src\packages\fcl-pdf\src\fppdf.pp:3726 #7 SAVETOSTREAM(0x1881628, 0x185c388) at
..\..\..\..\..\..\..\software\FPC\trunk_src\packages\fcl-pdf\src\fppdf.pp:3750 #8 :35

https://drive.google.com/open?id=0Bx-flYubOTroUHFPSmVkYm1XNkU

Ondrej

El 13/04/2016 a las 13:42, Michael Van Canneyt escribi?:

The support for compressed images and embedding of raw JPEG is in SVN too, sample program adapted to demonstrate this (-i -j command line options).

Hello,

Does the library detect the same image used multiple times ? In the past I was using a pdf generator for a report that has an image as background watermark. The report could be more than 100 pages and the pdf was multi-megabyte because the library adds each page watermark as a new graphic object, instead reuse the same object.

If its not easy to do automagically maybe an API to add a "shared" media object would be useful.

Thank you.

You must add images manually in a list.
Drawing an image means: "draw image N here at (X,Y)" It is up to you to add an image only once and re-use that.

The fpreport engine will add the image only once and will reuse it.

Michael.

Michael Van Canneyt wrote

The support for compressed images and embedding of raw JPEG is in SVN too, sample program adapted to demonstrate this (-i -j command line options).

Thank you very much!

Just 2 points:

1.) Is the "Writeln('Compressing : ',poCompressImages in Owner.Options);" line wanted/necessary? Maybe you forgot {$ifdef gdebug}?

2.) Don't we have too much TPDFOptions for compressing? In the future raw PNG embedding may be added and thus poUseRawPNG will be added (?). Maybe poUseRawJPEG can be omitted and replaced by poCompressImages?

Also 3 options for compressing "poCompressText, poCompressFonts, poCompressImages" seem to be useless for me. I either want to compress everything to get a small file or compress nothing to get a fast file.

Maybe one poCompress would suffice for all 4 (poCompressText, poCompressFonts, poCompressImages, poUseRawPNG)?

(Just a suggestion, feel free to refuse it, it's not that important anyway.)

Ondrej

I will look at it ASAP.

2.) Don't we have too much TPDFOptions for compressing? In the future raw PNG embedding may be added and thus poUseRawPNG will be added (?). Maybe poUseRawJPEG can be omitted and replaced by poCompressImages?

No, they do different things.

Also 3 options for compressing "poCompressText, poCompressFonts, poCompressImages" seem to be useless for me. I either want to compress everything to get a small file or compress nothing to get a fast file.

I prefer more options, it gives more fine-grained control.

We can make a

   CompressAll = [poCompressText, poCompressFonts, poCompressImages];

constant if you want, which will be kept up-to-date with all compression options.

Michael.

No, not needed. As I said, it's not that important.

Still could you please use poUseRawJPEG by default in TPDFDocument.Create? IMO poUseRawJPEG is very useful - it reduces both processing time because JPEG images don't have to be resampled by fpPDF and also keeps the exported PDF small.

Ondrej

I prefer not to, because of several reasons:
- it depends on 3.1 features.
- It forces the examination of all added images.
Examining is a waste of time for me, since I do not use JPEG, only PNG.
- I want the user to know and understand what he is doing. You do, but most will not (or so I think at first sight). By forcing them to enable some options, they will at least think about it. (or so I hope ;) )

In each case, for an advanced user as you, I would expect that the first thing you do is create a TOndrejPDFDocument subclass (or whatever the name). You can set all options there to defaults that you like. (I subclass all components I use for exactly such reasons)

Michael.

No. In 3.1 the size detection is just faster/better.

- It forces the examination of all added images. Examining is a waste of time for me, since I do not use JPEG, only PNG.

No. The only check it does more is
"Handler.InheritsFrom(TFPReaderJPEG)". I don't think it is that time-consuming.
If you disable poUseRawJPEG and you feed fpPDF with a JPEG image, it actually wastes time and resources to resample/resave(/+recompress if poCompressImages is enabled) the image.

In each case, for an advanced user as you, I would expect that the first thing you do is create a TOndrejPDFDocument subclass (or whatever the name). You can set all options there to defaults that you like. (I subclass all components I use for exactly such reasons)

Of course enabling it for myself isn't a problem. The problem is that I don't see any advantage disabling poUseRawJPEG and enabling poCompressImages by default - there is no :)

Ondrej

Yes.
So in 3.0 there is no time gain. You read the image anyway. The detection works by reading the whole image, because it needs the size.

If you know you will have JPEG, you can use the JPEG function.

Sure. When 3.0.4 is out, then we can switch the default.

Michael.

El 13/04/2016 a las 14:52, Michael Van Canneyt escribi?:

You must add images manually in a list. Drawing an image means: "draw image N here at (X,Y)" It is up to you to add an image only once and re-use that.

Hello,

Great, this answer my question completly! :)