unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#39554: 27.0.50; cairo not composing sequences
@ 2020-02-10 20:53 James Cloos
  2020-02-11  3:26 ` Eli Zaretskii
  2020-02-11  3:27 ` Eli Zaretskii
  0 siblings, 2 replies; 15+ messages in thread
From: James Cloos @ 2020-02-10 20:53 UTC (permalink / raw)
  To: 39554

Sequences like 0̸ fail to display composed in master --with-cairo but do
when usin xft.

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.

The ftcrhb: code needs to display the combining chars over the base
chars like the earlier code does.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#39554: 27.0.50; cairo not composing sequences
  2020-02-10 20:53 bug#39554: 27.0.50; cairo not composing sequences James Cloos
@ 2020-02-11  3:26 ` Eli Zaretskii
       [not found]   ` <m3d0ajd4fq.fsf@carbon.jhcloos.org>
  2020-02-11  3:27 ` Eli Zaretskii
  1 sibling, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2020-02-11  3:26 UTC (permalink / raw)
  To: James Cloos; +Cc: 39554

> From: James Cloos <cloos@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.





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#39554: 27.0.50; cairo not composing sequences
  2020-02-10 20:53 bug#39554: 27.0.50; cairo not composing sequences James Cloos
  2020-02-11  3:26 ` Eli Zaretskii
@ 2020-02-11  3:27 ` Eli Zaretskii
  2020-02-12 18:54   ` James Cloos
  1 sibling, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2020-02-11  3:27 UTC (permalink / raw)
  To: James Cloos; +Cc: 39554

> From: James Cloos <cloos@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.

And one more thing: if your master branch is at version 27.0.50, then
it is quite old.  Please try the latest master or the emacs-27 branch.





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#39554: 27.0.50; cairo not composing sequences
  2020-02-11  3:27 ` Eli Zaretskii
@ 2020-02-12 18:54   ` James Cloos
  0 siblings, 0 replies; 15+ messages in thread
From: James Cloos @ 2020-02-12 18:54 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 39554

>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:

EZ> And one more thing: if your master branch is at version 27.0.50, then
EZ> it is quite old.  Please try the latest master or the emacs-27 branch.

as i noted in my followup, master this month (at least) breaks gnus, so i
must still use december's compile for mail.  but the tests were on master
of the day i sent them.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#39554: 27.0.50; cairo not composing sequences
       [not found]   ` <m3d0ajd4fq.fsf@carbon.jhcloos.org>
@ 2020-02-12 19:59     ` Eli Zaretskii
  2020-02-13 20:16       ` James Cloos
  0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2020-02-12 19:59 UTC (permalink / raw)
  To: James Cloos; +Cc: 39554

[Please keep the bug number on the CC list.]

> From: James Cloos <cloos@jhcloos.com>
> Date: Wed, 12 Feb 2020 13:51:53 -0500
> 
> >>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Sequences like 0̸ fail to display composed in master --with-cairo but do
> >> when usin xft.
> 
> EZ> Please show a complete reproducing recipe for this problem.
> 
> The 0̸ in thequoted line is one.

Sorry, I failed to realize that ̸ was a combining accent, not an ASCII
slash.

In an Emacs built with HarfBuzz on MS-Windows, if I use a font that
has support for ̸, I do see these two characters composed into a single
glyph whose width is as that of a single character.  But if I use
DejaVu Sans Mono, I indeed see a double-width grapheme cluster.  So I
think this might be related to font selection somehow.  Can you try
different monospaced fonts and see if the results in the Cairo build
are better with other fonts?

> EZ> This means that the font backend couldn't produce a single glyph for
> EZ> the character combination, for some reason, so it displayed the
> EZ> original glyphs as a single grapheme cluster.  IOW, character
> EZ> composition did work, it just didn't find a precomposed glyph in the
> EZ> font, or maybe the precomposed glyph was rejected for some reason.
> 
> It is not supposed to be looking for precomposed glyphs.  It is supposed
> to be rendering each combining glyph on top of the base glyph.  Just
> like xft does.

The way character composition works in Emacs, we first ask the font
for precomposed glyphs, and display them if the font has them.  If
that fails, then we combine the separate glyphs ourselves.  See
compose-gstring-for-graphic.





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#39554: 27.0.50; cairo not composing sequences
  2020-02-12 19:59     ` Eli Zaretskii
@ 2020-02-13 20:16       ` James Cloos
  2020-02-13 20:24         ` Eli Zaretskii
  0 siblings, 1 reply; 15+ messages in thread
From: James Cloos @ 2020-02-13 20:16 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 39554

It does work correctly when i turn on variable-pitch-mode, which here is
set to use DejaVu Serif.

But xft does fine with DejaVu Sans Mono.

This bug remains a regression and requires a fix.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#39554: 27.0.50; cairo not composing sequences
  2020-02-13 20:16       ` James Cloos
@ 2020-02-13 20:24         ` Eli Zaretskii
  2020-02-14  0:58           ` James Cloos
  0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2020-02-13 20:24 UTC (permalink / raw)
  To: James Cloos; +Cc: 39554

> From: James Cloos <cloos@jhcloos.com>
> Cc: 39554@debbugs.gnu.org
> Date: Thu, 13 Feb 2020 15:16:39 -0500
> 
> It does work correctly when i turn on variable-pitch-mode, which here is
> set to use DejaVu Serif.
> 
> But xft does fine with DejaVu Sans Mono.
> 
> This bug remains a regression and requires a fix.

I don't think I agree.  This font has problems with combining accents,
see this discussion:

  https://lists.freedesktop.org/archives/harfbuzz/2019-August/007422.html





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#39554: 27.0.50; cairo not composing sequences
  2020-02-13 20:24         ` Eli Zaretskii
@ 2020-02-14  0:58           ` James Cloos
  2020-02-14  1:07             ` YAMAMOTO Mitsuharu
  0 siblings, 1 reply; 15+ messages in thread
From: James Cloos @ 2020-02-14  0:58 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 39554

>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:

EZ> I don't think I agree.  This font has problems with combining accents,

if xft is to be depricated in favour of cairo, then anything which works
in xft but fails in cairo is be definition a regression.

and ir works perfectly irrespective of font with xft.

so the fact that --with-cairo gets it wrong is indisputably a regression
in emacs on x11.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#39554: 27.0.50; cairo not composing sequences
  2020-02-14  0:58           ` James Cloos
@ 2020-02-14  1:07             ` YAMAMOTO Mitsuharu
  2020-02-14  4:50               ` James Cloos
  0 siblings, 1 reply; 15+ messages in thread
From: YAMAMOTO Mitsuharu @ 2020-02-14  1:07 UTC (permalink / raw)
  To: James Cloos; +Cc: 39554

On Fri, 14 Feb 2020 09:58:05 +0900,
James Cloos wrote:
> 
> >>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> EZ> I don't think I agree.  This font has problems with combining accents,
> 
> if xft is to be depricated in favour of cairo, then anything which works
> in xft but fails in cairo is be definition a regression.
> 
> and ir works perfectly irrespective of font with xft.
> 
> so the fact that --with-cairo gets it wrong is indisputably a regression
> in emacs on x11.

I guess the difference comes from with vs. without HarfBuzz rather
than cairo vs. xft.  Could you check if that is the case on your
environment?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#39554: 27.0.50; cairo not composing sequences
  2020-02-14  1:07             ` YAMAMOTO Mitsuharu
@ 2020-02-14  4:50               ` James Cloos
  2020-02-14  8:44                 ` Robert Pluim
  0 siblings, 1 reply; 15+ messages in thread
From: James Cloos @ 2020-02-14  4:50 UTC (permalink / raw)
  To: YAMAMOTO Mitsuharu; +Cc: 39554

>>>>> "YM" == YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

YM> I guess the difference comes from with vs. without HarfBuzz rather
YM> than cairo vs. xft.

makes sense.

YM> Could you check if that is the case on your environment?

all i know is that w/o cairo, describe-char reports:

    xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-22-*-*-*-m-0-iso10646-1
by these glyphs:
  [0 1 48 19 13 0 13 17 1 nil]
  [0 1 824 704 0 0 13 17 1 [-13 0 0]]

and w/ cairo it reports:

    ftcrhb:-unknown-DejaVu Serif-normal-normal-normal-*-22-*-*-*-*-0-iso10646-1
by these glyphs:
  [0 1 48 19 14 1 12 16 0 nil]
  [0 1 824 741 0 -17 -1 18 1 nil]

I presume that the '0 0 13 17 1 [-13 0 0]' vs '0 -17 -1 18 1 nil'
represents the failed overlay.

and that ftcrhb expands to freetype-cairo-harfbuzz.

it is a pain to dig deep w/o the left hand, but i can try w/ some
leading suggestions.  i haven't looked at the src since before my last
stroke, much less since this one.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#39554: 27.0.50; cairo not composing sequences
  2020-02-14  4:50               ` James Cloos
@ 2020-02-14  8:44                 ` Robert Pluim
  2022-02-10  7:25                   ` Lars Ingebrigtsen
  0 siblings, 1 reply; 15+ messages in thread
From: Robert Pluim @ 2020-02-14  8:44 UTC (permalink / raw)
  To: James Cloos; +Cc: 39554

>>>>> On Thu, 13 Feb 2020 23:50:51 -0500, James Cloos <cloos@jhcloos.com> said:

>>>>> "YM" == YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
    YM> I guess the difference comes from with vs. without HarfBuzz rather
    YM> than cairo vs. xft.

    James> makes sense.

    YM> Could you check if that is the case on your environment?

    James> all i know is that w/o cairo, describe-char reports:

    James>     xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-22-*-*-*-m-0-iso10646-1
    James> by these glyphs:
    James>   [0 1 48 19 13 0 13 17 1 nil]
    James>   [0 1 824 704 0 0 13 17 1 [-13 0 0]]

Thatʼs XFT not using harfbuzz

    James> and w/ cairo it reports:

    James>     ftcrhb:-unknown-DejaVu Serif-normal-normal-normal-*-22-*-*-*-*-0-iso10646-1
    James> by these glyphs:
    James>   [0 1 48 19 14 1 12 16 0 nil]
    James>   [0 1 824 741 0 -17 -1 18 1 nil]

And this is Cairo using harfbuzz.

    James> I presume that the '0 0 13 17 1 [-13 0 0]' vs '0 -17 -1 18 1 nil'
    James> represents the failed overlay.

    James> and that ftcrhb expands to freetype-cairo-harfbuzz.

    James> it is a pain to dig deep w/o the left hand, but i can try w/ some
    James> leading suggestions.  i haven't looked at the src since before my last
    James> stroke, much less since this one.

I donʼt see the issue with DejaVu Sans Mono in an Xft build, and
can reproduce it in an Xft+Harfbuzz build, so Cairo is not to blame
here.

Robert





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#39554: 27.0.50; cairo not composing sequences
  2020-02-14  8:44                 ` Robert Pluim
@ 2022-02-10  7:25                   ` Lars Ingebrigtsen
  2022-02-11 20:40                     ` James Cloos
  2022-02-11 20:48                     ` James Cloos
  0 siblings, 2 replies; 15+ messages in thread
From: Lars Ingebrigtsen @ 2022-02-10  7:25 UTC (permalink / raw)
  To: Robert Pluim; +Cc: 39554, James Cloos

Robert Pluim <rpluim@gmail.com> writes:

> I donʼt see the issue with DejaVu Sans Mono in an Xft build, and
> can reproduce it in an Xft+Harfbuzz build, so Cairo is not to blame
> here.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

This looks very similar to the problem in bug#44784, and the issue there
was that Emacs was choosing a font for ̷ that's not the same as the font
used for 0 -- in that case Emacs doesn't combine chars.  So it's a
matter of choosing a font that has wider coverage, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#39554: 27.0.50; cairo not composing sequences
  2022-02-10  7:25                   ` Lars Ingebrigtsen
@ 2022-02-11 20:40                     ` James Cloos
  2022-02-12  6:50                       ` Eli Zaretskii
  2022-02-11 20:48                     ` James Cloos
  1 sibling, 1 reply; 15+ messages in thread
From: James Cloos @ 2022-02-11 20:40 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Robert Pluim, 39554

>>>>> "RP" == Robert Pluim <rpluim@gmail.com> writes:
>>>>> "LI" == Lars Ingebrigtsen <larsi@gnus.org> writes:

RP>> I donʼt see the issue with DejaVu Sans Mono in an Xft build, and can
RP>> reproduce it in an Xft+Harfbuzz build, so Cairo is not to blame here.

LI> in that case Emacs doesn't combine chars.  So it's a
LI> matter of choosing a font that has wider coverage, I think.

no.

in this case one font is used.

w/ m17lib+libotf the two glyphs are combined and displayed one atop the other
(ie, z-axis stacking).

w/ harfbuzz the two glyphs still are combined but displayed next to each other.
(ie, x-axis stacking).

the first way is the correct way.  the latter is a bug.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6







^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#39554: 27.0.50; cairo not composing sequences
  2022-02-10  7:25                   ` Lars Ingebrigtsen
  2022-02-11 20:40                     ` James Cloos
@ 2022-02-11 20:48                     ` James Cloos
  1 sibling, 0 replies; 15+ messages in thread
From: James Cloos @ 2022-02-11 20:48 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Robert Pluim, 39554

Oh, i forgot to add:

the Noto fonts (at least Serif and Sans Mono)  also screws up 0̸.

but differently than dejavu sans mono does.

in noto there is a (very) tiny bit of overlap.  It looks like a percent
w/o the lower-right circle.  and the combining slash overlaps the
subsequent glyph.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6







^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#39554: 27.0.50; cairo not composing sequences
  2022-02-11 20:40                     ` James Cloos
@ 2022-02-12  6:50                       ` Eli Zaretskii
  0 siblings, 0 replies; 15+ messages in thread
From: Eli Zaretskii @ 2022-02-12  6:50 UTC (permalink / raw)
  To: James Cloos; +Cc: larsi, rpluim, 39554

> From: James Cloos <cloos@jhcloos.com>
> Date: Fri, 11 Feb 2022 15:40:19 -0500
> Cc: Robert Pluim <rpluim@gmail.com>, 39554@debbugs.gnu.org
> 
> in this case one font is used.
> 
> w/ m17lib+libotf the two glyphs are combined and displayed one atop the other
> (ie, z-axis stacking).
> 
> w/ harfbuzz the two glyphs still are combined but displayed next to each other.
> (ie, x-axis stacking).
> 
> the first way is the correct way.  the latter is a bug.

_If_ it's a bug, it's either in the font or in HarfBuzz.  Not in Emacs.





^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2022-02-12  6:50 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-02-10 20:53 bug#39554: 27.0.50; cairo not composing sequences James Cloos
2020-02-11  3:26 ` Eli Zaretskii
     [not found]   ` <m3d0ajd4fq.fsf@carbon.jhcloos.org>
2020-02-12 19:59     ` Eli Zaretskii
2020-02-13 20:16       ` James Cloos
2020-02-13 20:24         ` Eli Zaretskii
2020-02-14  0:58           ` James Cloos
2020-02-14  1:07             ` YAMAMOTO Mitsuharu
2020-02-14  4:50               ` James Cloos
2020-02-14  8:44                 ` Robert Pluim
2022-02-10  7:25                   ` Lars Ingebrigtsen
2022-02-11 20:40                     ` James Cloos
2022-02-12  6:50                       ` Eli Zaretskii
2022-02-11 20:48                     ` James Cloos
2020-02-11  3:27 ` Eli Zaretskii
2020-02-12 18:54   ` James Cloos

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).