mORMot Open Source

I think actually that the Enhanced Mata Canvas for sympdf is already EMF+.

Ths is from Winapi.GDIPOBJ in Delphi:

// The following methods are for playing an EMF+ to a graphics
// via the enumeration interface.  Each record of the EMF+ is
// sent to the callback (along with the callbackData).  Then
// the callback can invoke the Metafile::PlayRecord method
// to play the particular record.
function EnumerateMetafile(metafile: TGPMetafile; const destPoint: TGPPointF;
  callback: EnumerateMetafileProc; callbackData: Pointer = nil;
  imageAttributes: TGPImageAttributes = nil): TStatus; overload;

And mormot.ui.pdf.pas receives that in:

/// EMF enumeration callback function, called from GDI
// - draw most content on PDF canvas (do not render 100% GDI content yet)
function EnumEMFFunc(DC: HDC; var Table: THandleTable; R: PEnhMetaRecord;
  NumObjects: DWord; E: TPdfEnum): LongBool; stdcall;

I think the problem is that GDI+ thinks it has to do with a device which can't interpret postscript.

There is an option with POSTSCRIPT_IDENTIFY to set PSIDENT_GDICENTRIC or PSIDENT_PSCENTRIC for GDI centric or Postscript centric but that's for the device driver I think. (I don't even know if that would help)

I don't know how to influence GDI+ into thinking we have the dash-line capability (so it sends DASH instead of those ellipses).

Yes, but when GDI+ is going to pass on the records it stored, it does so via the EnumerateMetafile which is EMF+.
Synpdf itself works with Enhanced Meta Canvas with EMF+ structures doesn't it?

GDI+ does have the dash stored as real dash-structure (like passed to it). It gives it correctly to the printer driver (via the canvas) on Draw() command.
But for the TEnhancedMetaCanvas this is translated to ellipsed (which contain a bug that it draws the line length which is too big).

I whish I knew how the printerdriver did this. It also receives the GDI+ records on Draw() but seems to translate them much more efficient (postscript dash codes instead of ellipses).

BTW If I don't use Print To PDF from Microsoft but my own PDF writer (based on Ghostscript driver) I get a better result.

Now the COMPLETE PDF looks like this (only relevant print part).
This is including the solid line AND the dashed line.

%%Page: 1 1
%%BeginPageSetup
%%PageOrientation: Portrait
pdfStartPage
0 0 612 792 re W
%%EndPageSetup
[] 0 d
1 i
0 j
0 J
10 M
1 w
/DeviceGray {} cs
[0] sc
/DeviceGray {} CS
[0] SC
false op
false OP
{} settransfer
0 0 612 792 re
W
q
q
[0.12 0 0 0.12 0 0] cm
6 w
1 J
/DeviceRGB {} CS
[0 0 1] SC
180 3600 m
240 6360 l
1800 6300 l
S
[24 30] 0 d
/DeviceRGB {} CS
[0 1 0] SC
300 3600 m
360 6240 l
1800 6180 l
S
Q
Q
showpage
%%PageTrailer
pdfEndPage
%%Trailer
end

This is how it should be.
The [24 30] 0 d is the actual dashed line setup for pdf (as you could see in TPdfCanvas.SetDash()).
And the corresponding x l #10 after that prints the dashed line.

But I have no idea how to setup GDI+ to do exactly the same for synpdf.

I think it has to do with the fact synpdf uses a EMR/enhanced meta canvas and gdi will pass the drawing different from passing it to the printerdriver via canvas. But I'm not sure (as I said, I'm no expert).

Well, you should care if you want to fix this.

I'm not sure why GDI+ is drawing the dashes as ellipses but it's definitely doing that at a higher resolution.

1) You could draw this to another drawable canvas and after that copy that canvas to VCLCanvas and see if that helps (probably with loosing some resolution).

2) Second option is to find out why GDI+ is drawing ellipses and seeing if you can alter that behavior (maybe with setting the stroke color to transparent?).

3) Third option is to hack mormot.ui.pdf and adjust the line width when there is a dashed line. But I looked at the TPdfEnum.NeedPen and when it's called, it's not called with any dash style because GDI+ takes the drawing of dash completely for itself. So it's difficult to know if there is a dash being drawn. You could put a global boolean switch and hack the TPdfEnum.NeedPen, to pass 0.1 if that boolean is set (and set the boolean yourself when you want to draw a dash).

But you'll see it's not something the mormot.ui.pdf itself can do because from mormot's point of view, there is no dashed line being drawn, but multiple smaller ellipses, by GDI+.

No, actually it's something in GDI.

I had another quick look at the decompressed PDF it seems that there isn't really ONE dashed line (in terms of PDF line).

The line code looks like this and is correct:

/DeviceRGB {} CS
[0 0 1] SC
[] 0 d
1 J
0.75 w
22.5 467 m
30 812 l
225 804.5 l
S

And the dashed line looks like this with many repeats:

/DeviceRGB {} CS
[0 1 0] SC
[] 0 d
0 J
0.75 w
0.75 w
0.75 w
0.75 w
0.75 w
<many times>
/DeviceRGB {} cs
[0 1 0] sc
37.31 473.75 m
37.36 476.75 l
37.36 476.94 37.55 477.13 37.73 477.08 c
37.97 477.08 38.11 476.94 38.11 476.7 c
38.06 473.7 l
38.06 473.52 37.88 473.33 37.69 473.33 c
37.45 473.38 37.31 473.52 37.31 473.75 c
h
37.45 480.5 m
37.5 483.5 l
37.55 483.69 37.69 483.88 37.92 483.83 c
38.11 483.83 38.3 483.69 38.25 483.45 c
38.2 480.45 l
38.2 480.27 38.02 480.08 37.83 480.08 c
37.59 480.13 37.45 480.27 37.45 480.5 c
h
<last part repeated many times>

So it seems that GDI itself translate the dashed line itself to many multiple fragments (and calls to LineTo).

Above that code are many 0.75 w parts. (which stands for line width.

The kicker now.... I changed all the 0.75 w parts into 0.175 w to make the lines thinner.
The result is this:

Here you see clearly that it is GDI that is drawing the line.

When that is drawn on a canvas with 1 pixel resolution, you get the screen and printer result.
But when it is drawn to a canvas with much higher resolution, it's going to draw those circel thingies.

PS. I extracted the pdf with pdf2ps (from xpdf-tools) and looked at the resulting .ps file.
You can read the ps file afterwards with a postscript interpreter or with gimp (and setting a resolution of 1200 during import).

I know you can hack the pdf writer to write smaller lines (like I showed you earlier).
But it's definitely GDI that's drawing the dashed line itself.

Hi, a non-expert here...

For the actual setting of the pen and dash you can look in mormot.ui.pdf.pas at the procedure TPdfEnum.NeedPen.

But this only gets called when you actually save the file to pdf, not before (so the translation from gdi to pdf).

When putting a breakpoint there and watch for DC[nDC].pen.width you see that for both lines the value is 16 (in your example program).

Increasing the width to 100 in second breakpoint-loop seems to increase the width of the dashed line.
But lowering it under 16 to 8 for example doesn't seem to be possible.
Minimum width dashed line seems to be that value.

This is the result of setting the DC[nDC].pen.width to 1 for both lines.

And this for setting it to 100 for both lines.

Can you show your code or snippet?
For me it works fine with the latest source of mormot.ui.pdf.

PDF.VCLCanvas.Pen.Width := 1;
PDF.VCLCanvas.Pen.Style := psDash;
PDF.VCLCanvas.MoveTo(100, 600);
PDF.VCLCanvas.LineTo(300, 600);
PDF.VCLCanvas.Pen.Width := 4;
PDF.VCLCanvas.MoveTo(300, 600);
PDF.VCLCanvas.LineTo(600, 600);

I don't think that's (directly) possible with TPdfDocumentGDI.
You would think that it should work with TPdfDocumentGDI.RawPages but in TPdfDocumentGDI.AddPage there is this line at the top:

if (FCanvas<>nil) and (FCanvas.FPage<>nil) then
  TPdfPageGdi(FCanvas.FPage).FlushVCLCanvas;

That line flushes and frees TPdfPage.fVCLCurrentCanvas of the previous page.
That's the pdf.VCLCanvas you want to use for the page.
When going back to page one with TPdfDocumentGDI.RawPages the needed TPdfPage.VCLCanvas is already freed and destroyed so when accessing it again, it will be created again, new but empty.
That's why the page is overwritten.

You could try to comment out the above line. Then you get the result you want.
The TPdfPage.fVCLCurrentCanvas is kept after TPdfDocumentGDI.AddPage.
The TPdfPage.VCLCanvas is flushed in that case at TPdfDocumentGDI.SaveToStream() and not at AddPage.

But I'm not sure if there are any problems with it down the road.

Yes, I can confirm the UseUniscribe := true works in this case.
The UseFontFallBack were not needed for me (and seeing that the PDF already contains Arial I think they don't do much).

I don't now why UseUniscribe is needed when a fairly simple Arial font is used (I'm not that familiar with the inner workings of SynPDF).

But maybe it has something to do with the way everything is rendered into the WMF and after that the font-info becomes complex in which case there is a need for UseUniscribe (just guessing here).

BTW The reason some lines work fine and others not is in the fact that the space between words is wrong. And text which is combined is stretched. But text snippets that were placed on a certain position is fine.
The amount (Betrag) on the productline is on a specific position (so that works fine).
The amount  for subtotal and MWST probably have multiple spaces in front of them and that's because they are shifted too much to the right (the multiple spaces are all expanded).

(hey, and that's where that format('%11.2n) and format('%7.2n) comes in. The 11.2 has more spaces and each space is expanded to multiple spaces. 7.2 has less space and that's why that one seemed to fix some of the issues )

Maybe @ab can elaborate on the reason for the need for UseUniscribe.

We still haven't seen what exactly the problem is. Alignment problems? Or something else? "Doesn't render properly" isn't really a clear description.

That would suggest some alignment problems. If you use spaces you would need to use (right aligned or decimal aligned) tabs to always correctly align numbers.

These also don't align in text:
    145.12
133241.12
(and the first has 4 spaces, so is 7.2, second has 1 space so is also 7.2)

But I'm not sure why this would be correct in a WMF format (IF that's the actual problem of course).
Maybe it has to do with font substitution (in WMF one font and when rendered to PDF another font is chosen).

In that case it might be useful (especially for the developer) to have the sample meta.wmf to check where this goes wrong.

(It then can be loaded with aMeta.LoadFromFile('C:\temp\WMF\meta.wmf); and debugged properly.)

And what did you mean by "The expected PDF-items are added to the file, but after the pages."?

If I use vpHideToolbar and vpHideMenubar in ViewerPreference they seem to work fine.
Even setting Landscape to true works.
Even for vpFitWindow it seems to be set at the top of the pdf.

It's only because my pagelayout is set at SinglePage I don't think FitWindow is actually used/works.
The SinglePage is standard set as default. (FRoot.PageLayout := plSinglePage in TPdfDocument.NewDoc).

If you force it to plOneColumn you might get the result you want?

    PDF.Root.PageLayout := plOneColumn;
    PDF.Root.ViewerPreference := [vpFitWindow];

I'm not sure why for you the PageLayout and ViewerPreferences would be at the end of the pdf (if it is there).

Glad it works now

You have SQLite3Pages in there.
I don't have that. I use mORMotReport.pas.

I'm not sure where that SQLite3Pages comes from and how different it is from mORMotReport.pas.

I see you can get it from here https://synopse.info/forum/viewtopic.php?id=41
Still not sure how it is different.
Maybe that's the problem.

Edit: That one doesn't have the AppenRichEdit.

Where did you get the SQLite3Pages??
It has a date of 2010 !! Really OLD.

Where is your TGDIPages defined?
I'm not seeing an uses for mORMotReport in your code??

Did you read my previous post?

I can confirm the crash with your selected code (found on the forum here).
I got that too.

But try the exact code I gave (with an empty project).

Yes, I just created an empty project with one TButton and TRichEdit and dropped this code in the Button1.OnClick.

What bitness and platform are you compiling for? 32 bit or 64 bit (I tried 32 bit VCL).

(Just tried 64 bit VCL too and that also works for me, so I don't know what's wrong on your end. Maybe someone else knows more about it.)

Can you show an example (preferable with example rtf)?

If I use this code (with a sizable rtf, see attached) it works fine for me.

Simple project with just a button and a TRichEdit on form.

procedure TForm1.Button1Click(Sender: TObject);
begin
  RichEdit1.Lines.LoadFromFile(GetEnvironmentVariable('USERPROFILE') + '\Downloads\sample.rtf');

  with TGDIPages.Create(self) do
    try
      Caption := self.Caption;
      BeginDoc;
      AddTextToHeader(paramstr(0));
      SaveLayout;
      Font.Style := [fsItalic];
      TextAlign := taRight;
      AddTextToFooterAt('http://synopse.info', RightMarginPos);
      RestoreSavedLayout;
      AddTextToFooter(DateTimeToStr(Now));
      NewHalfLine;

      DrawTitle('Rich Edit Content', true);
      AppendRichEdit(RichEdit1.Handle);
      DrawTitle('Last page content', true);

      EndDoc;
      ExportPDF(ChangeFileExt(paramstr(0),'.pdf'),true,false);
      ShowPreviewForm;
    finally
        Free;
    end;
end;

Rtf download here: https://jeroen.github.io/files/sample.rtf

I can confirm the C# code is correct (or at least I can decrypt it in FPC/DCPcrypt2).

uses DCPrijndael, DCPcrypt2, base64;

function myDecryptCBC: ansistring;
var
  Cipher: TDCP_rijndael;
  Data, DataString, Key, IV: ansistring;
begin
  Data := DecodeStringBase64('WKaCNKYZpF9tb/CLp8fW/mX4r95OfjztavXhycsgDpA=');
  Key := DecodeStringBase64('TW4YnFfPEhLeehtwdEAZyJYg/zYxeeaDjlhKIifwGKI=');
  Assert(Length(Key) = 32);
  IV := Copy(Data, 1, 16);
  DataString := Copy(Data, 17);
  Cipher := TDCP_rijndael.Create(nil);
  Cipher.CipherMode := cmCBC;
  Cipher.Init(Key[1], Length(Key) * 8, @IV[1]);
  Cipher.DecryptCBC(DataString[1], DataString[1], Length(DataString));
  // PKCS7, last char is #11 which results in 16 - 11 = 5, length of Hallo
  DataString := Copy(DataString, 1, Length(DataString) - Ord(DataString[Length(DataString)]));
  Result := DataString;
  Cipher.Free;
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  S: ansistring;
begin
  S := myDecryptCBC;
  Memo1.Lines.Add(S);
end;

Gives result

I'm not sure why TAESCBC gives another result.

Could be useful to show the C# code too of how you encrypted this.

How did you pad the key in C#, with spaces? With #0? etc

The problem is that during decryption the last byte (which should contain the padding) is larger than the sizeof(TAESBlock).

Key should also be exactly 32 bytes (or padding to that number should be the same on both ends).

FYI (and reminder). Changes of mormot.ui.pdf.pas from Revision 3316 haven't made it to SynPDF trunk yet.

(It still uses fFontDescriptor.ValueByName('BaseFont') instead of Data.ValueByName('BaseFont'))

Also, the subsetting of CID embedded fonts are also not prefixed (see post above).

Not a problems for me, but I thought I mention it before the changes grow further apart
(if this is something that usually takes more time you can forget this reminder)

Have a nice holiday 

Yes. The ReduceTTF does a good job as far as I can see for now
Thanks.

I think there was still a small error in you previous change.
You had this:

// see 5.5.3 Font Subsets: begins with a tag followed by a +
TPdfName(fFontDescriptor.ValueByName('FontName')).AppendPrefix;
TPdfName(fFontDescriptor.ValueByName('BaseFont')).AppendPrefix; // <---- this line

But I think BaseFont isn't part of fFontDescriptor but of Data.
So it should be

TPdfName(Data.ValueByName('BaseFont')).AppendPrefix;

Otherwise BaseFont isn't found and isn't changed with prefix. And BOTH FontName AND BaseFont need to be prefixed.

(Adobe reader does show it as Subset when only FontName is prefixed but pdffonts.exe does not show it as subset.)

This was the result if BaseFont is not prefixed.

S:\pdfs\xpdf-tools-win-4.02\bin32>pdffonts -loc c:\temp\test2.pdf
name                                           type              emb sub uni prob object ID location
---------------------------------------------- ----------------- --- --- --- ---- --------- --------
Tahoma                                         TrueType          no  no  no            6  0 external: C:\WINDOWS\Fonts\tahoma.ttf
Code3de9                                       TrueType          yes no  no            8  0 embedded
Code128                                        TrueType          yes no  no           10  0 embedded
KIXBarcode                                     TrueType          yes no  no           12  0 embedded
SegoeScript                                    TrueType          yes no  no           14  0 embedded

When I change the line to

TPdfName(Data.ValueByName('BaseFont')).AppendPrefix;

I get

S:\pdfs\xpdf-tools-win-4.02\bin32>pdffonts -loc c:\temp\test2.pdf
name                                           type              emb sub uni prob object ID location
---------------------------------------------- ----------------- --- --- --- ---- --------- --------
Tahoma                                         TrueType          no  no  no            6  0 external: C:\WINDOWS\Fonts\tahoma.ttf
NFHHHJ+Code3de9                                TrueType          yes yes no            8  0 embedded
DABIJH+Code128                                 TrueType          yes yes no           10  0 embedded
ANHKBL+KIXBarcode                              TrueType          yes yes no           12  0 embedded
DCMDKN+SegoeScript                             TrueType          yes yes no           14  0 embedded

And that one seems to be correct.

BTW. Nice idea to use random32 and just snip 4 bits off each time for the random 6 letters

(With svn update your changes did get merged nicely locally with my already changed fEmbeddedSubsetCleanup changes. Never tried that before )

It does not seem to give a real error . I tried is with just 'ABCDEF+' for every font/subset and that worked too.

But the documentation states:

Or do you think they mean with different subsets, multiple subsets from the same font? That wouldn't really make much sense.

I need to find some tool online which check the validity of the PDF to make sure (but all the generators I've seen use really random characters for all subsets).

Edit: The original PDF from SynPDF (so all PDF's) give an error for this online validator https://www.datalogics.com/products/pdf … f-checker/ (Ghostscript ones are fine)

Edit #2: Ah. 1.3 files are fine.

Edit #3: This way you could also potentially have trouble if merging multiple SynPdf files with the same font but different subsets, I think