(no subject)

Hi Roland,

Roland Kay wrote:
>
> 1, is responsible for the majority of the error observed in the image I posted.
> It can be fixed adding the following two lines to
> GR_Graphics::setZoomPercentage():
>
> void GR_UnixGraphics::setZoomPercentage(UT_uint32 iZoom)
> {
> GR_Graphics::setZoomPercentage (iZoom); // chain up
> // Reset the device font for the new zoom.
> if (m_pFont) // <-- This
> m_pXftFontD = m_pFont->getDeviceXftFont(getZoomPercentage()); // <-- This
> }
>
> Is this an appropriate fix?

That seems correct solution to me -- if the font is cached for specific
zoom factor, than it needs to be refreshed on zoom change.

>
> I'm not at all sure about what can be done about 2.
>

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.

Note that this bug should not affect drawing done in the main document
window, which uses GR_Graphics::renderChars() that IIRC always supplies
the advances. The correct fix is I think to supply advances to
drawChars(). (I suspect we do not want remove the +1.5.)

Tomas

                
___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
Received on Wed Aug 17 09:22:20 2005