This fixes the problem mentioned by Martin. Apparently Tomas' code touched
the font width cache, changing the width of an unknown character from 0 to
something else, and also using UT_sint32 instead of UT_uint16. This patch
fixes the xft code to compensate. Seems to work fine on my machine.
Thought I'd toss it out for someone else to commit though, since I'm not too
familiar with this code.
Tomas: Do we need to handle both GR_CW_UNKNOWN and GR_UNKNOWN_BYTE in the
font cache, or only one?
Regards,
Will Lachance
[EMAIL PROTECTED]
--- xap_UnixFont.cpp Thu Aug 1 20:30:41 2002
+++ xap_UnixFont.cpp.new Fri Aug 9 17:03:19 2002
@@ -177,7 +177,7 @@
, m_pXftFont(0)
#endif
{
- //UT_DEBUGMSG(("XAP_UnixFont:: constructor (void)\n"));
+ //UT_DEBUGMSG(("XAP_UnixFont:: constructor (void)\n"));
m_cjk_font_metric.ascent = 0;
m_cjk_font_metric.descent = 0;
@@ -508,9 +508,8 @@
UT_uint16 XAP_UnixFont::getCharWidth(UT_UCSChar c) const
{
/* don't care about the pixel size */
- UT_uint16 width = (UT_uint16) m_cw.getWidth(c);
-
- if (width == 0)
+ UT_sint32 width = (UT_sint32) m_cw.getWidth(c);
+ if (width == GR_CW_UNKNOWN || width == GR_UNKNOWN_BYTE)
{
XftFaceLocker locker(getXftFont(12));
FT_Face pFace = locker.getFace();
@@ -524,7 +523,7 @@
m_cw.setWidth(c, width);
}
- return width;
+ return (UT_uint16)width;
}
#else
