mORMot Open Source

Yes, there seems to be some problems with Chinese characters (widestring conversion?) in mORMot2 in Lazarus.

This seems to work fine in Delphi (both Canvas.TextOut and Windows.TextOutW):

var
  pdf: TPdfDocumentGDI;
  S: WideString;
begin
  pdf := TPdfDocumentGDI.Create;
  try
    pdf.AddPage;

    // pdf.UseUniscribe := True; // not needed?
    // pdf.AddTrueTypeFont('SimSun'); // not needed?

    pdf.VCLCanvas.Font.Name := 'SimSun'; // 宋体
    pdf.VCLCanvas.Font.size := 20;
    S := WideString('测试内容');

    pdf.VCLCanvas.TextOut(200, 120, S);

    Windows.TextOutW(pdf.VCLCanvas.Handle, 200, 160, PWidechar(S), Length(S));

    pdf.SaveToFile(ExtractFilePath(Application.ExeName) + 'ceshi.pdf');
    ShellExecute(Application.Handle, 'open', pChar(ExtractFilePath(Application.ExeName) + 'ceshi.pdf'), '', '', SW_SHOWNORMAL);
  finally
      pdf.Free;
  end;

end;

I thought I'd try direct TPdfDocument, skipping the GDI entirely... but that also only works in Delphi and crashes on Lazarus.
(With TextOut instead of TextOutW it works but produces garbage characters logically)

var
  pdf: TPdfDocument;
  S: WideString;
begin
  pdf := TPdfDocument.Create;
  try
    pdf.AddPage;

    S := '发现双引号不正确“问题”';
    pdf.Canvas.SetFont('SimSun', 12, []);
    Pdf.Canvas.TextOutW(100, 600, PWideChar(S));

    pdf.SaveToFile(ExtractFilePath(Application.ExeName) + 'ceshi.pdf');
    ShellExecute(Application.Handle, 'open', pChar(ExtractFilePath(Application.ExeName) + 'ceshi.pdf'), '', '', SW_SHOWNORMAL);
  finally
      pdf.Free;
  end;
end;

So yes, definitely a problem with that code on Lazarus.

I don't think we can help without a more complete reproduceable example.
(including the metafiles if not generated by the example)

Something like this:

    aRect := Rect(0, 0, (300 * 2540) div 96, (300 * 2540) div 96);

But that results in 295x295 for me... ?
(and 96 needs to be the dpi for DC(0))

BTW. That test project doesn't create a EMF which contains an offset WinOrg or non-standard scale, like your original code from this topic does.
So it wouldn't detect the regression for which you opened this topic

I'm not sure what should be visible.
With EMFexplorer, nothing is really shown.

Also... in paint and IrfanView, nothing is shown. (I see in both that the actual image is just 11x11 pixels ?

Yep. Just checked.
My original is this (this is an image with a lot of clip-data):

With the adjusted code I get this (see the white pixels at the lower right edges):

Then with commenting out the 2 inc() lines it's correct again:

So now I have this:

var
  ClipRect: TPdfBox;
//...
      r := pr^;
      // inc(r.Bottom);
      // inc(r.Right);
      ClipRect.Left   := r.Left * Canvas.fDevScaleX;
      ClipRect.Top    := Canvas.fPage.GetPageHeight - (r.Top * Canvas.fDevScaleX);
      ClipRect.Width  := (r.Right - r.Left) * Canvas.fDevScaleX;
      ClipRect.Height := -(r.Bottom - r.Top) * Canvas.fDevScaleY; // Origin is bottom left so reversed
      // with Canvas.BoxI(r, false) do
      with ClipRect do
         Canvas.Rectangle(Left, Top, Width, Height);
      inc(pr);

Now it's still the question if this all still works correctly if there is another fWorldOffsetX and fWorldFactorX.
For that we need more diverse EMF files.

Ha, if you look at the code in LibreOffice... this fix was not for NOT for RegionMode::RGN_COPY but for everything else.

So for RGN_COPY it is absolute coordinates... and for anything else, that fix you point at, translates with WinOrg.

case EMR_EXTSELECTCLIPRGN :
                    {
                        sal_uInt32 nRemainingRecSize = nRecSize - 8;
                        if (nRemainingRecSize < 8)
                            bStatus = false;
                        else
                        {
                            sal_Int32 nClippingMode(0), cbRgnData(0);
                            mpInputStream->ReadInt32(cbRgnData);
                            mpInputStream->ReadInt32(nClippingMode);
                            nRemainingRecSize -= 8;

                            // This record's region data should be ignored if mode
                            // is RGN_COPY - see EMF spec section 2.3.2.2
                            if (static_cast<RegionMode>(nClippingMode) == RegionMode::RGN_COPY)
                            {
                                SetDefaultClipPath();
                            }
                            else
                            {
                                basegfx::B2DPolyPolygon aPolyPoly;
                                if (cbRgnData)
                                    ImplReadRegion(aPolyPoly, *mpInputStream, nRemainingRecSize, GetWinOrg());
                                const tools::PolyPolygon aPolyPolygon(aPolyPoly);
                                SetClipPath(aPolyPolygon, static_cast<RegionMode>(nClippingMode), false);
                            }
                        }

For this individual issue... this might work correctly.
(And if anything pops up, we should fix it at the spot)

Looks like it's just absolute coordinates.

So should be something like this:

      ClipRect.Left   := RCT.Left * Canvas.fDevScaleX;
      ClipRect.Top    := Canvas.fPage.GetPageHeight - (RCT.Top * Canvas.fDevScaleX);
      ClipRect.Width  := (RCT.Right - RCT.Left) * Canvas.fDevScaleX;
      ClipRect.Height := -(RCT.Bottom - RCT.Top) * Canvas.fDevScaleY; // Origin is bottom left so reversed

      // ClipRect := Canvas.BoxI(RCT, false);

The problem now is that we don't have a set of EMF/WMF files with complex and diverse structures to test this with.

From the other topic (from which my patch came) the fix worked perfectly for me.
But somehow, in your code, the fWinOrg is (-100,-100) which throws things off.

Maybe there are other possible problems with other complex EMF files (like when Canvas.fViewSize.cx isn't 1, for which we don't have an example to test with).

For example... in this topic on another forum, you can download a A.EMF and B.EMF.
https://www.vbforums.com/showthread.php … ing-Issues

It seems that SynPDF also has problems with A.EMF to place the objects correctly (namely the big blue ball).
And there is also a small artifact at te right bottom half of that ball.

This has nothing to do with this clipping code but it shows there are more problems with coordinates in the GDI+/EMF translation of SynPDF.

Yes, I also found it is the Canvas.BoxI translation that goes wrong.

MtwStark had a lot of changes to the GDI and clipping code.
But apparently the changes where so big, with several regression errors, it was chosen to revert instead of fixing those problems (which is a shame).

That code is here:
https://synopse.info/forum/viewtopic.ph … 786#p25786

There the TPdfEnum.ExtSelectClipRgn uses an adjusted BoxI() function. Namely Canvas.absBoxI().

      // MTW 2017-11-22 - Logical units to Device units with absolute reference to page origin
      // used for EMF clipping functions, region data coordinats are absolute (not relative to WorldTransform)
      // Inc(RCT.Bottom);
      //ClipRect := Canvas.BoxI(RCT, False);
      // need normalization for winding rule
      ClipRect := Canvas.absBoxI(RCT, true);
      Canvas.Rectangle(ClipRect.Left, ClipRect.Top, ClipRect.Width,
        ClipRect.Height);

Still need to figure out if this can be compressed to just a few simple changes (like you mentioned about offset or size).
Without changing too much in the complete rest of the code.

O, and the i + 1 should just be i in your case
(You start at 1, not 0)

If you are using the latest mORMot2, can you save the metafile to file and try loading it in a separate procedure.
If it still gives you problems maybe you can share that metafile.

(Just to rule out any potential problems in combination with TQRExpBarChart)

I used meta.LoadFromFile and RenderMetaFile() and that worked fine.

You are using the older SynPDF? (Newer source is in mORMot2)

I can't spot the problem exactly... but you have a Pdf.CleanupInstance.
TObject.CleanupInstance should never be called directly.

The aMeta.Clear also seems useless (because that should also be done in aMeta.Free).

Remove those two lines and see if it helps.
Although the error doesn't seem to point to those places, it could be because of the try/finally (and exception handling).

Something like this:

procedure TfPrinterOptions.ExportAsPdf(QuickRep: TQRCompositeReport; aFileName, aDescription: String);
var
  Pdf: TPdfDocument;
  aMeta: TMetaFile;
  i: integer;
  pdfFilter: TQRPDFDocumentFilter;
begin

  if NOT dmVA.aQryVAPraktice.Active then
    dmVA.aQryVAPraktice.Active := True;
  dmVA.aQryVAPraktice.Active := False;
  QuickRep.Prepare;

  Pdf := TPdfDocument.Create;
  try
    Pdf.Info.CreationDate  := Now;
    Pdf.Info.Creator := dmVA.aQryVAPraktice.FieldByName('PrakticeName').AsString;
    Pdf.DefaultPaperSize := psA4;

    for i := 1 to QuickRep.QRPrinter.PageCount do
    begin
      Pdf.AddPage;
      aMeta := QuickRep.QRPrinter.GetPage(i);
      try
        // draw the page content
        Pdf.Canvas.RenderMetaFile(aMeta,1,1,0,0);
      finally
        aMeta.Free;
      end;
    end;
    
    try
      Pdf.SaveToFile(aFileName); // Error Access violation at address 004C4620 in module ...
    finally
      // Send to ...
    end;

  finally
    Pdf.free;
  end;
end;

Shoutout to @everyone...
Does anyone have more experience with rendering metafiles through GDI to PDF via mORMot2 ?

I have emf streams/files (created via TJvRichEdit) with images.
In those emf streams, after the image is drawn with EMR_STRETCHDIBITS.
Followed by a EMR_EXTSELECTCLIPRGN to clip the drawn region to size.
And again followed by several EMR_RESTOREDC.

But in mORMot2 (SynPdf), the clipped region isn't reset when calling RestoreDC.
As a result... everything after this, is clipped away.

My feeling is, that in EMR_SAVEDC/EMR_RESTOREDC (so in Canvas.GSave/Canvas.GRestore), the clipping region should also be reset.

I changed my code here to include GSave/GRestore inside and that does seems to do the job.
But I'm unsure if this is the whole solution. Maybe the other GSave/GRestores can be removed because it should already be done in the emf itself.

(BTW. A small look at llPDFLib DoRestoreDC I see it does the same.)

procedure TPdfEnum.RestoreDC;
begin
  Assert(nDC > 0);
  Canvas.GRestore; // <--- add this
  dec(nDC);
end;

procedure TPdfEnum.SaveDC;
begin
  Assert(nDC < high(DC));
  Canvas.GSave; // <--- add this
  DC[nDC + 1] := DC[nDC];
  inc(nDC);
end;

I will change this in my code and see how it does in production. But maybe someone with more experience can confirm my findings.
@MtwStark @ArnoBrinkman ??

Edit: Ha, I now see MtwStark was already working on that.

procedure TPdfEnum.SaveDC;
begin
  Assert(nDC < high(DC));
  DC[nDC + 1] := DC[nDC];
  inc(nDC);
{$IFDEF TMW_TEST_NEW_CLIPRGN}
  // MTW 2018-01-30 - the problem wasn't GRestore/GSave, but was the invalidation of graphic state parameters
  Canvas.GSave;
{$ENDIF}
end;

https://synopse.info/forum/viewtopic.ph … 786#p25786

It's a real shame more extensive GDI support isn't implemented in mORMot2 itself over the years.

R0141: [037] EMR_SELECTOBJECT	(s=12)	{Table object: 6=OBJ_FONT}
R0142: [033] EMR_SAVEDC	(s=8)
R0143: [022] EMR_SETTEXTALIGN	(s=12)	{iMode(0= TA_LEFT TA_TOP)}
R0144: [033] EMR_SAVEDC	(s=8)
R0145: [030] EMR_INTERSECTCLIPRECT	(s=24)	{rclClip(118,222,131,262)}
R0146: [033] EMR_SAVEDC	(s=8)
R0147: [030] EMR_INTERSECTCLIPRECT	(s=24)	{rclClip(118,242,131,255)}
R0148: [017] EMR_SETMAPMODE	(s=12)	{iMode(8=MM_ANISOTROPIC)}
R0149: [012] EMR_SETVIEWPORTORGEX	(s=16)	{ptlOrigin(118,242)}
R0150: [011] EMR_SETVIEWPORTEXTEX	(s=16)	{szlExtent(13,13)}
R0151: [010] EMR_SETWINDOWORGEX	(s=16)	{ptlOrigin(0,0)}
R0152: [009] EMR_SETWINDOWEXTEX	(s=16)	{szlExtent(106,106)}
R0153: [081] EMR_STRETCHDIBITS	(s=168)	{rclBounds(118,242,130,254), Dest[x:0, y:0, cx:106, cy:106)], dwRop(0x00CC0020), Src[x:0, y:0, cx:4, cy:4, iUsage:0, offBmi:80, Bmi:40, offBits:120, Bits:48] BmiHeader[biSize:40, biWidth:4, biHeight:4, biPlanes:1, biBitCount:24, biCompression:0, biSizeImage:48, biXPelsPerMeter:3779, biYPelsPerMeter:3779, biClrUsed:0, biClrImportant:0]}
R0154: [037] EMR_SELECTOBJECT	(s=12)	{Table object: 2=OBJ_PEN.(PS_SOLID | COSMETIC)}
R0155: [037] EMR_SELECTOBJECT	(s=12)	{Table object: 3=OBJ_BRUSH.(BS_SOLID)}
R0156: [048] EMR_SELECTPALETTE	(s=12)	{ihPal(Stock object: 15)}
R0157: [075] EMR_EXTSELECTCLIPRGN	(s=64)	{iMode(5=RGN_COPY), RGNDATA[ptr:0x066b12f0, size:48, box(118,242,131,255)]}
R0158: [034] EMR_RESTOREDC	(s=12)	{iRelative(-1)}
R0159: [034] EMR_RESTOREDC	(s=12)	{iRelative(-1)}
R0160: [034] EMR_RESTOREDC	(s=12)	{iRelative(-1)}
R0161: [037] EMR_SELECTOBJECT	(s=12)	{Table object: 5=OBJ_FONT}
R0162: [084] EMR_EXTTEXTOUTW	(s=76)	{ TXT=[] [exScale(8.458333) eyScale(8.467624) iGraphicsMode(1), Bounds(0,0,-1,-1)] TxOPT[fOptions(0), nChars(0), offDx(76), ptlRef(131,213), rcl(0,0,-1,-1)] Spacing[84 => Total(84) =>xPtRefRight(214)]}
R0163: [084] EMR_EXTTEXTOUTW	(s=76)	{ TXT=[] [exScale(8.458333) eyScale(8.467624) iGraphicsMode(1), Bounds(0,0,-1,-1)] TxOPT[fOptions(16|ETO_GLYPH_INDEX), nChars(0), offDx(76), ptlRef(131,213), rcl(0,0,-1,-1)] Spacing[84 => Total(84) =>xPtRefRight(214)]}
R0164: [084] EMR_EXTTEXTOUTW	(s=76)	{ TXT=[] [exScale(8.458333) eyScale(8.467624) iGraphicsMode(1), Bounds(0,0,-1,-1)] TxOPT[fOptions(0), nChars(0), offDx(76), ptlRef(118,262), rcl(0,0,-1,-1)] Spacing[84 => Total(84) =>xPtRefRight(201)]}
R0165: [084] EMR_EXTTEXTOUTW	(s=76)	{ TXT=[] [exScale(8.458333) eyScale(8.467624) iGraphicsMode(1), Bounds(0,0,-1,-1)] TxOPT[fOptions(16|ETO_GLYPH_INDEX), nChars(0), offDx(76), ptlRef(118,262), rcl(0,0,-1,-1)] Spacing[37 => Total(37) =>xPtRefRight(154)]}

Argh. I do need the NewPath line there. Otherwise the clipping mechanisme doesn't work for my other part of the PDF (for my signature where the clipping needs to be on another background pdf with pdftk).

So the question remains... why does the the clipping continue after an image (as shown in Image 2)?

You can load the meta.emf in emfexplorer.exe and see what happens there.
Also... rendering it on screen works correctly.
It's just creating a PDF from it, it hides everything after the image.

I'm not sure about Delphi 11 (I'm still on 10.2) but TJvRichEdit supports images. They have Ole callback stuff which is probably needed to render the images to the metastream.

(I currently do have a small problem with images, not showing text after an image, but I'll open a new topic for that)

No, components are installed via packages in Lazarus. Same as with Delphi. Only when you click Install the whole IDE (lazarus) gets re-compiled.

Now the mormot2ui package is made as an install (design-time) package which recompiles the IDE while this shouldn't be necessary because there is no components installed. So it can just be a non-design package (same as the mormot2).

It does work as it is now but "Install" wouldn't be needed I think.
Unless components are added.

BTW. In Delphi only the path is added to the project after which everything gets compiled automatically. This could also be done the same way with Lazarus or FPC. But a package could add that path automatically which is easier. But I think the package could also just contain all the needed paths without adding all the files specifically (but somehow that doesn't work correctly now). I will look into that.

Ah, yeah, I didn't look at that. I think FPC has its own fcl-pdf package anyway.

@loadymf. In addition... you might want to try mORMot 2 which includes src/ui/mormot.ui.pdf.pas with the latest changes to the PDF engine. It might give you more luck.

Wait??? Doesn't this line read bytes BEFORE the data structure if len is 12????

movups  xmm1, dqword ptr [data + len - 16] // no read after end of page

data is the first pointer, len is 12 so data + len - 16 is going to do data - 4 ?

So using a array of less than 128 bits (16 bytes) is really dangerous with this function

(that would be any bitmap with width < 6 pixels for 24bit pixels which seems to be consistent with my experience)

~~
I tried to test with this but I can't fool it.

var
  a: array[1..1] of byte;
  hash: THash128Rec;
begin
  DefaultHasher128(@hash, @a, 12);

You think that should give an AV.

~~
There would not be an immediate need to fix this, but we should be aware of it

(or a check could be added in drawbitmap and any other place where this hash is used)

And if someone needs a quick "fix".... this works too (just using another hasher128)

  DefaultHasher128 := @crc32c128;

Ok, then there is something going on with the row.

It's a 24bit bitmap (default)

row := PERROW[B.PixelFormat];    = 24 bits = 3 bytes

w = 3    ---> that should be 3 * 3 = 9 bytes per row ???

row := (((w * row) + 31) and (not 31)) shr 3; // inlined BytesPerScanLine

row = 12

for y := 0 to h - 1 do
  DefaultHasher128(@hash, B.{%H-}ScanLine[y], row);

So the row should be 9 bytes for a 3 pixel bitmap, wouldn't it?

The row value is 12. Seems 3 bytes too much

Crashed line is in _AesNiHashXmm0 for 64 bit.
But if row (len) is indeed 12 for a 3 pixel bitmap then that seems logical that it crashes there:

        movups  xmm1, dqword ptr [data + len - 16] // no read after end of page

I don't know if the scanline is supposed to be aligned at 32 bit but seeing that access violation it seems not.
(the access violation is always on the last scanline)

Thanks for the merge.

When looking for the word "clipping" here on the forum I came across this topic from MtwStark.
https://synopse.info/forum/viewtopic.php?id=4276

It seems (s)he made a lot (and I mean A LOT) of changes to SynPDF regarding the clipping-code.

I couldn't find a pull request (or even fixes on github).

I understand that those changes were a LOT to just merge with the existing code (and it wasn't even as fix for mORMot2) and was left behind because of this.

If I have any other fixes I'll try to keep them small and clearly understandable

Ok, here is another proof that the bitmap was drawn too small.

I added a FillRectangle of 1x1 at coordinates 0,0  1,1 and 4,6.

You see clearly that in the original drawing of bitmap with 2x4 pixels (drawn at 2,2), the lower right is not connected to the FillRectangle.

So, or all the BoxI() for FillRect etc. is not correct (but they seems to be places correctly) or the code for DrawBitmap is incorrect (too small).

After some further testing I will prepare a pull request for the ExtSelectClipRgn with the addition of corrected bottom/right in DrawBitmap.
(After that, when I get the time I'll see if I can tackle the EMR_SELECTCLIPPATH, which is completely missing now).

When corrected:

Grrr. translating these coordinates is really hard.

Still not perfect.
It's also not just adding or substracting a value because the ratio/proportions are also off when using BoxI().
I can't figure out what other translation then BoxI() should be done.

The larger the image, the more deviation.

(There is also a big bug in PDF Engine when dealing with bitmaps of size 7x7 (very small). It crashes, even without the clipping stuff.)

Yes, I saw that too when tinkering with the code for drawing.
But it is GDI+ that's passing on that info.

For clipping problem I opened a new topic:
https://synopse.info/forum/viewtopic.php?id=6694

I am about to create a pull request with a fix (but still need to learn how to do that).

But even with the fix for clipping, the dashed line is too big. There is no clipping involved in the dashed line from GDI+.
You can create an EMF file and examine it with emfexplorer (and then View>EMF as Text).
There is no clipping records there.

BTW. Can you share your code to create your clipping example. I would like to throw it though the clipping fix to see if that works correctly (especially at the edges).

The code is almost identical with the old code (with the check for iMode added).

But I will test this some more (we wouldn't want a bad patch ) and create a pull request with patch (once I know how to do that )

Hmmmm, Yeah, definitely not supported.

Size of region data from GDI is 208 bytes.

      EMR_EXTSELECTCLIPRGN:
      begin
        dum1 := PEMRExtSelectClipRgn(R)^.cbRgnData;        // <---- has a block of 208 bytes
        E.ExtSelectClipRgn(@PEMRExtSelectClipRgn(R)^.RgnData[0],
          PEMRExtSelectClipRgn(R)^.iMode);
      end;

But the function ExtSelectClipRgn() doesn't seem to do much with the data parameter??

procedure TPdfEnum.ExtSelectClipRgn(data: PRgnDataHeader; iMode: DWord);
begin
  try
    with DC[nDC] do
      case iMode of
        RGN_COPY:
          begin
            ClipRgn := MetaRgn; // where is the data parameter used??
            ClipRgnNull := false;
          end;
      end;
  except
    on e: Exception do
      ; // ignore any error (continue EMF enumeration)
  end;
end;

Any ideas?

Was this meant to be functional or is it still in development?

Did this work in the past ???
Seeing this post: https://synopse.info/forum/viewtopic.ph … 071#p20071

Edit:
The code from that old topic (which was once in SynPDF) seems to be working much better. (no anti-alias but that might be fixed.)
Why was that code removed?

I did see some downsides of my hack above.
When using larger width for pen for dahses it doesn't work anymore for flat caps (probably because EMR_POLYBEZIERTO16 isn't used in that case).
I have a more 'stable' hack for you now. But you would need to have a special unique color for the dashes:

      EMR_EXTCREATEPEN: // approx. - fast solution
        with PEMRExtCreatePen(R)^ do
          if ihPen - 1 < cardinal(length(E.Obj)) then
            with E.obj[ihPen - 1] do
            begin
              kind := OBJ_PEN;
              PenColor := elp.elpColor;
              PenWidth := elp.elpWidth;
              PenStyle := elp.elpPenStyle and (PS_STYLE_MASK or PS_ENDCAP_MASK);

              // this doesn't work because we don't have dashes
              // if pen.style and PS_STYLE_MASK = PS_DASH then PenWidth := 0;

              if elp.elpColor = 0 { r } + 255 { g } shl 8 + 0 { b } shl 16 then PenWidth := 0; // your color for dashes

            end;

This will only set the pen width to 0 for when that color is used.
It seems a lot more stable (but is still an ugly hack).
It will also work for flat caps

(If anyone else has any other ideas about how to detect if we are in dashed lines ?)

Result:
(You'll notice the blue line creeps to the left but that's because of the round caps, and is according to specification, using the round cap before start of line).

BTW. This is the original where you see the problem of GDI+ clearly.

And this was with flat caps:

You also notice the corners are slightly different from the EMF version
So that does seem to be a minor 'bug' in synpdf but when using pen=0 those corners are cut anyway.
But maybe that's the reason the 'bug' is there in GDI+ to provide those corners for flat caps