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)
>

I'm not sure this will be the full solution.

The problem is that the zoom wants fonts at 12.9 then 13.05 which get
rounded to 12 and 13 for zooms of 86% and 87%. The measureUnremapped char
method calculates their widths as the values they effectively get at 12.9
and 13.05.

Even with your doubles patch the fonts will still be chosen as 12 and 13
when they "should be" 12.9 and 13.05.

I think the solution will require being able to do sub-pixel positioning.

We need to see what API's allow this.

ie FreeType, pango, Cairo, OSX, Windows GDI?

Martin

> 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 Thu Aug 18 00:21:12 2005