On 2017-10-31 16:21:58 -0400, Thomas Dickey wrote: > On Tue, Oct 31, 2017 at 10:39:28AM +0100, Vincent Lefevre wrote: > > Package: xterm > > Version: 330-1 > > Severity: important > > wishlist or normal. Don't soapbox, if you want to have a constructive > discussion.
No, this is really an important bug, with no workaround. This prevents me from upgrading the FreeType packages and related. > Following the discussion here, it's not xterm's bug. > > https://savannah.nongnu.org/bugs/index.php?52165 The fact is that xterm is based on a FreeType bug. The behavior of xterm shouldn't have been changed by an upgrade of the library package. > Lemberg's done this before. In a previous phase of breakage, I added > this feature, which would let you do a workaround: > > scaleHeight (class ScaleHeight) > Scale line-height values by the resource value, which is > limited to “0.9” to “1.5”. The default value is “1.0”, > > While this resource applies to either bitmap or TrueType fonts, > its main purpose is to help work around incompatible changes in > the Xft library's font metrics. Xterm-dev checks the font > metrics to find what the library claims are the bounding boxes > for each glyph (character). However, some of Xft's features > (such as the autohinter) can cause the glyphs to be scaled > larger than the bounding boxes, and be partly overwritten by > the next row. > > See useClipping for a related resource. As I've said in https://savannah.nongnu.org/bugs/index.php?52165 "*scaleHeight: 0.9" allows me to correct the window size, but the rendering is buggy: the blank line is still there[*] and the characters are not correctly erased. [*] I assume that's because (src->ascent + src->descent) > src->height -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
