unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Richard Wordingham <richard.wordingham@ntlworld.com>
Cc: 20140@debbugs.gnu.org, handa@gnu.org, larsi@gnus.org
Subject: bug#20140: 24.4; M17n shaper output rejected
Date: Mon, 07 Feb 2022 16:04:35 +0200	[thread overview]
Message-ID: <83czjyydqk.fsf@gnu.org> (raw)
In-Reply-To: <20220206220958.5a4d8ffe@JRWUBU2> (message from Richard Wordingham on Sun, 6 Feb 2022 22:09:58 +0000)

> Date: Sun, 6 Feb 2022 22:09:58 +0000
> From: Richard Wordingham <richard.wordingham@ntlworld.com>
> Cc: larsi@gnus.org, 20140@debbugs.gnu.org, Kenichi Handa <handa@gnu.org>
> 
> > > Sad to see that Khaled Hosny's suggestion not to use composition
> > > rules seems not to have been taken.  
> > 
> > You mean, to pass all the text via HarfBuzz instead?  That makes the
> > Emacs redisplay painfully slow, and would require a complete redesign
> > of how we render text to be bearable.  So as long as such a redesign
> > is not available, we cannot use that advice.
> 
> Except for Malayalam!  (Subexpression XX* in indian.el at the moment.)

(That was changed lately.  But it is a tangent.)

> > > They're complicated by the facts that the 'regular expressions' are
> > > not interpreted as regular expressions and they are not interpreted
> > > as closed under canonical equivalence.  I therefore calculate the
> > > regular expression.  
> > 
> > I'm not sure I understand the issue: what you do seems to be very
> > similar to what we do for the Indic scripts in indian.el, so what kind
> > of complications are you talking about here?
> 
> Well, those rules themselves are a bit odd.  Why are you composing
> single clusters?  Why are you breaking clusters where Microsoft
> imitators are likely to insert dotted circles?

I'm not sure this is what I asked.  I asked why you think this way of
defining patterns for composition rules is in any way exceptional.  It
seems pretty much boilerplate to me.

> The best sources are the regular expressions in the proposals, but they
> missed out the combination of tone mark and final consonant signs.

Can you be more specific about those proposals?  Any specific
pointers?

Also, does this mean there's currently no widely accepted agreement
regarding Tai Tham shaping?  What do native readers of that script
expect?

> What do you mean by 'shaping'?

Whatever is needed to produce correct display from a sequence of
codepoints in a given script.

> > At least for the dotted circle case, Emacs has a general composition
> > rule; see compose-gstring-for-dotted-circle and the corresponding rule
> > in composite.c.  So I'm not sure we need anything specific to Tai Tham
> > there.
> 
> Does the 3-character Khmer sequence "◌្ក" <U+25CC, U+17D2, U+1780> work
> in Version 28?  It doesn't in Version 26.3.  It should look like a
> dotted circle with the lower part of ក្ក below it.  In Version 26.3, I
> don't even get the consonant U+1780 subscripted!

No, it doesn't produce what you want (though the 2nd and the 3rd
characters do combine), but that's not surprising: the general rules
for U+25CC that we have cover only a single combining mark after it:

  (aset composition-function-table #x25CC
	`([,(purecopy ".\\c^") 0 compose-gstring-for-dotted-circle]))

So a sequence of more than one character after U+25CC needs an
explicit rule to work.  What is the rule in this case?  (And what does
Khmer have to do with the question I asked, which is about Tai Tham?)

> With HarfBuzz, if you don't compose U+25CC with the following mark, you
> are very likely to get two dotted circles - are you deliberately
> deleting one?

No.  And I don't get 2 dotted circles with the above in Emacs 28 with
HarfBuzz.

Anyway, Khmer is a separate issue.





  reply	other threads:[~2022-02-07 14:04 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-18 22:20 bug#20140: 24.4; M17n shaper output rejected Richard Wordingham
2015-03-19  3:43 ` Eli Zaretskii
2015-03-21  8:33 ` K. Handa
2015-03-21 17:20   ` Wolfgang Jenkner
2015-03-21 17:58   ` Richard Wordingham
2015-03-21 18:26     ` Eli Zaretskii
2015-03-25 14:25     ` K. Handa
2015-03-25 21:45       ` Richard Wordingham
2015-04-05 19:48       ` Richard Wordingham
2022-02-03 21:21 ` Lars Ingebrigtsen
2022-02-04  7:37   ` Eli Zaretskii
2022-02-05 22:52     ` Richard Wordingham via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-06  8:11       ` Eli Zaretskii
2022-02-06 22:09         ` Richard Wordingham via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-07 14:04           ` Eli Zaretskii [this message]
2022-02-07 23:38             ` Richard Wordingham via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-08 22:13         ` Richard Wordingham via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-12 18:54           ` Eli Zaretskii
2022-02-13 16:04       ` Eli Zaretskii
2022-02-13 20:53         ` Richard Wordingham via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-14 13:19           ` Eli Zaretskii
2022-02-14 22:14             ` Richard Wordingham via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-15  1:27               ` Richard Wordingham via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-16 15:13                 ` Eli Zaretskii
2022-02-16 15:12               ` Eli Zaretskii
2022-02-16 15:11           ` Eli Zaretskii
2022-02-13 19:49       ` Eli Zaretskii
2022-02-13 21:11         ` Richard Wordingham via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-14 13:26           ` Eli Zaretskii
2022-02-14 23:26             ` Richard Wordingham via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-15 14:40               ` Eli Zaretskii
2022-02-15 21:06                 ` Richard Wordingham via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-16 13:15                   ` Eli Zaretskii
2022-02-16 19:01                     ` Richard Wordingham via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-16 19:20                       ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83czjyydqk.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=20140@debbugs.gnu.org \
    --cc=handa@gnu.org \
    --cc=larsi@gnus.org \
    --cc=richard.wordingham@ntlworld.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).