Problems printing EMF drawings

Problems printing EMF drawings

Post by arate » Fri, 25 May 2007 04:04:20


Up to now, I have been working essentially with BMPs. But last December,
I began working on my very first application based on EMFs. I have read
that they would result in better graph quality. My project is now finished
except for the last chapter of the manual.

Everything looks really nice on screen and the few printouts I made many
months ago were OK. However, this week, I have found out that there are
problems in some of the drawings.

My program prints the EMFs using the instruction
Printer.Canvas.StretchDraw(Rect, Metafile);
I am aware that there are bugs with StretchDraw (I'm using Delphi 4) but I
know of no other way to print a metafile. (For bitmaps, I use a procedure
found in

I can insert the EMF pictures in a MS Word document and everything
looks good. However, when I convert the document into a pdf file, I get
graphs that do not come as they should. So, it seems that, at least in
this case, the source of the problem is not StretchDraw.

Here are some of the problems appearing when printing or when
producing a pdf file:
- surface regions colored with FloodFill will no longer be filled
- procedure Rectangle with a Brush.Color set to clBlack and a
Brush.Style set to various line patterns will lead instead to solid
rectangles of various shades of gray
- a bmp used as background to a EMF will not appear at all
- a BMP used as a graph element on an EMF will loose all its
colors and will appear black
- using a BMP and an ImageList with a mask will also result in a
complete loss of colors in some regions of the graph
- some dotted lines are lost, others become solid and some will
even change color (from clMaroon to clBlack)
- some solid line segments have missing parts.

I have also tried producing a pdf file from Open Office. The results
are essentially the same although not completely identical.

I suppose I am not the first having these kinds of problems. However,
I made a few searches with Google, got a lot of advertisements but
no real explanation of what is going on. I also looked in
This lead me to lots of interesting stuff but not much to help me on this.

Of course, I could convert the EMFs into BMPs but I don't see the
advantage of going though all the complications of working with
EMFs if the end products are BMPs.

Now, I do not think this is a printer problem (if it was, the pdf files
would come out OK). This leaves us to question Delphi (at least
version 4) or even the EMF format itself. Or maybe, the problem
comes from the operating system (in my case Windows 98.)

In one of my Delphi books
Peter Norton, John Paul Mueller
Peter Norton's guide to Delphi 2
(Sams Publishing, 1996),
Chap. 7, p. 209
I have found this which might shed some light into this matter
Windows 95 [...] doesn't include the full range of metafile
commands that Windows NT does, but it does provide
some. The result is that you gain the advantage of using
a metafile but Windows 95 won't completely understand
some Windows NT metafiles. Fortunately, if the GDI
doesn't understand a particular command, it ignores it and
goes to the next one.

This could explain why, when printing, the FloodFill instruction
is not executed. But then how come everything is as expected
on screen? Also, this wou

Problems printing EMF drawings

Post by Grandmaste » Fri, 25 May 2007 04:10:11

You usually cant perform all the same tasks on a printing device that you
can on screen. A lot of printer drivers are write-only, so a floodfill
would have no way of _reading_ the pixels that are already set on the
printer to be able to do the flood fill.


Problems printing EMF drawings

Post by arate » Fri, 25 May 2007 05:50:23


I forgot to mention that, from my program, I was able
to convert all EMFs to BMPs without any problem
(except the expected loss of graph quality).


PS: One of the interesting sites I found while performing
my searches last night is ~cho/3kdt/index2.php?viewall=1&bgcolor=
I do not know how many of you out there knew its
existence but it is huge: 29 079 links to articles on
how to perform some tasks with Delphi. (Just though
this might be of some interest.)

Rem: For email, you need to replace artima by altima
in the address appearing in the header.

Problems printing EMF drawings

Post by arate » Fri, 25 May 2007 06:52:27

I though that the Printer.Canvas was a sort of buffer set by Delphi were
the drawing commands could all be played out before the whole thing
is sent to the printer.

OK. I have a very old printer (an Epson LQ-500, dot matrix printer). Now,
what you are saying seems to imply that on some other printers, I may
be able to obtain an appropriate printout if the driver is not read-only.
What surprises me is that, when I send the printout to a pdf file, I get the
same problems with the FloodFilled regions. Surely, we should expect
better than that from Acrobat Writer.

If the only problem was with FloodFill, I could easily get around it and
write my own FloodFill procedure (even if I hve to color the region pixel
by pixel :-).

What I really find puzzling is the Bursh.Style bsHorizontal and the like
being replaced by bsSolid with various shades of gray when my Word
document is converted into a pdf file.

Anyway, I will try to contact a friend and ask him to print some emf files
on his printer and wee what comes out of it.

Thanks for the info.


Rem: For email, you need to replace artima by altima
in the address appearing in the header.

Problems printing EMF drawings

Post by Team » Sat, 26 May 2007 01:50:46

That is likely not what is happening. These brushes basically use
predefined 8x8 bitmaps to fill the region, so the lines are only a few
pixels apart. When that is rendered on a canvas with a much higher
resolution (= smaller pels) you simply cannot see the individual lines
anymore, unless you use a magnifier. The resulting pattern of tightly
spaced lines on white looks grey to the *** eye.

The problem is that some of the GDI instructions do not scale properly
when you StretchDraw a metafile. Metafiles are really geared towards
containing line drawings and text, any kind of bitmap content has
problems when scaling. You usually have to enumerate the metafile
records manually and modify the drawing code for some of the commands
you find.

A way out that you should try is to forget about StretchDraw. When you
compose the metafile, do not use the default MM_TEXT mapping mode. Set
the metafile canvas up using one of the hires mapping modes, e.g.
MM_HIMETRIC or MM_TWIPS. Then draw everything using this mapping modes
logical units (that requires some fiddling when it comes to text
output, since you have to set the metafilecanvas.font.pixelsperinch
property to the correct conversion factor yourself before setting
font.size will work. For MM_TWIPS the value to use would be 1440). When
you render a bitmap StretchDraw it with the appopriate scaling. When
you want to print the metafile set the printer.canvas to the same
mapping mode first and then use canvas.Draw, not StretchDraw.

Unfortunately the VCL tCanvas class was not designed with mapping mode
support in mind, some operations you do on it may get the mapping mode
reset. So if you observe problems check the mapping mode at certain
places in your drawing code. Or do all drawing using *** API
commands, even though that is mucho cumbersome...

Peter Below (TeamB)
Don't be a vampire ( ),
use the newsgroup archives :

Problems printing EMF drawings

Post by Grandmaste » Sat, 26 May 2007 03:58:27

'May' being the very key word there :-)
Some printers will let you get away with it, some wont. Actually, most
wont. If you're doing a lot of raster level graphics like flood fills,
you're probably better off rendering to a bitmap and then printing the
bitmap. Which is what I think you said you were doing originally.

Not necessarily. You need to understand what the adobe pdf makes is
creating. Its not creating an image, but outputtig pdf (basically
postscript) drawing commands.

Unfortunately, printing graphics isnt as simple as it should be. :-(

Problems printing EMF drawings

Post by arate » Sat, 26 May 2007 21:21:47

n 24 May 2007 09:50:46 -0700, "Peter Below (TeamB)" wrote:

What you are saying makes a lot of sense. However, when I examine
closely the pdf file, it surely does not look like this. Using the Acrobat
Reader magnifier, I zoomed in on a rectangular surface filled with
bsHorizontal. I pushed magnification to the limit, then used a physical
magnifying glass. The filling still seemed bsSolid. I didn't even see
some anisotropy between the horizontal and the vertical directions.

With one of my emf illustrations, I had some parts of vertical line segments
that were missing. In the same illustration, I had a bar over a letter e that
was shifted to the left. The e-bar (representing a positron) was obtained
with two consecutive TextOut instructions. Again, the image seemed fine
on screen and also when inserted into a MS Word document but defects
appeared when the doc file was converted into a pdf file. Maybe, in this
case, the problem came from Acrobat.

I wondering how many commands I would have to modify in order to
fix all problems and how much time all this would take. And, since I
may not have all the technical information on metafiles, there is no
garanteed success. It might be simpler for me to start from scratch
and invent my own vector graphic format (supposing this is not well
over my head).

When I read this, last afternoon, I had no idea what all this was about.
I should have mentioned that my knowledge on GDI and API is almost
non existent. (I work solely with the Canvas.) Now, after a bit of reading,
I understand most of your explanation.

There is, however, one thing that I am missing. From what you are saying, it
seems that we cannot use one mapping mode for some part of the graph
and another mapping mode for some other part (e.g. MM_TEST for writing
text and MM_TWIPS for drawing). But, from what I have read, I was under
the impresion that changing the mapping mode what just changing the way
we label the points of the device (just like, in mathematics, a change of
coordinate system will not affect the physical space it describes). Of
course, sending the emf to the printer may require all graph elements to
have the same mapping mode.

The more I learn about metafiles, the more they seem to lead to some
messy programming.

I don't think I want to get into API. I try, as much as possible to stick to
high level programming just in case I would decide one day to migrate
from Windows to Linux or to some other operating system.

I really have to feflect on all this. The more time I put on this, the less
time I will have for some projects in physics...

Thanks for the info.


Rem: For email, you need to replace artima by altima
in the address appearing in the header.

Problems printing EMF drawings

Post by arate » Sat, 26 May 2007 21:21:55

That is encouraging. :-)

Yes. Actually, right from the start, my program could save the graph
as an emf and export it as a bmp. It could also import a bmp but not
print it. I have now modified it a bit so that, if the user selects the Print
option, the program will display a dialog box asking it the graph is to
be printed as an emf or as a bmp, this while displaying some text
about possible problems with the emf format.

Most of the pdf fies I see in science have high quality graphs. For example,
if you visit
you can download the last issue (# 120) of Phys13 New (it's free). And if
you examine the illustration of p. 8, (Fig3) or the one on p. 14, you will see
high quality drawings. Using the Acrobat magnifier, we can zoom in and
lines will remain lines, we won't get stairs of pixel blocks. So, surely, these
illustrations were not inserted in the document as bitmaps. This is the graph
quality I would like to achieve.

For an example of a filled surface, we could look at one of the passed
issue (# 118), p. 9, Fig. 1.

I agree but I find this quite puzzling. So many people in science need
graphs to illustrate their thoughs or to represent their data.It's rather
strange that this problem has not yet been setlted in a satisfactory


Rem: For email, you need to replace artima by altima
in the address appearing in the header.

Problems printing EMF drawings

Post by David Ninn » Sat, 26 May 2007 22:14:04

> I agree but I find this quite puzzling. So many people in science need

Hi Andre,

It might be easier if you don't start with bitmaps, bitmaps aren't
scalable well and emf has the problems you've noted.

Perhaps think of it from the angle of :-

You have a graph in memory, it has x,y co-ordinates along the bottom,
vertical bars, lines etc. When the graph is rendered to the screen it
will take up 640 x 480 pixels and the bars will be so wide etc. When the
graph is to be rendered to the printer then it will be 15cm wide and
10cm heigh on a piece of A4, the bars, lines etc are scaled accordingly.

In both cases the graph has the same relative appearance but you're
rendering code is optimised for each device. There is a sort of
universal way of doing this by using the canvas, but it's not as easy as
displaying a bitmap to screen. If you start from this abstract
representation then view the printer and display as different ways of
displaying the same data it may be easier.

It would be a lot easier if something like display postscript had made
its way to windows but it never seemed to catch on.


Problems printing EMF drawings

Post by Nils Haec » Sat, 26 May 2007 22:56:02

If you go for your own vector drawing engine.. you will have the problem
that you must print your output as bitmap. This means large spool files, and
so on. So first find out if that's ok (just calculate: trying to print an
8x11" sheet at 600DPI, full colour, requires 8x11x600x600x3 = 95Mb of data).

If you're interested, I did the same, you should try my Pyro engine, it does
very high-quality drawing, and vector to bitmap conversion.

I did not yet write a webpage for Pyro, since it's still not mature, but you
can look at this forum:

Kind regards,


Problems printing EMF drawings

Post by Nils Haec » Sat, 26 May 2007 23:00:56

If you want to create high quality PDF's, dont go for metafiles but buy one
of the PDF components to create them directly.


Problems printing EMF drawings

Post by Team » Sun, 27 May 2007 02:23:50

ndre Ratel wrote:

Then the postscript-based driver used by acrobat does not support
pattern brushes for area fills. The last time I did Postscript was
about 15 years ago, but the Red Book is still sitting on my shelf <g>.
The language does support pattern fills, but they work a bit
differently than the Windows GDI does it.

Never tried it myself, but it can get complex from what I've heard.

In theory you can, but you just buy more problems this way.

The main point I should perhaps have mentioned is that it is much
better to start with a high-resolution image and reduce it to a smaller
resolution when you render it than the other way round. And these
mapping modes are device-independent, so you are relieved of the
problem of having to adjust your drawing code to the target device.

Not if you avoid bitmap content <g>.

EMF is a MS proprietary format, so you are sunk anyway if you want to
move to another platform. If you want a platform-neutral output format,
use Postscript.

Peter Below (TeamB)
Don't be a vampire (,
use the newsgroup archives :

Problems printing EMF drawings

Post by arate » Mon, 28 May 2007 10:44:51

n 25 May 2007 10:23:50 -0700, "Peter Below (TeamB)" <none> wrote:

With bitmaps, I am doing something a bit like that. I work essentially
with real math coordinates and have two functions for converting (x, y)
into pixels coordinates. When I want to print directly from my program,
I use a large bitmap and, after I StretchDraw it ot the Printer.Canvas,
I get an output which is not too bad (considering that the printer is a
24-pin DMP).

Now, just to check that I am getting this right:
With bitmaps, changing the mapping mode would amount to changing
the way math coordinates (in this case integer values) would map to
the pixel coordinates. Since drawing is performed on an Image.Canvas,
somewhat limited by the size of the screen, I would still need to StretchDraw
the picture to the Printer.Canvas. If I really want a high resolution printout,
I would need to first draw on the screen (just to see what's going on) and
then, later on when printing, to draw again on the Printer.Canvas using
its full resolution. (One could wish that this whole process would have
been automated.)

This was for bitmaps. Now, for a metafile, things work differently. Instead
of sending a picture to the printer, we are sending drawing instructions
which are to be replayed this time on the Printer.Canvas. If then we are
using a device-independent mapping mode, we will get the usual graph
resolution on screen but a much higher resolution on the printer. We get
the best of both canvases (screen and printer) without having to draw
twice. Am I right?

Another question:
If, instead of being printed, let's say that the picture is being saved to be
printed later on or is inserted into a Word document and converted, with
the rest of the document, to a pdf file. I suppose then that we will be, again,
stuck with the screen resolution.

If this means that I just have to avoid FloodFills and pattern brushes
for area fills while all the rest comes out real nice, it won't be too bad. :-)

I was suspecting this but was hoping that metafiles had made their way
to other operating systems. If, for instance, I look at the Open dialog box
of Paint Shop Pro, I see the following formats (among others)
BMP - OS/2 or Windows Bitmaps
IFF - Amiga
MAC - MacPaint
PCT - Macintosh PICT
RAS - Sun Raster Images
There are lots of OS exchanges in there.

My other hope was that other operating systems, like Linux, had
a similar graph format. Since I have tried to isolate as much as
possible the metafile stuff from the rest of my routines, I woun't
have much work to do when adapting my code to a new format.
The last thing I want is to have API instructions scattered in my

But, I agree that it would be better to use Postscript. In fact, I would
have chosen EPS instead of EMF if the format had been available
within Delphi.


Rem: For email, you need to replace artima by altima
in the address appearing in the header.

Problems printing EMF drawings

Post by arate » Mon, 28 May 2007 10:45:05

gt;Hi Andre,

I totally agree. In fact, in my procedures I work as much as possible with
math coordinates (x, y) which are real values, not integers. When I need
to access the Canvas, they are converted to pixels positions through two
mapping functions.

Now, I absolutely need to draw on screen just to see what is going on.
A few years ago I was plotting complicated functions taking more than
24 hours to draw and I needed to check periodically that the parameters
I had chosen were not too bad. And for these kinds of long runs, I don't
want to do the whole calculations again just for redraw the graph to the

But there may be a convenient way of implementing what you are
suggesting. We could have two canvases: one to be displayed
on screen and another with a much higher resolution which would
not be visible. Each calculation would be done just once but each
drawing instruction will be done twice, once for the screen canvas
and once for the invisble one. This way, we would have on screen
immediate feedback on what is going on. And, when the job is
finished and we are ready to print, we just have to StretchDraw
the content of the invisible hi-res bitmap to the Printer.Canvas.

That is th only way I see of implementing what you are saying.

Now, a question remains. Let's say that we want to insert the
graph in a Word document to be converted to a pdf file. How
do we proceed? If we use the low-res screen image, we are
back to the original problem. If we try to use the hi-res one, it
will occupy too much space on the page and may even not
fit. Of course, we can use Word to shrink the image but then
line segments become too thin and text become barely lisible
unless a wider Pen and a larger Font were used when making
the image. This mean that we need to use a different Pen.Width
and a different Font.Size for the invisible bitmap than for the
screen bitmap. This is not too much complications but will
require many tests.

But,maybe, you had something else in mind...

Microsoft, as usual, had to go its own way. :-)

But, of course, nothing prevents Borland from implementing EPS graph
format for Delphi.

There is probably some Fortran code out there on how to make EPS
graphs. I did perform a search with Google but didn't find any yet.


Rem: For email, you need to replace artima by altima
in the address appearing in the header.

Problems printing EMF drawings

Post by arate » Mon, 28 May 2007 10:45:12

This would be great for a standalone file to be printed.
However, it does not seem psooible to insert a pdf
image directly into a Word document.

I think, however, that ther is an Adobe utility with which
we can combine pdf files.


Rem: For email, you need to replace artima by altima
in the address appearing in the header.