--- a/man/ChangeLog	Thu Dec 09 22:51:43 2004 +0000
+++ b/man/ChangeLog	Fri Dec 10 06:36:00 2004 +0000
@@ -1,3 +1,8 @@
+2004-12-10  Stephen J. Turnbull  <stephen@xemacs.org>
+
+	* internals/internals.texi (Better Rendering Support --
+	Implementation): Document reasons for Label Widget crash.
+
 2004-12-07  Malcolm Purvis  <malcolmp@xemacs.org>
 
 	* Makefile (RECURSIVE_MAKE): Removed.
@@ -357,7 +362,6 @@
 	(Future Work -- Lisp Engine Replacement):
 	Add pointers to new node.
 
->>>>>>> 1.271
 2004-11-16  Ben Wing  <ben@xemacs.org>
 
 	* internals/internals.texi (Top):

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