Mercurial > hg > xemacs-beta
diff man/internals/internals.texi @ 2431:8f3d34b5fc05
[xemacs-hg @ 2004-12-10 06:35:54 by stephent]
document Xft issues <87k6rqwtjf.fsf@tleepslib.sk.tsukuba.ac.jp>
author | stephent |
---|---|
date | Fri, 10 Dec 2004 06:36:00 +0000 |
parents | ab71ad6ff3dd |
children | 6c7488f5350a |
line wrap: on
line diff
--- a/man/internals/internals.texi Thu Dec 09 22:51:43 2004 +0000 +++ b/man/internals/internals.texi Fri Dec 10 06:36:00 2004 +0000 @@ -23137,6 +23137,21 @@ engine interface'' to ``text'' seems like a plausible way to focus this work. +Further evidence for this kind of approach is a bug recently fixed in +the @samp{xft-sjt} branch. XEmacs was crashing because the Athena Label +widget tried to access a nonexistent font in its initialization +routine. The font didn't exist because although no core X11 font +corresponding to the spec existed, an Xft font was found. So the XEmacs +font instance existed but it did not specify an X11 core font, only the +Xft font. When this object was used to initialize the font for the +Label widget, None (0) was passed to XtSetArgs, then XtCreateWidget was +called, and the internal initialization routine attempted to access that +(nonexistent) font while computing an X11 graphics context (GC). + +A similar issue applies to colors, but there Xft colors keep the pixel +data internally, so (serendipitously) the X11 color (@emph{i.e.}, pixel) +member does get updated. + @item Colors, fonts, and faces Besides the rendering engine itself, the XEmacs implementations of these objects are poorly supported by current widget implementations,