Re: Screen vs Printer Fonts
- From: "Mike Williams" <Mike@xxxxxxxxxxxxxxxxx>
- Date: Sat, 3 Jan 2009 11:48:50 -0000
"Marv" <marvwade@xxxxxxxxxxxxxxx> wrote in message news:ujqYlWUbJHA.1184@xxxxxxxxxxxxxxxxxxxxxxx
The list box is defined as using Courier New at 9 pt.
There is a label at the top of the list box which is
defined as Courier at 10 pt. After the display, I copy
the contents of the label and the contents of the list box to an array and send it to a common print routine the
defines the output as Courier 10 pt. The heading and
the entries in the list box are aligned just right on the display but when I print them they do not.
Firstly you've mentioned two different fonts in your post (Courier New and Courier). The former is a TrueType or OpenType font which has a fairly wide range of available point sizes and the latter is a Screen Font which is much more restricted regarding the available point sizes, so I'm not quite sure exactly what you are doing, or whether your mention of two different font names is a simple typo in your post.
Secondly, even if you use the same font name and point size on both the Form (or on the various controls you're using) and the Printer, and even if you use a fixed character width TrueType font (such as Courier New) rather than a proportionally spaced font, you will still have problems regarding character alignment if you are relying merely on spaces to create the alignment for you. This is because all fonts, whether they are screen fonts or TrueType fonts, are restricted to being displayed in "whole pixel" units on the output device on which they are used. This "whole pixel" limitation applies both to the point size itself and to the width of each character cell.
There are always 72 points per logical inch and if, for example, you set the point size to 8 points on a Form (or on a control on the Form) and your machine is running at the standard 96 dots per inch display resolution which most machines are set to use (what used to be called the "small fonts" setting) you will actually get a point size of 8.25 points. This is because the system needs to set the point size in display pixels (using whole pixel units rather than points) and the nearest whole pixel size to 8 points on a 96 dpi display is 11 display pixels (8 / 72 * 96 = 10.667 pixels) and 11 pixels equates to 8.25 points. The same principle applies if you set a point size of 8 points on the Printer, except that your printer probably has a resolution of 600 pixels per inch and so the nearest available whole pixel size on the Printer will be 67 printer pixels (8 / 72 * 600 = 66.67) and 67 printer pixels equates to 8.04 points. So, when you ask for an 8 point font you will actually get 8.25 points on the screen and 8.04 points on the printer (on a system such as the one I have described). The values on your machine may be different of course, because you may be running your display at something other than 96 dpi and your printer may be running at something other than 600 dots per inch, but similar problems will still exist. Things at first appear better when you use 9 points because a point size of exactly 9 points (on the system I have described) is available on both the 96 dpi screen and on the 600 dpi printer (exactly 12 screen pixels and exactly 75 printer pixels respectively and so you will get exactly 9 points on both devices. However, even 9 point fonts still have the same kind of problems because this "whole pixel" requirement applies to the width and horizontal placement of each character cell as well as the vertical point size. For example, if you set the font to Courier New 9 points you will get 9 points both on the screen and the printer, but the fixed width character cells will be different, being 5.24 points wide on the display and 5.40 points wide on the printer.
The bottom line is that things which line up neatly on the screen will not necessarily line up neatly or in the same way on the printer, even if you are using fixed width fonts. In the case of your own specific problem there are two solutions. The first is to effectively take a screen grab of the portion of the Form you are interested in and then print the resultant bitmap to the printer (there are numerous ways of doing that). However, it is not what I would call the preferred method because it limits the printed output resolution and the quality of the printing will therefore not be particularly good. The second method, which is the one I would suggest, is to print your output using the Printer.Print method (as I assume you are currently doing) but to specifically set the desired print position of each text element using either Tabs or Printer.CurrentX or Printer.CurrentY as appropriate. Personally I would suggest using CurrentY because Tabs are not always reliable and they do not always do what you might expect them to do.
For example, if you wish to produce a printed list of four columns of text with each column neatly aligned then use Printer.CurrentY to set the horizontal print position to the desired column coordinate immediately before you print each piece of text into that column. Alternatively, if you are printing "one column at a time" rather than "one row at a time" you can use Printer.ScaleLeft to set the desired horizontal column position before printing each full column with multiple Print statements. This will save you preceeding each Print statement with a Printer.CurrentY because it will cause the implied Printer.Newline at the end of each Print statement to move the print position back to the horizontal position set by ScaleLeft rather than to the left edge of the page.
Mike
.
- References:
- Screen vs Printer Fonts
- From: Marv
- Screen vs Printer Fonts
- Prev by Date: transfer text from label to textbox preserving linebreaks
- Next by Date: Re: transfer text from label to textbox preserving linebreaks
- Previous by thread: Screen vs Printer Fonts
- Next by thread: How to connect to 2 mdb files with one Data control at run time?
- Index(es):
Relevant Pages
|
