GNU bug report logs -
#29078
25.2; font issue with FreeType 2.8; should not use the rounded ascender and descender
Previous Next
Full log
View this message in rfc822 format
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 29078 <at> debbugs.gnu.org
> Date: Mon, 18 Nov 2019 21:31:43 +0100
>
> Vincent Lefevre <vincent <at> vinc17.net> writes:
>
> > On 2019-11-18 19:32:41 +0100, Lars Ingebrigtsen wrote:
> >> Using
> >>
> >> ftcrhb:-PfEd-DejaVu Sans
> >> Mono-normal-normal-normal-*-25-*-*-*-m-0-iso10646-1 (#x957)
> >
> > Under Debian/unstable, I don't get it either. Neither with
> >
> > ftcrhb:-PfEd-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1
> >
> > But the bug occurs with
> >
> > ftcrhb:-PfEd-DejaVu Sans Mono-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1
> >
> > That's for the rendering. I don't know whether the cell height is
> > honored in all these cases.
>
> Ah, yes. If I say
>
> emacs -Q -fn "DejaVu Sans Mono:size=30"
>
> and vary the size, I get the gaps in the lines for some sizes (like 23)
> but not others (like 25).
Strangely, I see small (1- or 2-pixel) gaps for Courier New on
MS-Windows, and only for a couple of size values. Moreover, with
DejaVu Sans Mono, I don't see any gaps for all sizes between 9 and 30.
FWIW, the font-related APIs on MS-Windows report glyph metrics as
integer values, so Emacs doesn't round anywhere. So either MS-Windows
does a better job with that font (unlikely) or there's something else
at work here.
I guess we will have to wait until someone tells us what to do here.
This bug report was last modified 5 years and 270 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.