mORMot Open Source

That's weird. If I look in the WMF with EMFexplorer I do get some font info, but maybe not for all objects:

Multiple lines with
EMR_EXTCREATEFONTINDIRECTW    (s=368)    {ihFont(2) ELF[name() style() vendor(0x072DDF38)] LOG[face(Arial), style(Bold), charset(0),family(0),precision(0), height(-100), width(0)]}

But it's also weird that some text is correct. For me... every WMF/EMF renderer I used (emfexplorer, gimp, paint and irfanview) do give somewhat correct result (although some give different font results). So they do fall back to a "correct" font as where SynPDF falls back to NO font (giving overlapping characters).

No, it's just Arial in the WMF.
When I trace through the code I get in TPdfCanvas.SetPdfFont where is skips the code because of the "// check if this font is already the current font".

But when I look in the actual PDF you get to the point for P.O.No. where there is no "/F1 9.95 Tf" set.
And I can't see that there is any "default" font set for the (or a) PDF.

Q
q
BT
39.67 676.56 Td
(P. O. No:) Tj
ET
Q
q

while above it is this for CUSTOMER

q
/F2 9.95 Tf
BT
39.67 694.54 Td
(CUSTOMER:) Tj
ET
Q
q

All the text which is printed overlapped seem to be missing the font setting. It may be due to some recursive problem where SynPDF thinks there is a current font set while there is not... But since I don't know if the OP has the same issue (in the older SynPDF) I'm not sure if it's worth investigating.

(BTW Rendering this though RenderMetaFile() it actually produces a corrupt PDF. Doing this with Draw(), which used some of the same code, gives above result. So there is also something wrong when doing it through RenderMetaFile)

Links are correct now (I guess it was the extra slash at the end).

The GDI+ implementation of SynPDF is far from perfect. It probably lacks some features used which results in a 'corrupt' PDF.

I did notice you used SynPDF. I don't have that installed anymore and the old SynPDF isn't updated anymore. For a more recent version you would need to use mormot.ui.pdf in mORMot2.

With that one I got a 'corrupt' pdf trying to do RenderMetaFile(pdf.Canvas, aMeta, 0.58, 1.30, 0, 0);

When I did pdf.VCLCanvas.Draw(0, 0, aMeta); I did get all the images. But the text wasn't exactly correct.

But I can't speak for the older SynPDF.

You might want to provide an example for this. Without it, it would be hard to diagnose the problem.
(You can provide larger parts of code via github gist)

In Sumatra reader you can press CTRL+D for properties (or use the menu) and then use "Get Fonts Info". There you can see which fonts are used and which are embedded.

It's advisable to always embed the fonts (at least a subset of the fonts) that are not default on all systems.
Calibri is widely used but there are some systems that don't have them.

(Maybe not a problem for you at the moment, if you know what fonts are on the systems, but you should keep it in mind )

Glad to hear it was just a glitch in the system and all it took was a restart.

Did you embed the used fonts?
(See ctrl+d in Adobe and then fonts tab)

Note for @ab
I did a bit of digging and found that in TPdfWrite.AddGlyphs the TPdfFontTrueType.GetAndMarkGlyphAsUsed is called.
For the unicode character U+FB05 ſt this function returns 0 because it can't find that character in fUsedWide.

Why doesn't it add the (unicode) character to the Glyph map when not found?

There is a FindOrAddUsedWideChar in there but that's only used when the Glyph is found in fUsedWide (in which case the add seems a little pointless).

@sameerpandit Sorry. I can't help if I can't reproduce it.
And without code and used wmf, I can't reproduce it.

Pointing to some half ready code and no wmf doesn't help with that.

Maybe @ab can be more helpful (but my guess is not without actual being able to reproduce it too).

Yeah... 'Bookmarks' is really confusing in PDF/Adobe. Although it's called Bookmarks in the sidebar, they are actually Outlines. It's also called outlines in the PDF specs, so looking for Bookmarks will only confuse you

If you do TPdfDocument.CreateOutline() you can create 'Bookmarks' in the PDF (also had to dive into the sourcecode to find that out ).

function TPdfDocument.CreateOutline(const Title: string; Level: integer; TopPosition: single): TPdfOutlineEntry;

You can create several levels. 0 is the root and 1 etc are levels under it.

For example:

// pdf.addpage etc
pdf.CreateOutline('Test-page-1- root', 0, 1);
pdf.CreateOutline('Sub bookmark', 1, 20{?});
// pdf.addpage etc
pdf.CreateOutline('Test-page-2-root', 0, 1);

BTW. You do need to use AUseOutlines to true when creating TPdfDocumentGDI, otherwise outline doesn't work.

pdf := TPdfDocumentGDI.Create(true); // <- AUseOutlines = true

Do you mean the bookmarks at the right of the PDF?
Have you tried using CreateBookMark yet?

If you search on this forum there are several examples of CreateBookMark (just calling it after page creation).

I adjusted the test project a bit to include creating a pdf directly after generating the PDF (with correct dimensions).
Also included a SetWindowOrgEx() line. That indeed shows my previous changes work correctly for offset window but I'm still unsure if it needs adjusting at other places.

I also noticed that the test for RGN_AND, RGN_DIFF, RGN_OR and RGN_XOR also worked correctly in PDF.
But that's because it doesn't test for those modes in EMR_EXTSELECTCLIPRGN but only in CombineRgn.

And using CombineRgn() doesn't actually put that mode RGN_AND etc in the metafile !!!
(it just buffers it and exports the final EMR_EXTSELECTCLIPRGN with RGN_COPY (which is done in the ExtSelectClipRgn() line.)

(edit: sorry for posting the code... moved to gist...)

For adjusted testproject:
https://gist.github.com/rvk01/60453f5bd … 8d75bba8fa

I think CreateEnhMetaFile takes .01-millimeter unit as size, not pixels.
https://learn.microsoft.com/en-us/windo … hmetafilea

300*0.01 = 3mm which is 11 pixels at 96 dpi.
(according to https://pixelcalculator.com/en)

You can also see here that it needs mm measurements.
https://github.com/synopse/mORMot/blob/ … taFile.pas

In follow up on the other topic... I found a directory here with lots of EMF files to test.
https://github.com/kakwa/libemf2svg/tre … ources/emf

When putting this in the bugreport directory from the other topic... and changing the following.
It will create all the pdf files in that emf directory.
There are lots of pdf that end up corrupt.

And others have strange result. 000 and 015 doesn't have the axes. and 040 also has lots of things wrong.
It indeed shows the need for automated test

BTW. comparing images extracted from pdf from a testrun with baseline images would be very hard I imagine. They would never be pixel perfect.
And before that... you would first need to fix all the problems that already exist with the above emf's before using these for regression testing

uses
  mormot.ui.pdf, ShellApi, System.IOUtils, System.Types;

procedure TForm1.Button1Click(Sender: TObject);

  procedure ProcessAllFilesInDirectory(const Directory: string);
  var
    Files: TStringDynArray;
    FileName: string;
  begin
    if not TDirectory.Exists(Directory) then exit;
    Files := TDirectory.GetFiles(Directory, '*.emf', TSearchOption.soAllDirectories);
    for FileName in Files do
    begin
      Self.DoConvertMetafileToPdf(Filename, ChangeFileExt(Filename, '.pdf'));
    end;
  end;

begin
  ProcessAllFilesInDirectory(ExtractFilePath(Application.ExeName) + 'emf');
  //Self.DoConvertMetafileToPdf(ExtractFilePath(Application.ExeName) + 'bogus.wmf', ExtractFilePath(Application.ExeName) + 'bogus.pdf');
end;

test-040.pdf

test-015.pdf

I now have this.
But I wonder if now the inc for r.bottom and r.right are still needed. Need to check this.

      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);

But that's the really strange part.

It says:

But... the current code DOES factor in fWinOrg.
But I think this is wrong.

If you look at my last changes

      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);

You see it doesn't use fWinOrg at all.
It just uses the coordinates without translating it with WinOrg at all.

Weird...

This will draw the rectangle correctly:

      RCT.Left := RCT.Left + round(Canvas.fWinOrg.X * Canvas.fViewSize.cx / Canvas.fWinSize.cx);
      RCT.Right := RCT.Right + round(Canvas.fWinOrg.X * Canvas.fViewSize.cx / Canvas.fWinSize.cx);
      RCT.Top := RCT.Top + round(Canvas.fWinOrg.Y * Canvas.fViewSize.cy / Canvas.fWinSize.cy);
      RCT.Bottom := RCT.Bottom + round(Canvas.fWinOrg.Y * Canvas.fViewSize.cy / Canvas.fWinSize.cy);
      ClipRect := Canvas.BoxI(RCT, false);

That corrects the I2X/I2Y to not use fWinOrg.X/Y.

But the comment from the other source is:

Which seems to suggest it does need to be relative to fWinOrg but not to fWorldOffsetX.

(But in the WMF the WinOrg.X/Y is -100/-100. I'll need to readup on this as to what it actually should be.)

The interpretation of the EMR_EXTSELECTCLIPRGN inside the WMF indeed seems to cut away the wrong part in the PDF.

R0109: [034] EMR_RESTOREDC    (s=12)    {iRelative(-1)}
R0110: [030] EMR_INTERSECTCLIPRECT    (s=24)    {rclClip(16,82,776,113)}
R0111: [037] EMR_SELECTOBJECT    (s=12)    {Stock object: 13=OBJ_FONT}
R0112: [040] EMR_DELETEOBJECT    (s=12)    {ihObject(6)}
R0113: [037] EMR_SELECTOBJECT    (s=12)    {Table object: 4=OBJ_FONT}
R0114: [024] EMR_SETTEXTCOLOR    (s=12)    {0x00000000}
R0115: [022] EMR_SETTEXTALIGN    (s=12)    {iMode(24= TA_BASELINE)}
R0116: [075] EMR_EXTSELECTCLIPRGN    (s=64)    {iMode(5=RGN_COPY), RGNDATA[ptr:0x071d0cb8, size:48, box(110,176,882,314)]}
R0117: [022] EMR_SETTEXTALIGN    (s=12)    {iMode(24= TA_BASELINE)}
R0118: [022] EMR_SETTEXTALIGN    (s=12)    {iMode(24= TA_BASELINE)}
R0119: [022] EMR_SETTEXTALIGN    (s=12)    {iMode(24= TA_BASELINE)}

This could be fixed by reverting back to just removing the complete TPdfEnum.ExtSelectClipRgn() to do nothing (putting an exit above fixes it).
But that's not a real solution of course.
Better would be to find out why the values (110,176,882,314) are interpreted wrong.

I'll try to see how this is done with the other (more developed solutions) for GDI rendering.

In your current code you can put a line like this:

meta.SaveToFile(format('c:\temp\meta-%d.emf', [i + 1])); // this saves the meta to c:\temp
// draw the page content
RenderMetaFile(Pdf.Canvas, aMeta,1,1,0,0); // <-- this is the old line

After that you can test with:

procedure TestMetaToPdf;
var
  Pdf: TPdfDocument;
  aMeta: TMetaFile;
begin
  Pdf := TPdfDocument.Create;
  try
    Pdf.Info.CreationDate  := Now;
    Pdf.Info.Creator := 'meme';
    Pdf.DefaultPaperSize := psA4;
    Pdf.AddPage;
    aMeta := TMetaFile.Create;
    try
      aMeta.LoadFromFile('c:\temp\meta-1.emf');
      // draw the page content
      RenderMetaFile(Pdf.Canvas, aMeta,1,1,0,0);
    finally
      aMeta.Free;
    end;

    try
      Pdf.SaveToFile('c:\temp\test9.pdf');
    finally
      // Send to ...
    end;

  finally
    Pdf.free;
  end;
end;

No, there is no TPDFCanvas.RenderMetaFile.
But you should use procedure RenderMetaFile() for that.
It's in mormot.ui.pdf so you can just call it.

You pass your Pdf.Canvas as first parameter. Rest is the same.

procedure RenderMetaFile(C: TPdfCanvas; MF: TMetaFile; ScaleX: single = 1.0;
  ScaleY: single = 0.0; XOff: single = 0.0; YOff: single = 0.0;
  TextPositioning: TPdfCanvasRenderMetaFileTextPositioning = tpSetTextJustification;
  KerningHScaleBottom: single = 99.0; KerningHScaleTop: single = 101.0;
  TextClipping: TPdfCanvasRenderMetaFileTextClipping = tcAlwaysClip);

Yes, probably. But I rather have a lot of q/Q than clipping in the wrong place where text (and in my case even an amount/currency column) is clipped

That being said... shouldn't EMR_RESTOREDC always do a restore Q in PDF? It's not for nothing EMR_RESTOREDC is in the EMF.

The q/Q are for pushing/restoring the graphical state. But Line Width/Brush etc. are also part of the graphical state (PDF1.7 4.3.1).
So when SAVEDC/RESTOREDC is called in EMF, it's only logical to (ALWAYS) do the same in PDF, regardless if it's needed (because you can't possibly determine the actual need to do so without evaluating everything that comes before it).

GDI

PDF

I think with the adjustments of MtwStark, it will also always save/restore on SaveDC/RestoreDC. But those where developing adjustments.

In llPDFEMF.pas it seems to set a Clipping := true on EMR_EXTSELECTCLIPRGN and only does FCanvas.GStateRestore in RestoreDC when that Clipping is set.
It seems clipping is a lot more 'mature' in that code. But that was already known.

It looks like most calls to GStateRestore are done when Clipping is true (so not only within text processing).

But as stated before... in EMF... even a simple SAVEDC, set Line Width to 100, do nothing else and RESTOREDC, should restore the line width.
I don't think that's being done now when translating this to PDF.

So I don't think lot's of q/Q is polluting the PDF... it's just following the EMF.
You could check the complete graphical stack (not only clipping, but also bitmap, brush, palette, font, pen, region, drawing mode, and mapping mode) and see if that's changed. If it's not changed, you could omit the q/Q. But that seems like a lot of work. Besides IsClipping you would need IsLineWidthSet, IsBrushSet, IfFontSet etc. etc. Just doing a q/Q would be much simpler (and it follows the EMF).

(If I got some time I'll check some other EMF->PDF converters. Until then I'll test the stability of adding the q/Q)

Clipping works perfectly in synpdf with an image in TJvRichedit.
I use the TPdfDocumentGDI and it enumerates perfectly through the EMR_STRETCHDIBITS for the image.

After that the richedit/Windows does the clipping for transparency through EMR_EXTSELECTCLIPRGN. That also works perfectly for my hand signature as image in the richedit.

It's just that any text after it is also clipped.
Or seems like the TPdfEnum.ExtSelectClipRgn leaves the clipping in a wrong state.

But I'll investigate this further. I have a feeling it's just a minor bug which can be fixed really easy but I was hoping you would have some more expertise as to how that newpath worked and would spot the bug more easily. But I'll get into it and report back when I find something.

After my last pull request the clipping works very good, at least for the RGN_COPY part. It just that the clipping seems to be left in a wrong state (on?).

Works fine for me (with latest mORMot 2 sources).

What version of code are you using?
(otherwise a small sample would be helpful)

This works for me (generates a 1.5 PDF):

procedure MakePdfSynPdf;
var
  FileTemp: string;
  pdf: TPdfDocumentGDI;
begin
  FileTemp := 'C:\Temp\Test1.pdf';
  pdf := TPdfDocumentGDI.Create;
  try
    pdf.UseOptionalContent := true;
    pdf.Info.Title := 'Title name';
    pdf.Info.Author := 'User name';
    pdf.Info.Creator := 'Software name';
    pdf.Info.subject := 'Auto generated document';

    // page 1
    { page := } pdf.AddPage;
    pdf.VCLCanvas.Font.Name := 'Times New Roman';
    pdf.VCLCanvas.Font.size := 24;
    pdf.VCLCanvas.TextOut(100, 100, 'some text on page 1');

    // page 2
    { page := } pdf.AddPage;
    pdf.VCLCanvas.Font.Name := 'Times New Roman';
    pdf.VCLCanvas.Font.size := 24;
    pdf.VCLCanvas.TextOut(100, 100, 'some text on page 2');

    // back to page 1
    pdf.Canvas.SetPage(pdf.RawPages[0]);
    pdf.VCLCanvas.Font.Name := 'Times New Roman';
    pdf.VCLCanvas.Font.size := 24;
    pdf.VCLCanvas.TextOut(200, 200, 'some extra text on page 1');

    pdf.SaveToFile(FileTemp);

    ExecAssociatedApp(FileTemp);

  finally
      pdf.Free;
  end;

end;

You probably just want the complete mORMot 2 package. Compiling just the mormot.ui.pdf.pas will pull in everything else anyway.

Compiling mORMot 2 on Lazarus/FPC trunk (from 2 months ago) works fine.

I only had to include mormot.ui.pdf.pas and mormot.lib.uniscribe as files in my console project because they are not in the mormot2ui.lpk.
(mormot.ui.report.pas is missing there too)

I did get this message during install of mormot2ui.lpk.

It probably doesn't add the path to the include path.
The path is in the package but somehow it doesn't get included automatically to the project when adding mormot2ui as requirement.

Manually setting "mORMot2\src\ui;mORMot2\src\lib" as "Other unit files" in projects options works too.

After that, creating a PDF with TPdfDocumentGDI isn't a problem.

Can't speak about the rest of mORMot 2

But overall, using mormot.ui.pdf shouldn't be too hard on Lazarus (Windows, I didn't test Linux).

BTW. mormot2ui should install designtime components, shouldn't it?
I don't think it does. It does have the "Install" button but I don't think it really installs anything.
(or I'm just looking in the wrong place)

Edit: Ah, this probably answers it

// do-nothing-unit on non Delphi + Windows system
// = not yet compatible with FPC/LCL due to a lot of Windowsims and VCLisms :(
procedure Register;
begin
end;

With the latest version of mormot2.ui.pdf your code works fine for me (in Delphi 10.2 and 32 bit app) and results in a pdf of 25MB with 70.000 pages.
So you might want to use the latest version (the mormot2 one, not the synpdf one).