GNU bug report logs - #50951
28.0.50; Urdu text is not displayed correctly

Previous Next

Package: emacs;

Reported by: Rah Guzar <aikrahguzar <at> gmail.com>

Date: Fri, 1 Oct 2021 20:19:01 UTC

Severity: normal

Tags: moreinfo

Found in version 28.0.50

Done: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Visuwesh <visuweshm <at> gmail.com>
To: 50951 <at> debbugs.gnu.org
Cc: rahguzar <at> zohomail.eu, eliz <at> gnu.org, larsi <at> gnus.org
Subject: bug#50951: 28.0.50; Urdu text is not displayed correctly
Date: Tue, 06 Sep 2022 09:56:09 +0530
[திங்கள் செப்டம்பர் 05, 2022] Rah Guzar via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:

> Hi Eli,
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> It is unclear to me why this conclusion.  Emacs uses HarfBuzz, and the
>> only factor that could affect that, apart from selecting the font, is
>> the setting of the current-iso639-language variable, which AFAIR
>> Rahguzar tried setting with no success.
>
> At your suggestion, I tried hb-view and it renders Noto Nastaliq fine.
> Similarly Libre Office which also uses harfbuzz as far as I understand,
> also renders it fine. Which is why I said that the problem is limited to
> emacs. My understanding of font rendering is non-existent but visually
> what seems to happen is that emacs displays all the individual atoms
> (glyphs?) but it doesn't know how to position them relative to each
> other so they overlap and obscure each other. This positioning is
> especially tricky in Nastaliq fonts since it can require moving all of
> up, down, left, right. The big fonts that emacs render correctly, take
> care of this by prepackaging all these combinations of characters that
> require anything other than right to left movement as separate shapes.

To my ears, this sounds an awful lot like bug#54646 where I faced
similar font clipping issues with Noto Serif Tamil (and other Tamil
fonts).  The issues with clipping and other glyph placement issues went
away when I used the Xft+Harfbuzz backend, perhaps that might fix your
issue as well?  But you might trade crisp font rendering for a slightly
blurry one though; in my case it was a trade-off I had to make.




This bug report was last modified 2 years and 241 days ago.

Previous Next


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