[ to the real mcclim-devel address, this time ] Hi, Find attached a preliminary patch to deal with the fact that, in general, glyphs from fonts are not constrained to draw only to the right of the cursor position. This patch does not correct any of the assumptions about horizontal left-to-right rendering or single-line rendering. However, it attempts to cater for all cases which are currently functional, for the CLX backend (both with ordinary X fonts and with the experimental Freetype bindings). It is probably fairly tricky to trigger problems without this patch using the ordinary X fonts, but using the Bitstream Vera family of fonts in climacs for a little while tends to degrade the display as incremental-redisplay fails to erase the entirety of glyphs (because the bounding rectangle is wrong). It works by introducing a new internal function, TEXT-BOUNDING-RECTANGLE*, which is somewhat analogous to TEXT-SIZE and STREAM-STRING-WIDTH, only capable of dealing with non-zero offsets. TEXT-BOUNDING-RECTANGLE* returns the coordinates of a bounding rectangle that would bound the output of DRAW-TEXT* at position 0 0 and with :ALIGN-X and ALIGN-Y taking their default values. It is entirely possible that I have miscalculated some of the other cases in DEF-GRECORDING DRAW-TEXT: caveat user. With this patch, I was no longer able to trigger disastrous redraw effects on simple climacs editing operations; previously, entering " ___" on a line, putting point at the start of the line and then hitting the space bar a few times would leave a trail of pixels as the output records for almost all the text would move (on my display here, with my freetype options, the #\_ character has an active pixel at -1). The real test case for this is the tablature editor, which is using a font designed such that the centres of characters are at (0,0); unfortunately, I'm not in a position to run it right now, but with luck we'll be able to test this tomorrow (and extend this work to the Postscript backend: maintainers of other backends should chime in at this point to indicate whether this solution is acceptable and implementable :-). Cheers, Christophe