#1 Re: PDF Engine » Bitmap with height 1 pixel results in a corrupted file » 2018-01-23 09:48:15

ab wrote:

I guess the bitmap should not be drawn at all... what do you think?

In my case, I do have such a bitmap that contains information I need on the pdf (might seem silly, but that's how it is, and I have to work with that). So just not drawing is not an option for me.

ab wrote:

AFAIR it is because PDF boxes coordinates expect that.

I'll try to look further into that later this week, it seems a bit peculiar.

#2 PDF Engine » Bitmap with height 1 pixel results in a corrupted file » 2018-01-18 07:28:02

Marsh
Replies: 3

Hi,

after having used SynPDF for years without any issues, I stumbled upon a small problem today which leads to corrupted PDFs. I found out what's happening, but not sure about the proper solution.

So basically, my application tried to create a pdf that contains a Bitmap with a height of 1 pixel. In the procedure TPdfEnum.DrawBitmap, the bitmap size R is rescaled to variable Box in the function BoxI/RectI. But this rescaling results in a height of 0, which then leads to a corrupted PDF file (often, the PDF ends up corrupt, and if not, it usually does not continue drawing any elements that were added after the bitmap).

1. Why are both the right and bottom coordinates for variable Box shifted by -1 in function RectI?
2. Maybe there should be some error handling when height or width of the variable Box is 0, or the bitmap should not be drawn at all?

See the code section below. variable ClipRc is checked if it's actually a valid rectangle, but variable Box is not.

    // draw the bitmap on the PDF canvas
    with Canvas do begin
      R := Rect(xd, yd, wd+xd, hd+yd);
      NormalizeRect(R);
      Box := BoxI(R,true);
      ClipRc := GetClipRect;
      if (ClipRc.Width>0) and (ClipRc.Height>0) then
        Doc.CreateOrGetImage(B, @Box, @ClipRc) else // use cliping
        Doc.CreateOrGetImage(B, @Box, nil);
      // Doc.CreateOrGetImage() will reuse any matching TPdfImage
      // don't send bmi and bits parameters here, because of StretchDIBits above
    end;

#3 Re: PDF Engine » PDFEngine Clipping Implementation + Output stream optimizations » 2018-01-17 09:24:30

Hi MtwStark,

Thanks for your fixes. I have used my workaround for years now, but I'll look into this when I get the chance.

#4 Re: PDF Engine » EMF clipping problem » 2015-03-18 10:22:50

Hi Tom,

sorry for my delayed answer.
Yeah I noticed that problem, that's why i mentioned it works for a single clipping rectangle only. I couldn't figure out yet how to resolve that issue unfortunately.

#5 Re: PDF Engine » EMF clipping problem » 2015-02-21 10:32:11

Well right after I posted the above message, I guess I found part of the bug. I made a quick fix that works, at least for a single clipping rectangle.

In SynPdf.pas in the function EnumEMFFunc, change the EMR_INTERSECTCLIPRECT statement:

EMR_INTERSECTCLIPRECT:
  begin
    ClipRgn := e.IntersectClipRect
      (e.Canvas.BoxI(PEMRIntersectClipRect(r)^.rclClip,
      true), ClipRgn);

    e.Canvas.Clip;
    with e.Canvas.BoxI(PEMRIntersectClipRect(r)^.rclClip, true) do
      e.Canvas.Rectangle(Left, Top, Width, Height);
    e.Canvas.EoClip;
  end;

Furthermore, I noticed a bug in TPdfCanvas.EoClip, instead of upper case W, lower case w should be added to the stream, so:

procedure TPdfCanvas.EoClip;
begin
  if FContents <> nil then
    // FContents.Writer.Add('W*'#10);
    FContents.Writer.Add('w*'#10);
end;

#6 Re: PDF Engine » EMF clipping problem » 2015-02-21 10:16:38

Hi,

I'm getting great results with this library, it made generating a Pdf really easy. But I also noticed that clipping for EMF is not supported. So far I managed to get around with a hack, but now I'm looking for a proper solution.
Would be great to see an update on that soon.

Cheers

Board footer

Powered by FluxBB