468,290 Members | 2,019 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,290 developers. It's quick & easy.

graphics & printing

When I draw (using DrawString() and other Draw...() methods) directly
to the PrintDocument using the PrintDocument's PrintPageEventArgs e,
the print-out comes out nice and sharp. But when I direct my graphics
to memory first then using PrintDocument's PrintPageEventArgs
e.DrawImage(), I get the image printed with the right scale and
everything, but the characters and everything else is blurry, out of
focus and just generally very bad.

I adjust the units of the DrawString() and other Draw...() methods
when I paint to memory because, I believe, the smallest printer unit
is 1/100th of an inch while the memory's is 1/300th of an inch or
thereabouts. But that is neither here or there, I just wanted to
mention it to say that I am already aware of the difference in units.
At any rate, the picture is in the right size but the image is so darn
fuzzy. I tried painting the memory image to a form first before
sending it to the printer and it paints fuzzy on the form too.

I played with SmoothingMode, TextContrast and TextRenderingHint and
others, to no avail.

I searched for solutions on microsoft's site, also to no avail.

Does anyone know why I am getting such fuzzy images when I paint to
memory first?. Am I missing a trick or something? Your help is
greatly appreciated.
jake

Apr 15 '07 #1
1 3397
On Sun, 15 Apr 2007 16:09:55 -0700, jake <ja********@gmail.comwrote:
When I draw (using DrawString() and other Draw...() methods) directly
to the PrintDocument using the PrintDocument's PrintPageEventArgs e,
the print-out comes out nice and sharp. But when I direct my graphics
to memory first then using PrintDocument's PrintPageEventArgs
e.DrawImage(), I get the image printed with the right scale and
everything, but the characters and everything else is blurry, out of
focus and just generally very bad.
I don't think "fuzzy" is a precise enough description of what's going
wrong for anyone to say for sure what you need to fix.

However, I'll suggest a couple of things. First, modern printers have
resolutions *much* higher than 1/100th of an inch (that would be 100 dpi),
while screen resolution is generally fixed at much less than 1/300th of an
inch (that would be 300 dpi, whereas the default under Windows is 96 dpi,
though it's hard to make a perfect determination due to varying display
sizes and resolutions). Second, if you draw your image to memory first
then the resolution of the image is limited to the resolution of the
destination memory image (Bitmap in this case, I assume). If you simply
use the default resolution for a memory image, then the image is going to
be lower resolution when drawn to memory first.

If you feel that you need to draw your image to memory before printing,
there are a couple of ways you can avoid the loss of resolution. The
first would be to create a Bitmap that has the same resolution as the
destination printer. Of course, you need to get the printer resolution to
do this, and of course the memory required may be large, or even
prohibitive (depending on the resolution of the printer and the size of
the paper).

An alternative would be to draw to a Metafile first, instead of a Bitmap.
The basic mechanism is essentially the same, but rather than your drawing
being rasterized into a pixel-based bitmap, the actual drawing calls are
recorded into the metafile. This has two effects: one, the size can be
much smaller, because its the commands that are stored, not each
individual pixel; and two, since the original drawing calls are stored,
when they are played back (drawn) to the printer, the full resolution of
the printer is used.

The above may or may not be of use. Since your problem description is so
vague it's hard to know what exactly the problem is. But hopefully it's
relevant.

Pete
Apr 15 '07 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

7 posts views Thread by DotNetDeveloper | last post: by
reply views Thread by Mark Davison | last post: by
2 posts views Thread by ECVerify.com | last post: by
reply views Thread by Tom McL. | last post: by
6 posts views Thread by Chris Dunaway | last post: by
reply views Thread by NPC403 | last post: by
2 posts views Thread by MrBee | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.