Despite adding the width parameter to the //SETFONT GDI printing directive, there have been continuing complaints about fixed pitch variability. For example, a form will be worked out on one printer, only to discover that when printed on another, the horizontal character spacing is slightly more or less, causing the columns to the right of the page to no longer line up with the form.

There was a lengthy discussion of this issue awhile back which led to the addition of the width parameter, which solved most of the problems, but oddly, not for the Courier font. (The Courier font has always mysteriously misbehaved; as just one example, the bold version is often narrower than the normal version.)

To get to the point, I've finally come up with what appears to be a more reliable and precise way to force it (and any fixed pitch font) to render itself at the exact requested size (in terms of characters per inch). The technique essentially consists of explicitly positioning each character, rather than just using the natural font tracking, so it makes the CPU work harder, but the difference in effort will not be perceptible. The question is, whether this new logic should be considered a bug fix and just applied universally, or, since it might result in changes to existing GDI report spacing that has been worked out by trial-and-error, should it be some kind of new option?

To help decide, here's an updated version of the sample document used in the above mentioned thread. The examples at the top of the page show the natural font spacing for three common fixed-pitch fonts at 12 points, in normal, bold, and italic. (The intent being to show that even though they are all 12 point fixed pitch fonts, the actual characters per inch varies with the font face and style attributes.) At the bottom of the page are the same examples, but using the width parameter to specify a width of 72 (tenths of points), which should give us exactly 10 characters per inch. The vertical dotted line shows where each line should end if the spacing was exactly 10 CPI.

First, this is how it works now (i.e. thru 5.1.1148.0). Notice that the line lengths are all the same in the bottom section, except for two problems: 1) they are all slightly too short, coming in at about 9.9 CPI instead of 10.0, and 2) Courier is misbehaving. (The reason for the spacing being slightly less than 10 CPI is that the technique involved adjusting the font cell width, one pixel at a time, until a 50 character sample line came out as close as possible but not beyond the target length, so, depending on various factors, it will be either perfect or slightly short.)



And here's how it looks with the new technique. Notice that now the lines at the bottom are all exactly the right length:



So to repeat the $64 question: should I just apply the fix? Or should we add some new switch to //SETFONT which you have to specify to make the width parameter work precisely and reliably? One idea would be to set the width to the negative value, which would be easy to implement, but might seem a little weird or counter intuitive. Another would be to add a new bit flag to teh pitch-and-family or style parameters. Or, we could just apply the new formula and call it a fix.

That sounds wonderful.

We have perhaps hundreds of programs using GDI. We have taken various measures in each program, location and even down to the printer level to make the forms come out right. I am sure there are many places where we are now relying on the font to come out incorrectly so that it fits.

If you were to apply this universally and these fonts all started working 'correctly' then that would certainly involve changing each program as we go and would frustrate many of our customers.

I would thus vote that you give us the option of when we use this new parameter.

We haven't used the new 'Width' parameter too often since it is relatively new. So if you just wanted to make 72 really do exactly 72 as in your above example we would be able to adjust those few places where we have used that feature.

I'll vote for whatever makes Joe happy...

Seriously, OK for us as we dont use GDI heavily, but if I am understanding this post, I can turn on some nice GDI functions and still get my reports that use MASK commands to print out in line... that would be great.

I would definitely prefer to just make the width parameter do what it was always supposed to do, rather than have to introduce some other flag to distinguish between "sort of" and "yes definitely" modes. Particularly since both of my suggestions above (of using negative values for width or a new flag in the pitch-and-family parameter would cause havoc in earlier versions of A-Shell and ATE). The only backwards-compatible solution I can think of would be to add another parameter to //SETFONT (a rather ugly hack) or to add some global switch, perhaps in the printer init file, to enable/disable the newer precision (perhaps not quite as ugly but certainly complicated and non-intuitive).

So, given the relatively limited use (so far) of the width parameter, my vote is definitely to just make it work as intended. But I'm going to try to get a couple more opinions first.

My vote goes to solutions that don't need special settings to make things work as expected.

Anyway, by now, I don't use "width" in SETFONT so, if some trick can save others to adjust existing programs, I'll be ok with any solution.

Jack, We are not currently using width or //SETVMI in any of our GDI printing. So I guess I cannot offer an opinion since this potential change should not affect us.

Thanks for the feedback. It is certainly sounding like we can get way with just "fixing" the existing features to work more precisely and uniformly, without having to worry too much about preserving existing errant behavior.

Just to follow-up/clarify, the changes described above were implemented in 5.1.1149.0, and here's an illustration of the difference it makes with a 300 DPI driver. (The actual printfile, FIXWID.TXT[908,37] can be downloaded here .)

Here's the output (showing Courier with various widths), prior to 5.1.1149:



And here is is again, with 5.1.1149:



Aside from the fact that the earlier version merged some widths to the same actual size, it also resulted in actual widths that were at most, equal to, but nearly always less than the theoretically correct width, which is what you get in the later version.

For example, since each line of text is exactly 60 characters long, a width of 60 (60/720 = 1/12 = 12 CPI), it should be exactly 5" long. At a width of 72 (72/720 = 1/10 = 10 CPI) it should be exactly 6" long.

Note that the differences are much less dramatic at higher resolutions, and the recommendation remains to set all your printer drivers to at least 600 DPI if you can.