Posted by Brian Levantine on Thu, 11 Sep 2003 09:24:39 :
Hi Robert. I can see why you're frustrated. Sadly, I'm probably going to
add some more grief to your load. It sounds to me like you've done
everything correctly. I see no reason for the discrepancy between the
printers. The units for all GDI commands to the printer are in TWIPS
(1/20th of a point[inch/72]). The measurements are actually resolved by
Windows or the device driver (I'm not sure which). With the exception of a
straight print, COSP does not do anything to the data that is sent to the
printer. In the case of a straight print COSP does interpret the CR, LF and
FF characters to perform those functions. As far as I know, once a font is
created it remains unchanged. You might consider taking some time to write
a VB print program that uses GDI commands to isolate the problem.
Brian Levantine
brian@signature.net
----- Original Message -----
From: "Robert"
To: "Multiple recipients of list support"
Sent: Wednesday, September 10, 2003 2:24 PM
Subject: Windows Fonts (Printing)
> Hi,
>
> I'm getting totally frustrated with Windows and Xerox over this stupid N32
laser printer...
>
> We just completed a very easy to use print routine that would allow us to
print reports on any
> kind of Windows printer with standard presentation and very few user
input.
>
> It is so smart that it actually recomputes the font size if it believes
that the report details
> will not fit in the print frame.
>
> Obviously we are using fixed pitch font. We selected "Letter Gothic" for
it's readability up 'till
> fairly small size. So far so good...
>
> What we discovered is that stupid Windows does not render fonts with the
same height/width ratio
> if you call a font be height or by width (points size vs CPI).
>
> Anyway, our report routine will generate 2 fonts; the standard font
(default to 10 pts) and the
> title font (typically 12 pts). The title font is used only on the top line
of the page (in the
> header routine) and the remainder of the header and the report data is
printed using the standard
> font.
>
> What I have (in my test program) is a report with 114 columns to fit
between margins 529 & 11495
> pixels. So when I call SET.FONT.STANDARD I tell it to use a font with a
Width of 96 and for the
> Height i multiply that by 2. GetFontInfo confirms that my font once
generated has a Height of 235
> and an AveCharWidth of 96.
>
> What I see on paper is that when my report starts printing it prints a bit
smaller: I calculated
> that it was printing with a 95 pixels wide font. BUT I print a microline
every third line (for
> readability) and the line immediately following the MicroLine is CORRECT
(aka wider than the other
> lines). This happens on only ONE printer and it behaves the same for Win98
& Win XP (totally
> different print driver).
>
> I use the PTR.TextOut routine for printing. I do not call any font or font
align function once the
> header is printed. I tried PTR.MoveTo/PTR.LineTo and the mnemonics...
same!
>
> If I run this on any other printer Laser and/or inkjet, the reports prints
fine.
>
> This was tried with Comet 2002 build 311 and Comet 2000 build 308.
>
> Question to Brian: does Comet touch in any way the data that is sent to
Windows Printing? I
> remember that the QCRT does character repositioning ad every
two-spaces....
>
> I tough that once a font was generated it didn't change... why would it go
back and forth between
> 95 pixels and 96 pixels... only call in between is the MoveTo/LineTo...
>
> Help please !
>
> Robert
> MasterDebugger@yahoo.com
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com