[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#880407: xterm: font issue with FreeType 2.8; should not use the rounded ascender and descender



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 <vincent@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)


Reply to: