Re: Face issue -- possible bug

[Eli Zaretskii <eliz@gnu.org>]

> From: Joost Kremers <joostkremers@fastmail.fm>
> Cc: emacs-devel@gnu.org
> Date: Tue, 17 Jul 2018 09:56:14 +0200
> 
> > What does Emacs say if you go to the character and type "C-u C-x 
> > =",
> > when the problematic font is used?
> 
> Well d'uh, I could have thought of that myself... Anyway, with 
> Linux Libertine O (which displays the character incorrectly), `C-u 
> C-x =` gives:
> 
> ==============================
> 
>              position: 182 of 268 (68%), column: 5
>             character: n (displayed as n) (codepoint 110, #o156, 
>             #x6e)
>     preferred charset: ascii (ASCII (ISO646 IRV))
> code point in charset: 0x6E
>                script: latin
>                syntax: w 	which means: word
>              category: .:Base, L:Left-to-right (strong), a:ASCII, 
>              l:Latin, r:Roman
>              to input: type "C-x 8 RET 6e" or "C-x 8 RET LATIN 
>              SMALL LETTER N"
>           buffer code: #x6E
>             file code: #x6E (encoded by coding system utf-8-unix)
>               display: composed to form "n̩" (see below)
> 
> Composed with the following character(s) "̩" using this font:
>   xft:-PfEd-Linux Libertine 
>   O-normal-normal-normal-*-21-*-*-*-*-0-iso10646-1
> by these glyphs:
>   [0 1 0 2420 13 0 13 10 1 nil]
>   [0 1 809 745 0 -9 -6 -1 5 [-2 -1 0]]
> 
> Character code properties: customize what to show
>   name: LATIN SMALL LETTER N
>   general-category: Ll (Letter, Lowercase)
>   decomposition: (110) ('n')
> 
> There are text properties here:
>   fontified            t
>   wrap-prefix          ""
> 
> ==============================
> 
> And with DejaVu Sans Mono (displaying the character correctly):
> 
> ==============================
> 
> 
>              position: 182 of 268 (68%), column: 5
>             character: n (displayed as n) (codepoint 110, #o156, 
>             #x6e)
>     preferred charset: ascii (ASCII (ISO646 IRV))
> code point in charset: 0x6E
>                script: latin
>                syntax: w 	which means: word
>              category: .:Base, L:Left-to-right (strong), a:ASCII, 
>              l:Latin, r:Roman
>              to input: type "C-x 8 RET 6e" or "C-x 8 RET LATIN 
>              SMALL LETTER N"
>           buffer code: #x6E
>             file code: #x6E (encoded by coding system utf-8-unix)
>               display: composed to form "n̩" (see below)
> 
> Composed with the following character(s) "̩" using this font:
>   xft:-PfEd-DejaVu Sans 
>   Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1
> by these glyphs:
>   [0 1 110 81 9 1 8 8 5 nil]
>   [0 1 809 689 0 4 6 -1 5 [-10 -1 0]]
> 
> Character code properties: customize what to show
>   name: LATIN SMALL LETTER N
>   general-category: Ll (Letter, Lowercase)
>   decomposition: (110) ('n')
> 
> There are text properties here:
>   fontified            t
>   wrap-prefix          ""
> 
> ==============================
> 
> The only difference I notice is with the numbers following "by 
> these glyphs", but I have no idea what those numbers mean.

(If you _really_ want to know what they mean, see the description of
GLYPH in the doc string of composition-get-gstring.)

Note how the first glyph of the composition data with the "bad" font
has zero as its 3rd component, whereas the "good" font has 110 there,
which is the codepoint of 'n'.  Having zero there is not really
normal, I think.

I downloaded the Libertine O font and tried that on MS-Windows.  I
don't see this problem there with that font.  So based on that, and on
the fact that another font displays this combination correctly on your
system, my primary suspect is neither Emacs nor the font, but the
shaping engine we use to compose characters.  On GNU/Linux we use
libm17n-flt as the shaping engine, so the first step is to make sure
you have its latest version installed.  I think the latest version is
only available in the CVS repository, which you can access through
Savannah:

   http://savannah.nongnu.org/projects/m17n/

If installing the latest version doesn't help, it might be a bug in
libm17n-flt, so I'm CC'ing Handa-san who might be able to help fix
this.