GNU bug report logs - #44664
28.0.50; troubles with some chars in term

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: schwab <at> linux-m68k.org, bugs <at> gnu.support, 44664 <at> debbugs.gnu.org
Subject: bug#44664: 28.0.50; troubles with some chars in term
Date: Sun, 29 Nov 2020 17:46:25 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: schwab <at> linux-m68k.org,  bugs <at> gnu.support,  44664 <at> debbugs.gnu.org
> Date: Sun, 29 Nov 2020 10:58:16 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> You mean they are so wide that compressing them will make them illegible?
> >
> > I don't know how to "compress" glyphs, actually.  I hoped that we can
> > get away with just "padding", which boils down to enlarging their
> > width metrics.  But if we need to make the width significantly smaller
> > than the font glyph font says, I don't know what would be the effect
> > of that, and I have no idea how to "shrink" a glyph on display.
> 
> Oh, I thought you said that we shrink some glyphs vertically already?

No, we just override the metrics, which claims unreasonably large
height.  The glyphs themselves are not as tall as the metrics says.

> I imagined shrinking the width of a glyph would mean just throwing away
> some vertical lines, or specify a transformation matrix, or something.
> (I have not looked at the code, as you can tell.)

We can easily clip the glyph, yes.  I don't know how legible will the
result be.  Transformation matrices is not something I'd love to use
here.

Eventually, we need to see how many characters, if any, exhibit this
problem.  Maybe the issue is minor.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.