Hi all,
But all this code is commented out, isn't it?
You are right. My fault :-(
Actually the problem with this code is that it is unreadable.
Indeed!
Anyway, the problem seems to be related to font_metrics::ascent:
case MENU_SEPARATOR:
{
// A triangle the width and height of an 'x'
int w = font_metrics::width('x', font);
int ox = font_metrics::width(' ', font) + int(x);
int h = font_metrics::ascent('x', font);
int xp[4], yp[4]; xp[0] = ox; yp[0] = baseline;
xp[1] = ox; yp[1] = baseline - h;
xp[2] = ox + w; yp[2] = baseline - h/2;
xp[3] = ox; yp[3] = baseline; pain.lines(xp, yp, 4, LColor::special);
x += width(bv, font);
break;
}On Qt/FreeWin32, variable 'h' is set to -14, i.e. to a negative value, though it should be positive (ascent should alway be positive, right?)
If you look at frontends/qt2/qfont_metrics.C, you see
int ascent(char c, LyXFont const & f)
{
if (!lyxrc.use_gui)
return 1;
QRect const & r = metrics(f).boundingRect(c);
return -r.top();
}Interestingly, Allan has changed this code in 2002. If I change the return statement back to
return abs(r.top())
the output improves. However, there are still problems with math formula. I assume that method(s) "descent" is/are also involved in this problem. I played a bit with various changes but I didn't find a working solution.
For the time being, the really interesting question is: Does Qt/Win32 return a faulty value - or is Qt/X11 broken - or does LyX rely on random results - or what?
Michael
