Re: measureString() oddity

Hi Guys,

> This is not FT bug, but AW one. The linearHoriAdvance is obtained for
> layout xft font, but the font which is used to draw is device xft font,
> which is of different size -- it is scaled by the zoom factor, plus
> there is 1.5 added to it (see XAP_UnixFont::getDeviceXftFont()). The 1.5
> is significant at 100%, and I suspect strongly that it is the cause of
> differences you are seeing. (IIRC it was Martin who added the +1.5,
> something to do with improved clarity on screen.) You can test if I am
> correct by removing the 1.5.

Setting extra_font_size to 0.0 doesn't solve the problem. I think the 1.5 is
part of the problem, but it seems more complicated than that. Integer rounding
seems to be at least partly to blame.

For example, if I change the test to display a "B" where it thinks a string
of "A"s finishes then I get the following for zoom=86% and extra_font_size=0.0

        AAAAAAAAAAAAAAA
                          B

But for 87% I get this:

        AAAAAAAAAAAAAAA
                    B

(Note: In reality, it's actually the A's getting wider not the B moving to the
left)

What's happening is that at 86% getDeviceXftFont() calculates a font size of
12.9pt, which it rounds down to 12pt. At 87% it calculates 13.05pt and rounds
to 13pt. As a result, the string gets dramatically wider.

In contrast measureUnRemappedChar() is taking the value for a 120pt font from the
cache and scaling it as a float. Of course, it eventually gets rounded to an
integer as well, but apparently not in step with the device font.

This looks like being a very fiddly problem!

R.
Received on Wed Aug 17 15:03:34 2005