On 2020-01-20 20:06:51 -0500, Thomas Dickey wrote: > 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.
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. > 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. 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. > 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. I get many width issues, but perhaps because this is not for western fonts. > 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 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. -- 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)
