FreeType 2.8 uses different rounding rules for ascender and descender, so that one can now have (src->ascent + src->descent) > src->height in CACHE_XFT from fontutils.c (only because of rounding), which yields a spurious blank line between lines of text. The consequences are: 1. Tables look a bit ugly. 2. Windows (with the same number of text lines) are unnecessarily higher than before. 3. This breaks existing configurations. For instance, the xterms started at the beginning of my X session appear partly off-screen. Upstream now recommends to use the values from the FT_Face structure and scale them manually: ------------------------------------------------------------------------ Global size metrics values in the `FT_Size_Metrics' structure can be different for TrueType fonts. Reason is that in older FreeType versions the metrics were rounded differently to integer pixels compared to all other font formats, yielding an inconsistent behaviour if you used non-native hinting. Starting with this version, global size metrics for TrueType fonts are handled the same as other font formats: `ascender' gets rounded up, `descender' getsrounded down, `height' gets normally rounded, and `max_advance' gets normally rounded, too. If you need more precise values of (global) ascender, descender, height, or `max_advance', please take the corresponding values from the `FT_Face' structure and scale them manually.------------------------------------------------------------------------ See the discussion: https://savannah.nongnu.org/bugs/?52165 Here's my original Debian bug report about FreeType: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866960
[...] Well, for TrueType fonts (as it was mentioned later). But this seems to be the most common fonts from FreeType on Debian, and the default ones.
wishlist or normal. Don't soapbox, if you want to have a constructive discussion. Following the discussion here, it's not xterm's bug. https://savannah.nongnu.org/bugs/index.php?52165 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.
wishlist or normal. Don't soapbox, if you want to have a constructive discussion. Following the discussion here, it's not xterm's bug. https://savannah.nongnu.org/bugs/index.php?52165 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.
No, this is really an important bug, with no workaround. This prevents me from upgrading the FreeType packages and related. 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. 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
No, this is really an important bug, with no workaround. This prevents me from upgrading the FreeType packages and related. 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. 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
No, this is really an important bug, with no workaround. This prevents me from upgrading the FreeType packages and related. 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. 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
At 2017-10-31T16:21:58-0400, Thomas Dickey wrote: Oh, so _this_ is the reason that when I use the lovely FreeMono font, horizontal walls in NetHack have holes in them. Serious business.
I investigated, found that it is a defect in FreeType. None of the comments in https://savannah.nongnu.org/bugs/?52165 were helpful (some of the information is incorrect). I made a workaround for this problem in patch #331.
I investigated, found that it is a defect in FreeType. None of the comments in https://savannah.nongnu.org/bugs/?52165 were helpful (some of the information is incorrect). I made a workaround for this problem in patch #331.
We believe that the bug you reported is fixed in the latest version of
xterm, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 880407@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Sven Joachim <svenjoac@gmx.de> (supplier of updated xterm package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Thu, 04 Jan 2018 18:06:06 +0100
Source: xterm
Binary: xterm
Architecture: source
Version: 331-1
Distribution: unstable
Urgency: medium
Maintainer: Debian X Strike Force <debian-x@lists.debian.org>
Changed-By: Sven Joachim <svenjoac@gmx.de>
Description:
xterm - X terminal emulator
Closes: 869248 877628 879936 880120 880407 880551
Changes:
xterm (331-1) unstable; urgency=medium
.
* New upstream release.
- Add workaround for improper grayscale adjustments made in FreeType
library, exposed by changes to rounding in 2.8.1, which shows up as
a gap in line-drawing characters (Closes: #880407).
- Replace constant 10msec delay for next X event with new resource
nextEventDelay, and reduce that to 1msec to accommodate faster machines
than used when -hold was implemented in 1999 (Closes: #877628).
- Add scroll-to action, which simplifies binding a key to scroll to
the beginning or end of the saved-lines (Closes: #880120).
- Improve workaround for #542434 by using the font's maximum width
when no ISO-8859-1 glyphs are provided (Closes: #879936).
- Additional manpage macro cleanup (Branden Robinson, Closes: #880551).
- Fix typography in xterm.man (patch by Bjarni Ingi Gislason,
Closes: #869248).
* Refresh Debian patches.
* Use https in the Homepage field.
* Bump Standards-Version to 4.1.3, no changes needed.
Checksums-Sha1:
c374e845be7d2fbefdaf7066519ddd291860025f 2414 xterm_331-1.dsc
ad8325e4a23cc32be0933b2f38ae11f96797b12a 1286312 xterm_331.orig.tar.gz
b2bd9940b0593f9276f2951d7b66997f4061d1d3 250 xterm_331.orig.tar.gz.asc
8c9d438c458a3fd8e0de6bc464441bad1c104223 101352 xterm_331-1.debian.tar.xz
dd4c4ffa274b073ad5c00d0d551adcc5dc7ea763 8446 xterm_331-1_source.buildinfo
Checksums-Sha256:
bb287af01a118ede5aca036de1bf6a515f5e952aa35685003dbf2e233d42bcbc 2414 xterm_331-1.dsc
9ae856a30fd93046be93952a6898ba47f6f88ad6a988a7c949c4c80d5199ef10 1286312 xterm_331.orig.tar.gz
96c928fd85081624286882ce42781d35f3e514b1eee807b65dacf6808d422a44 250 xterm_331.orig.tar.gz.asc
5d81b7d06318ce5c89fc69015369e5277404edbba7fb859bc7b297e2bcc0498a 101352 xterm_331-1.debian.tar.xz
368be1192471e5a28a4741f73b7e3a12b4ed4487163c26f1d7b0d6ffaf183b71 8446 xterm_331-1_source.buildinfo
Files:
8874f62e04b34d893caee28e79d906a3 2414 x11 optional xterm_331-1.dsc
e08455ab7d4fe8acbb0480dfc8d990f3 1286312 x11 optional xterm_331.orig.tar.gz
fc6db39a424af15ea01f4ce2336773fe 250 x11 optional xterm_331.orig.tar.gz.asc
b865fc197c43879030a521e54550c9de 101352 x11 optional xterm_331-1.debian.tar.xz
c499a9f8cd42910c80f9641e424c9ca1 8446 x11 optional xterm_331-1_source.buildinfo
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEKF8heKgv5Jai5p4QOxBucY1rMawFAlpOX2cACgkQOxBucY1r
MaxHEBAA21iMiV49OE7nGJNHWj/QY/3ZEhRGquwQtGIpLez+csEA83eE+hI7FSyW
u4wcQqdgXwwvTR+MtixRj39X52YebaEjI5hiq/Q0l1BU6WCK2Lzxc6on8HVcNlsE
siCSSX91392EkJqY8x7Fdgu0bu8+ZGfloRug2Ng35I0EYXXuF/pGdgYjUZrya+tI
rtBQPSLHmBrIPgTLRy3xUJoXKwZdpDdGNQwkxirjMlKKuT/5igN/u5B9qW0Lz2ZC
uCob0xF5Y4O2vG/ovabMWJjxhOP2O7IqH4Drtaq4Q4AqfvIq70nA9Kbek2lFXq1g
EGlIcfnvv023KPmNrs0dy5O/us/ndWCvjRjSrsOsRRf+4O/oChqJFjMrGhUwWtyk
JU0wl09A00evZ0h6ugl5Ag0uW9qN2nAqZ95Am0VhIA5lmiJXzqTPflmu9myjKMEW
+vmrf7HhwvzCCkOCG/G53RbvFRAu1rW09BD2/71LA81V2UG2u3p8wDlSW8nqTZzT
KGJ1jXCt8pMvhbHE2rNZkZBuOiC5gNwoStlvUOZWw/Qk7L/sH0nhifOnaY95uvVi
V7Q10Gfp6nusM/dn4g0vNWFGay1k+79H4j/Mk+nHRMfwuthvFZ5ShQKpZGqyPWrd
4w8RuSKCrbWs1KkydeKiBBPYvMBnM4VoXnstoW7JeHjprsKa6pk=
=xUV+
-----END PGP SIGNATURE-----
Control: reopen -1 Control: found -1 331-1 Control: tags -1 - fixed-upstream same number of text lines, and a black line between text lines.
----- Original Message ----- | From: "Vincent Lefevre" <vincent@vinc17.net> | To: dickey@his.com, 880407@bugs.debian.org | Sent: Friday, January 5, 2018 2:30:51 AM | Subject: Bug#880407: #880407 xterm: font issue with FreeType 2.8; should not use the rounded ascender and descender | | Control: reopen -1 | Control: found -1 331-1 | Control: tags -1 - fixed-upstream | | On 2017-12-30 14:53:27 -0500, Thomas Dickey wrote: | > I investigated, found that it is a defect in FreeType. | > None of the comments in | > | > https://savannah.nongnu.org/bugs/?52165 | > | > were helpful (some of the information is incorrect). | > | > I made a workaround for this problem in patch #331. | | It still has the same problems: xterm higher than before for the | same number of text lines, and a black line between text lines. Then you should provide more information allowing this to be reproduced.
I can reproduce this with the default config and: xterm -fa Monospace -fs 10 -xrm "Xft.dpi: 132" (the "Xft.dpi: 132" is important).
----- Original Message ----- | From: "Vincent Lefevre" <vincent@vinc17.net> | To: "Thomas Dickey" <dickey@his.com> | Cc: 880407@bugs.debian.org | Sent: Friday, January 5, 2018 4:09:08 AM | Subject: Re: Bug#880407: #880407 xterm: font issue with FreeType 2.8; should not use the rounded ascender and | descender | | On 2018-01-05 03:59:42 -0500, Thomas Dickey wrote: | > Then you should provide more information allowing this to be | > reproduced. | | I can reproduce this with the default config and: | | xterm -fa Monospace -fs 10 -xrm "Xft.dpi: 132" | | (the "Xft.dpi: 132" is important). I did that (and other values of ".dpi") without seeing any other effect than the one for which I made a workaround: detecting the improper rounding and forcing xterm's internal line-drawing in that case. The line-drawing glyphs were effectively shorter than some of the other characters.
Sorry, I don't understand what you mean. Can you reproduce the problem with that?
only for the case that I made xterm detect/workaround. I added debug-tracing in fontutils.c to show the actual data for the FT_Size_Metrics, as well as loading the glyph to see the pixels. It wasn't a "black" line but rather two raster lines with low values. The rounding change altered the weights from about 12/16 down to 8/16 or 9/16. I added logic to add the weights and turn on xterm's line-drawing when it fell below the threshold. (The trace adds a lot of data; I'd turn it on by the configure with --enable-trace, as well as editing fontutil.c to define OPT_TRACE as 2, and defining DEBUG_XFT). I ran that against all of the fonts from fc-list (several hundred...), found some unrelated issues (lack of error-checking in FT_Load_Char, requiring yet another workaround), but no more than that. In tracing the FT_Size_Metrics, I found no font metrics which Xft could have repaired: all of the damage was done by the change to FreeType2. In particular, tracing the sizes as floating point, none of the values had nonzero fractional parts. As far as I can see, Xft simply gets the result from FreeType2, which has already been rounded.
only for the case that I made xterm detect/workaround. I added debug-tracing in fontutils.c to show the actual data for the FT_Size_Metrics, as well as loading the glyph to see the pixels. It wasn't a "black" line but rather two raster lines with low values. The rounding change altered the weights from about 12/16 down to 8/16 or 9/16. I added logic to add the weights and turn on xterm's line-drawing when it fell below the threshold. (The trace adds a lot of data; I'd turn it on by the configure with --enable-trace, as well as editing fontutil.c to define OPT_TRACE as 2, and defining DEBUG_XFT). I ran that against all of the fonts from fc-list (several hundred...), found some unrelated issues (lack of error-checking in FT_Load_Char, requiring yet another workaround), but no more than that. In tracing the FT_Size_Metrics, I found no font metrics which Xft could have repaired: all of the damage was done by the change to FreeType2. In particular, tracing the sizes as floating point, none of the values had nonzero fractional parts. As far as I can see, Xft simply gets the result from FreeType2, which has already been rounded.
are 23-pixel high instead of 21). I have tried with -xrm "*scaleHeight: 0.9", which gives the same height as before (21 pixels per cell), but this doesn't make these blank lines disappear. Moreover, when I type "É" (E with an acute accent), the accent is no longer visible!
Things have changed again with FreeType 2.9 (libfreetype6 2.9.1-3).
I now get with "DejaVu Sans Mono" and size 10 (-fs 10):
Xft metrics screen->renderFontNorm[0] = 21 (18,5)* advance 11, actual 11
Xft metrics screen->renderFontBold[0] = 21 (18,5)* advance 11, actual 11
Xft metrics screen->renderFontItal[0] = 21 (18,5)* advance 11, actual 11
(it was "20 (16,5)* advance 10, actual 10" with FT 2.8), but the issue
is the same (if not worse).
With size 11 (-fs 11):
Xft metrics screen->renderFontNorm[0] = 23 (19,5)* advance 12, actual 12
Xft metrics screen->renderFontBold[0] = 23 (19,5)* advance 12, actual 12
Xft metrics screen->renderFontItal[0] = 23 (19,5)* advance 12, actual 12
With size 12 (-fs 12):
Xft metrics screen->renderFontNorm[0] = 26 (21,6)* advance 13, actual 13
Xft metrics screen->renderFontBold[0] = 26 (21,6)* advance 13, actual 13
Xft metrics screen->renderFontItal[0] = 26 (21,6)* advance 13, actual 13
The attached patch, which decreasing both ascent and descent by 1 when
height < ascent + descent, avoids this font height issue. I'm not sure
about the "height = font->height = ascent + descent;" line; it doesn't
seem to have any effect.
Note that even with size 12, I need to decrease both ascent and descent
to avoid blank lines.
With this patch, I get the same behavior (window height and rendering)
as with the old FreeType 2.6 in sizes 10 and 12. For size 11, I have
the choice between
- decreasing either ascent or descent, which slightly increases the
window height compared to FreeType 2.6 (I get slight blank lines,
but there was the same issue with FreeType 2.6 with this size),
- decreasing both, which completely solves the blank line issue,
but one may find text lines a bit too close to each other. This
may be a matter of taste, though.
I haven't found any drawback, but I haven't tested other fonts. Note,
however, that the behavior is changed only in the "inconsistent" case
height < ascent + descent.
Perhaps there should be an option about such adjustments...
[...] Sorry, I think that the change was just due to a different Xft.dpi value (as I did the test on a different machine): 132 instead of 88. Anyway, the problem is the same in both cases.
Patch at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880407#100
decide what to do in the "height < ascent + descent" case.
This is a bit like scaleHeight should do, but:
* The new Xft behavior is now opposite as described (for a past
behavior): instead of causing glyphs to be scaled larger than
the bounding boxes, the bounding boxes are now increased by
xterm (in order to match ascent + descent) while the size of
the glyphs has remained the same, which makes windows taller
than needed (thus wasting valuable space on the screen) and
introduces blank lines between line-drawing characters.
* The scaleHeight feature does not work well with this opposite
Xft behavior, e.g. instead of removing a blank line, it removes
some other horizontal line from the glyph.
* The new Xft behavior is a rounding issue: one or two values have
been rounded away from zero instead of toward zero. Thus the
difference with the old behavior is something like 1 or 2 pixels
(along a vertical). So, the configuration value, if any, should
not be a scaling factor, but a value in pixels.
We believe that the bug you reported is fixed in the latest version of
xterm, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 880407@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Sven Joachim <svenjoac@gmx.de> (supplier of updated xterm package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Mon, 20 Jan 2020 18:31:37 +0100
Source: xterm
Architecture: source
Version: 352-1
Distribution: unstable
Urgency: medium
Maintainer: Debian X Strike Force <debian-x@lists.debian.org>
Changed-By: Sven Joachim <svenjoac@gmx.de>
Closes: 880407 931305
Changes:
xterm (352-1) unstable; urgency=medium
.
* New upstream release.
- Adjust fontsize data to handle a minor inconsistency from recent Xft
versions (Closes: #880407, adapted from patch by Vincent Lefevre).
- Add a table to the manual page description of forceBoxChars to alert
the reader to the special characters aside from "line-drawing" which
are drawn directly when this resource is set (Closes: #931305).
* Bump autoconf-dickey build dependency to (>= 2.52+20200111), as per
configure.in.
* Disable the adequate autopkgtest.
* Update years in debian/copyright.
Checksums-Sha1:
6f71d2b7eadaf47e179cc57c896b4d9e8106d61a 2402 xterm_352-1.dsc
9f16861deae113cab4c651c19f9083ecea28ad32 1405420 xterm_352.orig.tar.gz
252f74e66aa5849b74571b19bbab163063d9a85d 265 xterm_352.orig.tar.gz.asc
5835d87bc897c5c0079725765d0b1655360c855d 110764 xterm_352-1.debian.tar.xz
1f2c7e00f5c165153bf75ade0d893ae8d3954da6 7445 xterm_352-1_source.buildinfo
Checksums-Sha256:
f5b9c7028137fe2d46343f0ec775c8d2865ab61b3195efcaf96b29d6ddca0816 2402 xterm_352-1.dsc
7342f8da0e5337ed8c8722b05257d90b1bd2f9b04f3a2d9c10ad05e95c52d57e 1405420 xterm_352.orig.tar.gz
ca6cf42bec73399c408a69a70e0a03ad319915ad259cdaf1b06fbe4c643c2c2f 265 xterm_352.orig.tar.gz.asc
55acc6f19bab209aac4c58af8628bb08c794a91f3f5e92309d3b422bc304c4ee 110764 xterm_352-1.debian.tar.xz
ec7b5c754a39719a4c6eeaf255cf7af81bec5a2a36e6b6d540fd1d9e34f9736e 7445 xterm_352-1_source.buildinfo
Files:
1dfbc1debd957cf0e35b78d08e1801d6 2402 x11 optional xterm_352-1.dsc
9d41798d035976715d532d38327f5e41 1405420 x11 optional xterm_352.orig.tar.gz
469c0ba7d7e7713ee1593f53a4ef8ff8 265 x11 optional xterm_352.orig.tar.gz.asc
6a5002fe9a0a7e7f86b1b16feffe2e6e 110764 x11 optional xterm_352-1.debian.tar.xz
d45dc98fc42e8a0c2190571ccb4294bf 7445 x11 optional xterm_352-1_source.buildinfo
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEKF8heKgv5Jai5p4QOxBucY1rMawFAl4l5fYACgkQOxBucY1r
MayD5w//TdG1on6f62UhF3auhTlVYh3ls6edJbmmJBF3Y1ZpTuuYcQEdz4xXJzn7
Ko3RWuj/sg6wDKMW+JxrYZKjqAn3xHDykv0DHajL9uzC9+cCjtqJlj/b0nRWQxNS
or6+D7ywkaG21q2kMOyQgHKfnjZRWm1o/W/1oG7Jz50LbN4YGLj5Gv9rRcsfwDzk
dftshnJg2lzowv8gl1Rgl84Cj/LAwR1vINSWwvQbzam3Kn58h69LNOYIW7aJ7iq2
/Wv6W1igx1KMSyK+Aqzj5m2ygKRDgtHsUOIwezkTGz3ttjAInH5U0Im1TSCgF5Na
NoVnSnNC0ERmZIrqIKPSkN3YIeYgxx38vaUxWLNrCuFUqRtrpp2vsPfJ6BITZNRm
nKJkN0BiCxfZ8gsBw+LsBfzl1WJCm7t2RjagB7MhLo0sw2x+20ves99zIJVS2jj9
cvNuwIrWkrHwCuIjB5Eg7hb86eZVcpKMDvAl7JScaaAczUZrkQeb86dqCr5jOONq
/B5xDz704wis5NjEZEbBgkmuuK4Sj0pOH0dnECPV9O+EhQhyychM9q/mGW1FzHee
dEpwt6DeEPPawOdQ14SplDOtoYxUCdqDmLdEtpvZNp1Pst+qGhoYguzpcvPNv6H2
algpi5yE8cCfs4h2ThY7QG8e3pwPDeSUUwx0dfFSaH67D0CcEv8=
=sGm3
-----END PGP SIGNATURE-----
Control: reopen -1
Control: found -1 352-1
working with 351-1.
What has been done in fontutils.c is:
@@ -2912,6 +2921,17 @@
ascent = font->ascent;
descent = font->descent;
if (height < ascent + descent) {
+ if ((ascent + descent) > (height + 1)) {
+ /* this happens less than 10% of the time */
+ --ascent;
+ --descent;
+ } else if (ascent > descent) {
+ /* this is the usual case */
+ --ascent;
+ } else {
+ /* this could happen, though rare... */
+ --descent;
+ }
TRACE(("...increase height from %d to %d\n", height, ascent + descent));
height = ascent + descent;
}
I don't know why, but I needed to modify font->ascent, font->descent
and font->height too... well, at least the first two, i.e. using
ascent = --font->ascent;
and
descent = --font->descent;
solves the problem. Alternatively, add "font->" everywhere, and set
ascent = font->ascent;
descent = font->descent;
height = ascent + descent;
only at the end.
Note: for easier readablility, I also suggest to change the test
if (height < ascent + descent) {
to
if ((ascent + descent) > height) {
in order to be similar to the test on the next line.
The change that I used gave me the same result for the font which you mentioned in the bug report. You may be using some different font. Keep in mind that you're rating a 1 or 2 pixel change in the size as "important". Without a screen-magnifier (or printing the data in a log file), others won't notice this problem. However, in reviewing the suggested change, I found that more than 90% of the fonts on my system would be 1 pixel in error. Less than 10% adjusted the height consistently with ascent/descent. Doing that test takes about a half hour on my machine, and makes it unusable during the test. Script is attached, feel free to run it a few times. The part where you're modifying the inputs to the calculation didn't change the result for the font you specified. Just as well (since modifying the inputs will make the results less predictable), but if you can identify the problem which it was intended to fix, you might come up with a workable solution.
The change that I used gave me the same result for the font which you mentioned in the bug report. You may be using some different font. Keep in mind that you're rating a 1 or 2 pixel change in the size as "important". Without a screen-magnifier (or printing the data in a log file), others won't notice this problem. However, in reviewing the suggested change, I found that more than 90% of the fonts on my system would be 1 pixel in error. Less than 10% adjusted the height consistently with ascent/descent. Doing that test takes about a half hour on my machine, and makes it unusable during the test. Script is attached, feel free to run it a few times. The part where you're modifying the inputs to the calculation didn't change the result for the font you specified. Just as well (since modifying the inputs will make the results less predictable), but if you can identify the problem which it was intended to fix, you might come up with a workable solution.
I'm using the following settings: /usr/bin/xterm -xrm "Xft.dpi: 132" -xrm "XTerm*faceName: DejaVu Sans Mono" -xrm "XTerm*faceSize: 10" under Debian/unstable. I don't use a screen magnifier, and the difference is very visible. Perhaps because I've been using this config for several years. It is also visible after login since with the wrong height, the xterm windows that are placed by default appear partly off-screen. I get many width issues, but perhaps because this is not for western fonts. The only other alternative would be to make things configurable, so that the user could adjust the parameters according to the choice of the font and his wishes.
I don't see this in Debian testing. In Debian testing (see attached) the appearance is identical. Given when you opened the bug report, there's no reason for me to investigate Debian unstable.
I don't see this in Debian testing. In Debian testing (see attached) the appearance is identical. Given when you opened the bug report, there's no reason for me to investigate Debian unstable.