471,616 Members | 1,353 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,616 software developers and data experts.

Why is there a differnce between Print Preview and Print to printe

Hello,

I've created a Document which i want to print using the PrintDocument class.
In the document i draw some strings, and lines. When I PrintPreviewing my
document (using the PrintPreview class) everything is ok, excatly as i draw
it. but when i'm sending it to the printer, some of the strings and lines are
setping out of the page's border. Why is that? doesn't print preview suppose
to preview the exact printing? is it fixable?

Thanks,
Gidi
Dec 11 '05 #1
2 1924
Gidi,

Well, ultimately, no, it won't. Ideally, yes, it would be, but in the
end, you are "printing" on two different mediums, with different
resolutions, different capabilities. This is why there is probably a bit of
overhead.

Are you checking the bounds of the page in the print preview? You
should scale appropriately and then print the preview that way.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Gidi" <sh*****@hotmail.com.dontspam> wrote in message
news:8E**********************************@microsof t.com...
Hello,

I've created a Document which i want to print using the PrintDocument
class.
In the document i draw some strings, and lines. When I PrintPreviewing my
document (using the PrintPreview class) everything is ok, excatly as i
draw
it. but when i'm sending it to the printer, some of the strings and lines
are
setping out of the page's border. Why is that? doesn't print preview
suppose
to preview the exact printing? is it fixable?

Thanks,
Gidi

Dec 11 '05 #2
As Nicholas pointed out, every target device that you print to has
slightly different qualities. This means that if you print the same
thing to multiple printers, or to print preview and then to some
printers, it's quite possible that the output will vary slightly.

The only away around this that I've ever heard of came from the guys at
Business Objects (aka Crystal) who revealed to me why their Crystal.NET
product (and, I assume, their other versions) does such weird and
annoying things with the printer's DEVMODE structure: it grabs all of
the attributes from the printer you indicate when you're designing the
report, and then attempts to set exactly those attributes (exactly that
DEVMODE contents) on the final output printer. Of course, if the
printer on which you designed the form and the final output printer are
different models (or, God forbid, different brands), the result can be
bizarre behaviour indeed.

I asked them why they did weird crap like that, when it causes us
nothing but grief, and they claimed that it was because they wanted to
guarantee that the designed report would be identical to the final
output. In effect, they wanted to get around the effect that you saw.
Unfortunately, their solution introduces all sorts of limitations,
including practically requiring you to design your report on the same
brand and model of printer as you're going to use in production
(assuming that all of your production printers are the same, or that
you even know what the production printer will be).

In other words, it appears that the alternative to slight differences
between what you see and what you get can be even worse than the
problem itself.

Dec 12 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

9 posts views Thread by igotyourdotnet | last post: by
1 post views Thread by XIAOLAOHU | last post: by
1 post views Thread by ZEDKYRIE | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.