Re: measureString() oddity

Won't this problem be (partially) solved in my DOUBLE branch? Rounding
issues should hardly occur there.

For the uninitiated: that branch uses doubles for all its 'layout unit
calculations', reducing/eliminating the bad effects of rounding. Only
when going to device units rounding occurs (obviously)

Marc

On Wed, 2005-08-17 at 14:04 +0100, Roland Kay wrote:
>
>
> 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:26:14 2005