incorrectly placed and scaled meta files

Wolsink · 2012-03-20 21:28:27

From a Richedit decendant I did try to convert meta file pictures (vector format) to PDF format with the aid of 'ExportPDF(FileName,true,true);'
This works only partly.
Peculiar is that the border lines of the picture are depicted as intended, but the rest of the meta file picture is moved to the top-left side of the page. With the dimensions of almost a postage stamp. Incorrect placed and scaled therefore.

The meta file picture is drawn by the program onto a TImage component, thereafter the program does copy-paste the meta file into the decendant of the Richedit component.
Copy-paste the meta file by hand from the Richedit component into for instance Microsoft Word works fine.
The border lines are made with the use of the GDI Rectangle function; this is converted into PDF format as intended.
The rest of the figure is made with the aid of 'MoveTo', 'LineTO' functions and 'TextOut' functions; they seem to have to been shifted and scaled out of focus by the conversion to the PDF format

I hope this description does help.

Gerrit Wolsink

ab · 2012-03-21 07:40:07

When printing using a TRichEdit component, all printing is done from the Windows API.
TRichEdit implementation is pretty rough, when it comes to sophisticated rendering (like pictures).

How do you print the TRichEdit component? Using TGDIPages.AppendRichEdit?
Does printing preview work as expected in SQLite3Pages?

MoveTo/LineTo/TextOut are working very well with SynPDF enumeration.

Some code to reproduce the issue is needed.
Or at least some WMF file which is not rendered as expected.

Wolsink · 2012-03-21 20:56:01

Thanks for your reply very much.

I do use the PDF engine as an add on to my program only; with the code below (not more than that)

procedure TEditForm.PDFKnopClick(Sender: TObject); {pushing a button}
begin
with TGDIPages.Create(EditForm) do
try
Screen.Cursor:=crHourGlass;
BeginDoc;
SaveLayout;
Font.Size:=10;
TextAlign:=taLeft;
AddLineToFooter(true);
AddPagesToFooterAt(TResourceLocalizer.GetString(LanguageResOffset,2336)+'%d/%d',LeftMargin);
RestoreSavedLayout;
AppendRichEdit(RichEdit1.Handle);
EndDoc;
FileName:=ChangeFileExt(FileName,'.pdf');
ExportPDF(FileName,true,true);
// ShowPreviewForm;
finally
Free;
Screen.Cursor:=crDefault;
end;
end;

The ShowPreviewForm has the same wrong behaviour as ExportPDF(FileName,true,true);

Printing to paper I did not test, I did now however, with a surprising result.
Printing to paper gives the folowing results:
- ExportPDF(FileName,true,true) --> the same wrong behavoiur on screen as on paper
- ShowPreviewForm -->wrong on screen; right on paper (with the aid of the 'Printbutton') <--- that's the surprise

I do use the native RTF format of the RichEdit component (bitmap or meta files embedded in it do work).
Below I copied a small RTF file with one line of text and an embedded metafile (because of size I did ommit the largest part of meta file information however):

{\rtf1\ansi\deff0\deflang1033{\fonttbl{\f0\fnil Courier New;}{\f1\fnil MS Sans Serif;}{\f2\fnil Times New Roman;}}
{\colortbl ;\red0\green0\blue0;\red255\green0\blue0;\red0\green0\blue255;}
\viewkind4\uc1\pard\cf1\f0\fs20
\par \cf2\ul\b\f1\fs28 FRAMEWORK program - displacement method (Statical calculation)
\par \cf3\ulnone\f2\fs20
\par \cf1\ul\fs28{\pict\wmetafile8\picw17489\pich8925\picwgoal9915\pichgoal5060
0100090000036c4600000b001610000000001610000026060f002220574d464301000000000001
00abf10000000004000000002000009c4800009c680000010000006c0000000000000000000000
ef010000fc000000000000000000000051440000dd22000020454d46000001009c6800007a0200
00080000000000000000000000100000008007000038040000a50200007d010000000000000000
000000000000d5550a0048d005001b000000100000000000000000000000520000007001000001
000000f5ffffff0000000000000000000000009001000000000001000000004d00530020005300
61006e007300200053006500720069006600000000000000000000000000000000000000000000

etc. etc. etc.

0500040000002d01060004000000f0010900040000002d010800050000000902ff000000080000
00fa02000001000000ff000000040000002d0105000400000004010d00040000002d0103000400
00002d010400040000002d010600030000000000
}
\par \ulnone\fs20
\par }

I don't know if it does help, but my coding to do graphics is as follows:

.......
Bitmap:=TBitmap.Create;
Bitmap.Width:=Image1.Width;
Bitmap.Height:=Image1.Height;
Image1.Picture.Graphic:=Bitmap;
Mainform.ImageMain:=Image1;
if MtFile then {option for MetaFile pictures is switched on}
begin
MainForm.MyMetafile.Clear;
MainForm.MyMetafile.Width:=Image1.Width;
MainForm.MyMetafile.Height:=Image1.Height;
MainForm.WaarMetaFile:=TMetafileCanvas.Create(MainForm.MyMetafile,0);
end;
PlotGeoMetrie2D(1,tekst,True); {the actual plotting of the picture}
if MtFile then {playing MetaFileCanvas}
begin
Mainform.WaarMetaFile.Free;
Mainform.ImageMain.Canvas.Draw(0,0,Mainform.MyMetafile);
end;
Bitmap.Free;
........

I do hope this information does help you.

Gerrit Wolsink

ab · 2012-03-22 06:19:07

If the preview is not OK, the issue comes from TRichEdit itself, i.e. the Windows operating system.
Preview is just a plain GDI replay of the metafile content exported by the RichEdit control.

Try to set ForceNoAntiAliased = TRUE.
And report if the preview work this time.

Both SynGDIPlus (preview) and SynPDF (PDF creation) handle metafile embedding and scaling.
Some of our projects use such content, and work as expected.

Wolsink · 2012-03-22 19:46:42

Thanks for your advice.

I did add ForceNoAntiAliased:=TRUE

This did solve the problems all together.
Both ShowPreviewForm and ExportPDF(FileName,true,true) works fine now (I am running Windows 7).

Best regards,

Gerrit Wolsink

Wolsink · 2012-03-22 20:52:57

In my last post I was too swift with cheering that all was OK.

I did test it 5 times and all seemed to be OK; suddenly the old wrong behaviour for ExportPDF(FileName,true,true) was back.
ShowPreviewForm does work allways fine however (with ForceNoAntiAliased:=TRUE).
I did reboot my Windows 7 computer; this did not help.
I did run the program on an old computer running Windows XP: same weird behaviour.
As now ExportPDF(FileName,true,true) mostly does not work well, but sometimes it does.
It's puzzling this random behaviour.
Could in be an initialization error of some kind?

Wolsink · 2012-03-23 10:29:32

Back again.

I did some detective work.
I think I know now what the reason is why ExportPDF(FileName,true,true) placed and scaled the metafile pictures wrongly.

I do use the GDI procedure 'FloodFill(X, Y: Integer; Color: TColor; FillStyle: TFillStyle);' to color some parts of the background of the pictures.
If I disable this flood filling all seemes to work OK now.
I don't have to set ForceNoAntiAliased:=TRUE anymore (for both ShowPreviewForm and ExportPDF(FileName,true,true)).
Anti aliasing works fine now therefore.

This all does explain that the border lines of the pictures did picture well and all the other graphics elements not.
FloodFill was applied just after drawing the border lines. It has nothing to do with the type of graphics element (e.g. rectangle, line, text).

The firm conclusion is that ExportPDF(FileName,true,true) does not handle the graphics correctly after applying the FloodFill procedure (in relation to the place and the scaling on the page).

I hope this does help you.

ab · 2012-03-23 21:01:28

This is a gdiplus limitation.

Sorry for the inconvenience..

mORMot Open Source

#1 2012-03-20 21:28:27

incorrectly placed and scaled meta files

#2 2012-03-21 07:40:07

Re: incorrectly placed and scaled meta files

#3 2012-03-21 20:56:01

Re: incorrectly placed and scaled meta files

#4 2012-03-22 06:19:07

Re: incorrectly placed and scaled meta files

#5 2012-03-22 19:46:42

Re: incorrectly placed and scaled meta files

#6 2012-03-22 20:52:57

Re: incorrectly placed and scaled meta files

#7 2012-03-23 10:29:32

Re: incorrectly placed and scaled meta files

#8 2012-03-23 21:01:28

Re: incorrectly placed and scaled meta files

Board footer