Re: Screen Size

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

"mayayana" <mayaXXyana1a@xxxxxxxxxxxxxxxx> wrote in message news:Q%TZg.11708$Y24.1505@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

I can see how that could be wishful thinking, if ScaleY
is only doing the math for me to provide number of
pixels per *logical* point. But now I'm wondering how
I got it right. My 768px high screen is 8 logical inches
high but nearly 10 actual inches high, yet when I call
DrawText with the conversion I get from ScaleY, the
text in the picture box seems to be an exact match to
the printed text [on the printer] when I hold a printed
sample up to the screen. Shouldn't the screen version
be 20% bigger, since a logical inch in this case is 1.25
real inches?

Actually the DrawText API does not change the size of the characters. It merely draws a specific string of text and wraps it so that it prints into a specified rectangle. It is normally used for printing blocks of text into specific sized rectangles. So I presume you mean that you used the conversion obtained from Point to Pixels to set up the size of your font in the LOGFONT structure that you used with CreateFontIndirect API and then just happened to draw that text to the screen DC using DrawText. Is that what you did? If that is the case (and I'm fairly sure that it is) then you've probably used the pixel value directly when using CreateFontIndirect, without inverting it.

When you use a negative value for the pixel size in the lfHeight entry in the LOGFONT structure (which is what applications normally do) then you are effectively asking Windows to select a font size such that the height of the "glyph" (the part of the character cell actually occupied by the shape of the characters) is the requested pixel height. The overall height of the font "cell" (the height which would be returned by the TextHeight function) is greater than this value, because it also includes an additonal "white space" at the top (known as the "internal leading").

However, when you use a positive value for the pixel size in the lfHeight entry in the LOGFONT structure (which is NOT what applications normally do) then you are effectively asking Windows to select a font size such that the height of the entire character cell (including the "glyph" and including the "external leading") is the requested pixel height. Since the entire height of the entire character cell is the requested value then it follows that the height of the "glyhp" (the actual drawn shape of the characters) is smaller than the requested pixel value (whereas before, using a negative value for lfHeight, the glyph height was the same as the requested pixel value).

So, using a positive value for the lfHeight entry in the LOGFONT structure (which is not the normal thing to do) results in smaller size for the drawn shape of the characters and a smaller overall cell height than it would do if you used a negative value (which is what most other things normally do). It is effectively the same as asking for a slightly smaller font. In your own specific case (where you were using a 768 pixel or 8 logical inch screen height which just happened to have an actual physical height of 10 inches) a point on the screen is physically about 20 per cent larger than a Point on the printer (although it is of course the same "logical" size). But your use of a positive value in the lfHeight entry in the LOGFONT structure effectivily meant that you were asking Windows for a slightly smaller font on the screen than the size you thought you were asking for. This of course meant that the physical height of a specific printed character on the screen more closely matched the physical height on the printer (because using the negative value for the screen and not for the printer meant that the printer and the screen were effectively using two different font sizes, with the font size on the screen being the smaller of the two).

It's a little difficult to explain this stuff in writing, especially at this time of the morning and before I've had my breakfast!, but hopefully what I've written makes sense to you.

Mike



.

Relevant Pages

  • Re: Setting the column width size to n number of characters
    ... size in pixel. ... number of characters. ... for some possible choices of font. ... Roedy Green Canadian Mind Products ...
    (comp.lang.java.gui)
  • Re: make drawString render fonts identically to PhotoShop 7.0
    ... I've noticed that there are differences, pixel for pixel, when ... rendering characters in the same Font with Java and with Photoshop. ... Most characters match pixel for pixel, ... The percentage varies with font choice. ...
    (comp.lang.java.programmer)
  • Re: poorly formed underbrace (s)
    ... characters can be relied on to always ... be adjusted the same way to go onto the pixel grid, ... I tried your document sert up for xelatex and the underbrace seems much better. ... %%!TEX encoding = UTF-8 Unicode ...
    (comp.text.tex)
  • Re: poorly formed underbrace (s)
    ... characters can be relied on to always ... be adjusted the same way to go onto the pixel grid, ... I tried your document sert up for xelatex and the underbrace seems much ... %%!TEX encoding = UTF-8 Unicode ...
    (comp.text.tex)
  • Tk canvas: why are some lines a pixel too short?
    ... My Tk application draws its own characters, ... to have one few pixel fewer lit up on the two right-hand ends compared ... the supposedly symmetrical pattern has a distinctly flat ...
    (comp.lang.tcl)