On Wed, Sep 01, 2004 at 12:10:13PM +0200, Branden Robinson wrote: > retitle 263877 xterm: [uxterm] various display artifacts > thanks > > On Fri, Aug 06, 2004 at 04:57:20PM -0400, Thomas Dickey wrote: > > Perhaps we're not talking about the same thing. That should set the font > > in the non-UTF-8 case for xterm. But uxterm is setting environment and > > options so that (I am fighting with PuTTY again ;-): > > > > UXTerm.vt100.utf8Fonts.font > > > > is the corresponding resource which is expected to have an iso10646 font. > > xterm will work with that - if you're not using any characters past the > > iso-8859-1 set. The cells corresponding to missing characters should be > > blank. > > Can someone please help me out with a better explanation of what the bug > being reported here actually is? "various display artifacts" is hopelessly > vague. Well, there are two reports here. The quote above is (as suggested in your comment below) the resource issue. The term "display artifacts" refers to something different. When xterm draws characters on the screen, it (would like to) assume that the characters do not overlap. There are a few cases that come to mind where this does not happen (and the reader sees little dots on the screen as text is written, clipping off the extra trash): a) xterm's fake bold (shifting text right by one pixel), but that "shouldn't" happen since xterm uses clipping. b) xterm misinterprets the font metrics (a possible bug) c) the font metrics (the numbers that tell how large the cells are, their extent), are incorrect. The third case is something that does come up from time to time. However - the report for 263877 sounds mostly like the bug fixed in patch #194 (from the mention of whitespace): Patch #194 - 2004/7/27 - XFree86 4.4.99.11 fix a repainting bug introduced in patch #180: when using a font lacking line-drawing characters, a repaint of the screen could skip horizontally an extra amount after filling in the missing character (reports by Nicolas George, Hans de Goede, Redhat Bugzilla #128341). > Is this yet another case of excess aggression in X resource wildcarding? no > Is there even an actual bug here? Perhaps. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Attachment:
pgpDOMNWN3F7P.pgp
Description: PGP signature