Using PDF Engine in TPrintPreview and a problem i entered

PictoSelector · 2010-07-19 20:04:12

Hi,

This PDF Engine is promising, but maybe not complete. But of course i could do something wrong here :-)

The issue i'm facing:
I want to use the PDF Engine in the excellent TPrintPreview of delphi area (http://www.delphiarea.com/)

That is not that difficult, but my output is wrong, the images in it are 'printed' overlapped.

I've created a example that is using the same meta file and code as in TPrintPreview. This makes it easier to debug...
(i'm using the latest 2010-07-19 code from the source control)

The example can be downloaded from:
http://www.pecsforall.com/downloads/TestSynPDF.zip

If you need more information please let me know.

Martijn van der Kooij

ab · 2010-07-19 22:12:15

I just looked at the emf file generated.

It just a bunch of StretchDiBits... it's not optimized for generating a PDF! PDF prefers vectorial data as bitmap.

I'm not sure you're taking the PDF generation from the right side... I think it's worth looking after vectorial meta file generation, instead of these bitmaps.

In all cases, here is the code which could be faulty:

  EMR_STRETCHDIBITS: begin
    NormalizeRect(PEMRStretchDIBits(R)^.rclBounds);
      with PEMRStretchDIBits(R)^ do // only handle RGB bitmaps (no palette)
        if (offBmiSrc<>0) and (offBitsSrc<>0) then begin
          E.DrawBitmap(xSrc,ySrc,cxSrc,cySrc, xDest,yDest,cxDest,cyDest,iUsageSrc,
            pointer(cardinal(R)+offBmiSrc),pointer(cardinal(R)+offBitsSrc),
              rclBounds.Left,rclBounds.Top,E.Canvas.Doc.ForceJPEGCompression);
        end;

Perhaps the EMR_SETSTRETCHBLTMODE action should be implemented in the engine: it was not used yet.

If you can make it work for your content, please share!

Thanks for your interest.

PictoSelector · 2010-07-20 07:19:36

ab wrote:

I just looked at the emf file generated.
It just a bunch of StretchDiBits... it's not optimized for generating a PDF! PDF prefers vectorial data as bitmap.

I know, but that the way that TPrintPreview works: it creates a metafile for each printed page. The other solution would be to paint directly to the pdf which is better to keep the original optimalizations (and images / texts) but requires a lot more rewriting.

ab wrote:

I'm not sure you're taking the PDF generation from the right side... I think it's worth looking after vectorial meta file generation, instead of these bitmaps.
Perhaps the EMR_SETSTRETCHBLTMODE action should be implemented in the engine: it was not used yet.
If you can make it work for your content, please share!

If i make it work then i will surely share it. But i'm looking for several solutions now of the problem that on some systems the original pdf solution of TPrintPreview is failing...

Martijn

ab · 2010-07-20 11:11:06

I've found some solution - now uploaded to the Source Code Repository.

The sample program you supplied above now works as expected - as far as I could see it.

The PDF generated file seems OK, and is very small (77 KB).

I don't think the problem is in TPrintPreview, because metafiles can be vectorial without any problem. See how you print to the TPrintPreview metafile in your main application: perhaps you could print with some GDI vectorial commands instead of raw bitmaps.

PictoSelector · 2010-07-20 13:21:40

This is much better indeed :-) up to the next problem i just found :-(

I've updated the file above with another emf the preview created. The text that is on the right side (with an angle of 90 deg) is not rotated in the pdf.

Thanks a lot for fixing the bitmap problem, i think the rotation error is the only error left. When that works ok i expect to be able to replace the pdf creator in TPrintPreview....

ab · 2010-07-20 16:59:17

Could you send the pdf, emf and source files as for the previous bug?

You can also go to our Source Code, and open a new ticket...

PictoSelector · 2010-07-20 18:58:07

I've update the zip at my site

PictoSelector · 2010-07-20 20:26:03

I've also send my changes in Print Preview to the Print preview forum. So you might see some traffic from it :-)
( http://forum.delphiarea.com/viewtopic.php?f=7&t=1827 )

ab · 2010-07-21 14:40:25

Issue found and fixed. Uploaded to our Source Code repository.

SynPdf Version 1.8.8
- fix small issue with font orientation in metafile enumeration

You're still creating your page using bitmaps. Or your software seems to create vectorial graphics: isn't there any way of creating the drawings using vectorial GDI commands instead of bitmaps? Perhaps I'm wrong and your pics are bitmaps.

PictoSelector · 2010-07-21 15:08:56

ab wrote:

Issue found and fixed. Uploaded to our Source Code repository.
SynPdf Version 1.8.8
- fix small issue with font orientation in metafile enumeration

Thank you, it works like a sharm now :-)

ab wrote:

You're still creating your page using bitmaps. Or your software seems to create vectorial graphics: isn't there any way of creating the drawings using vectorial GDI commands instead of bitmaps? Perhaps I'm wrong and your pics are bitmaps.

The original images are also bitmaps, most of the images are bitmaps, but maybe i can change the way 1800 of the 13000 pictures are handled (those pictures are wmf files and i could handle them that way instead of painting them to a bitmap internally)

I can also change the way the text pictos are created internally, that way they will be much smaller in the resulting pdf and better zoomable.

I'm now testing it more but it looks very promising!!!

Martijn

ab · 2010-07-22 07:47:36

Yes after browsing your web site and discover your very interesting tool, I saw that most pictures are bitmaps. Monochrome bitmaps do compress well, so the resulting pdf file size seems appropriate.

Of course, if you can embed wmf/emf files to the PDF, that could help!

About TPrintPreview, did you see our SynGdiPlus library? There is a way of rendering metafiles with GDI+, i.e. with Anti-Aliaising and smooth drawing. I guess TPrintPreview use TMetaFile to store and render its pages during preview, so perhaps using SynGdiPlus as rendering engine could improve the output. See how it works in our SQLite3Pages unit, which core is more or less the same as a TPrintPreview, but oriented more as a report generating tool.

See http://synopse.info/forum/viewforum.php?id=4
and http://synopse.info/forum/viewtopic.php?id=41

PictoSelector · 2010-07-23 15:01:07

ab wrote:

About TPrintPreview, did you see our SynGdiPlus library? There is a way of rendering metafiles with GDI+, i.e. with Anti-Aliaising and smooth drawing. I guess TPrintPreview use TMetaFile to store and render its pages during preview, so perhaps using SynGdiPlus as rendering engine could improve the output. See how it works in our SQLite3Pages unit, which core is more or less the same as a TPrintPreview, but oriented more as a report generating tool.

I will take this in consideration. First i want to make sure that the change to SynPDF is working out well.
Thanks for you comments!

Martijn

mORMot Open Source

#1 2010-07-19 20:04:12

Using PDF Engine in TPrintPreview and a problem i entered

#2 2010-07-19 22:12:15

Re: Using PDF Engine in TPrintPreview and a problem i entered

#3 2010-07-20 07:19:36

Re: Using PDF Engine in TPrintPreview and a problem i entered

#4 2010-07-20 11:11:06

Re: Using PDF Engine in TPrintPreview and a problem i entered

#5 2010-07-20 13:21:40

Re: Using PDF Engine in TPrintPreview and a problem i entered

#6 2010-07-20 16:59:17

Re: Using PDF Engine in TPrintPreview and a problem i entered

#7 2010-07-20 18:58:07

Re: Using PDF Engine in TPrintPreview and a problem i entered

#8 2010-07-20 20:26:03

Re: Using PDF Engine in TPrintPreview and a problem i entered

#9 2010-07-21 14:40:25

Re: Using PDF Engine in TPrintPreview and a problem i entered

#10 2010-07-21 15:08:56

Re: Using PDF Engine in TPrintPreview and a problem i entered

#11 2010-07-22 07:47:36

Re: Using PDF Engine in TPrintPreview and a problem i entered

#12 2010-07-23 15:01:07

Re: Using PDF Engine in TPrintPreview and a problem i entered

Board footer