Re: Rotated Text Help Needed

"Howard Henry Schlunder" <howard_hs@xxxxxxxxx> wrote in message
news:4345ab1c$1_3@xxxxxxxxxxxxxxxxxxxxx

> If you call GetTextMetrics(), several useful parameters about the
> font you created will be returned. In particular, tmAscent and
> tmDescent will tell you where the baseline is located relative to
> the top or bottom of the cell, respectively.

Thanks for the response, Howard. Actually I did already know about the
GetTextMetrics stuff, and I was going to use it to adjust the positions, but
I decided not to do so in the question I posted simply because it would have
masked what I saw as being a "bug", and I was hoping that people with
different versions of Windows would post back with some results.
Unfortunately at the moment all responses have been from people running
WinXP. I'm still hoping that someone using Win98 will check it out for me as
well.

> I've run your code on Windows XP Professional SP2 and
> observed the same results you described. Although surely
> aggravating, the behavior you described doesn't look like an
> error at all. It is simply the way the GDI works. When you
> ask for a font rotated at some non-Cartesian friendly angle,
> Windows has to go synthesize the font for you. When it does
> this, it is free to do whatever it thinks will make the end font
> look the best. It is highly probable that your code will yeild
> the same results on Windows 98

Actually I get a completely different result on my Win98 machine, which is
what prompted me to post my question. At the time I had only tested it on
the screen in Win98 (because I didn't have a printer attached to that
machine) but I've now also tested it with a printer and it has confirmed my
suspicions. On my Win98 machine all fonts look exactly the same and the
glyph is positioned in exactly the same position within the character cell,
and the character cell itself is exactly the same height for *all* angles,
including the four angles which seem to be a problem in WinXP. I do
understand that the GDI is constrained by the resolution of the output
device when calculating the rotated shape and size of the glyph and its
character cell, but the differences in the output between Win98 and WinXP
are not merely a couple of pixels. The difference in the case of the screen
is about 10 pixels, and in the case of the printer it is about 60 or 120
pixels (depending on the current printer resolution). I know that the glyph
itself is about the same size, but the character cell (which is, after all,
as much a part of the character as is the glyph itself) is completely
different (Win98 versus WinXP). If Microsoft did not consider the cell to be
important then there would be no point in the GDI providing a SetBkMode API
(or the VB FontTransparent property). So, even though the problem is easy to
fix (as I said in my original message) I still think that it is a "bug".
After all, there is no earthly reason why Microsoft should *deliberately*
change the position of a glyph within its cell and also change the size of
the cell itself, especially as it was already being generated perfectly in
Win98, with each rotated font character being the same for every angle of
rotation under Win98. And even if they did decide to deliberately do such a
thing for WinXP, there is no earthly reason why they should choose to do so
for just four of the thousands of possible angles of rotation! To have a
specifically rotated character glyph sitting in a completely different
position within its cell in WinXP than it does in Win98, and to make that
cell a completely different size as well, is quite an important change. If
it was a deliberate change then it would surely have been documented (which
it has not!). Nope. I'm afraid I've got to stick (at least for the time
being) to my statement that it is a "bug" in WinXP!

Thanks a lot for responding Howard. Your amendments to the code are
appreciated. By the way, when I change your code to output to the printer
instead of to the screen the fonts are not rotated at all. However, I
presume that you know the reason for that. It is another "bug", this time in
the VB printer object, but I'm sure you already know how to fix it. Once
again, thank you very much for your response.

Mike




.