GNU bug report logs - #39554
27.0.50; cairo not composing sequences

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: James Cloos <cloos <at> jhcloos.com>
Cc: 39554 <at> debbugs.gnu.org
Subject: bug#39554: 27.0.50; cairo not composing sequences
Date: Tue, 11 Feb 2020 05:26:19 +0200

> From: James Cloos <cloos <at> jhcloos.com>
> Date: Mon, 10 Feb 2020 15:53:32 -0500
> 
> Sequences like 0̸ fail to display composed in master --with-cairo but do
> when usin xft.

Please show a complete reproducing recipe for this problem.

> In a version w/o cairo I get:
> 
> Composed with the following character(s) "̸" using this font:
>   xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-22-*-*-*-m-0-iso10646-1
> by these glyphs:
> 
> and the single char takes up the same width as any ascii letter.
> 
> W/ cair i get:
> 
> Composed with the following character(s) "̸" using this font:
>   ftcrhb:-unknown-DejaVu Sans Mono-normal-normal-normal-*-22-*-*-*-m-0-iso10646-1
> by these glyphs:
>   [0 1 48 19 13 1 12 16 0 nil]
>   [0 1 824 704 13 0 13 17 1 nil]
> 
> and the single char takes twice the expected width, but still works as a
> sing;e char.  OTOH, in the *Help* buffer '"̸"' is three separate chars.
> Buth with xft '"̸"' displays with the slash overlaying the first ".
> As it should.

This means that the font backend couldn't produce a single glyph for
the character combination, for some reason, so it displayed the
original glyphs as a single grapheme cluster.  IOW, character
composition did work, it just didn't find a precomposed glyph in the
font, or maybe the precomposed glyph was rejected for some reason.

We need the detailed use case to investigate.

Please also tell what is your version of HarfBuzz, in case this
matters.

And in the XFT case, what was the shaping engine? was it libflt?

Thanks.

Previous Next

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