bug#50951: 28.0.50; Urdu text is not displayed correctly

[Visuwesh <visuweshm@gmail.com>]

[திங்கள் செப்டம்பர் 05, 2022] Rah Guzar via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:

> Hi Eli,
> Eli Zaretskii <eliz@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.