GNU bug report logs - #20222
25.0.50; Wrong horizontal position of combining characters

Previous Next

Full log

Message #17 received at 20222 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 20222 <at> debbugs.gnu.org, schwab <at> linux-m68k.org, orivej <at> gmx.fr
Subject: Re: bug#20222: 25.0.50;
 Wrong horizontal position of combining characters
Date: Wed, 15 Jan 2020 18:21:28 +0200

> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Wed, 15 Jan 2020 06:21:31 +0100
> Cc: 20222 <at> debbugs.gnu.org, Andreas Schwab <schwab <at> linux-m68k.org>
> 
> Orivej Desh <orivej <at> gmx.fr> writes:
> 
> >> >  --with-xft --without-libotf --without-m17n-flt --with-x-toolkit=gtk2
> >> 
> >> What happens if you build with libotf?
> >
> > Thanks! I rebuilt Emacs with m17n and libotf, and now Ezra SIL and Linux
> > Libertine look perfect. (But only if multiple composing characters are
> > entered in some order that seems logical: 05E9 shin + 05C2 sin dot +
> > 05B9 holam compose into one character, yet shin + holam does not compose
> > with the following sin dot.) Cardo font, on the other hand, became even
> > more broken, with more composing characters shifted to the right. (I
> > think it was m17n that helped, because only Linux Libertine is available
> > in OTF, and also rendering of TTF variant of Linux Libertine got fixed.)
> 
> It seems to me that the original issue is solved by building with
> libotf.  Is there anything more to do here?  If I don't hear anything
> else within a couple of weeks, I'll assume this is fixed and close the
> bug.

I think this bug doesn't exist with HarfBuzz, because it can handle
these in any order.

Previous Next

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