Fog Creek Software
Discussion Board

Print Preview Calculations

I'm having some trouble with a few calculations I need to do.  First of all let me explain what I am doing.  I am trying to create a print preview in VB6.  It should obviously match the printer output, but it doesn't.

Even though I create a picture box of the exact same size as the sheet of paper the output does not match.  I'm thinking it's because of the difference in DPI.  The Printer is 360 DPI and the Screen is 96 DPI.  I want a 72 Point Font to be 1 Inch high on both.  Seems trivial but I can't get it to match.  The Picture Box in VB is being measured in Twips and so is the printer output.  I don't understand why they wouldn't match up.  Now if I fiddle around and adjust the size of the picture box a little bigger I can get the outputs to match.  The problem is I can't come up with a formula to calculate the difference between the printer and the screen.

For example:

If I had an 8.5 by 11 in. sheet of paper, It would be:

1440 x 8.5 = 12240 twips wide (which is what i make the picture box)

1440 x 11 = 15840 twips high (which is also the initial size of the picture box)

This should match the physical sheet of paper but it doesn't so I have to add a certain amount to both width and height of the picture box:

For example:

12240 + 1585, 15840  + 1585 gives me the correct output on a 360 DPI printer with a 96 DPI screen.  The problem is coming up with a generic formula to come up with "1585" for any given set of inputs.  Or maybe the problem lies further back in that you can't match a picture box measured in twips to the same size sheet of paper measured in twips.

Any tips from people who have created a print preview would be appreciated.

Tuesday, January 6, 2004

From experience, you're about to spend a lot of time in tears.

Basically, the printer's have a printable area. This is the bit of A4 they can actually put ink on.

They also have an idea of where their print origin on the page is. Here's a clue as to the problem: It's neither the printable area, nor the actual corner of the paper.

Not only does it vary from printer to printer, print driver to print driver, it also varies a bit from page to page because of the mechanics of loading the paper. And you can't get sensible answers about these questions from the printer or the print driver. You can get some indication of it by asking how big the non-printing border is and then indenting by that much (I think -- it's been a while).

In order to get decent alignment between the printer and a feature on the paper (such as perforations) we ended up experimentally determining tweak values for the edges in twips for common printers and designing the printable stuff/perforations so they could cope with being out a bit.
Lets put it this way, after the experience of doing this, I swore off doing anything complicated with low-level printing ever again. The closest I come these days is writing LaTeX files...

Tuesday, January 6, 2004

My last job was in a print shop writing VB apps to generate the actual PCL code for the printers.  We had X-constants & Y-constants for each printer.  Yes, the two lasers were the exact same model, but they still printed differently.  Our print drivers never changed, but that would change the constants as well.

I hate printers.

Tuesday, January 6, 2004

In short with plain VB you can't.
The best way is to create a windows metafile using the printer DC then play it back to the screen. If you don't the fonts will never match. This is mostly due to font rounding.
If you can cope with some slop then it'll be OK, however if you want good looking results metafiles are the only way to go. (The same flaws exist in .NET)

Peter Ibbotson
Tuesday, January 6, 2004

I meant to say I need to write a sample for other purposes, if I get a chance I'll post a link to the code.

Peter Ibbotson
Tuesday, January 6, 2004

There I go again trying to do the impossible.  Thanks for the replies guys.  I'll try the metafile thing Peter and see if I can get it to work.  Of course your sample code would always be appreciated.  This must be how DocuCom PDF driver and others like it work?

Tuesday, January 6, 2004

OK websites up with a little discussion document see:

Peter Ibbotson
Thursday, January 8, 2004

*  Recent Topics

*  Fog Creek Home