From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Amit Aronovitch Newsgroups: gmane.emacs.bidi,gmane.emacs.devel Subject: Re: Re: Arabic support Date: Fri, 3 Sep 2010 17:32:33 +0300 Message-ID: References: <83bp8oml9c.fsf@gnu.org> <83pqwvhsbm.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0691555472==" X-Trace: dough.gmane.org 1283524372 31995 80.91.229.12 (3 Sep 2010 14:32:52 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 3 Sep 2010 14:32:52 +0000 (UTC) Cc: emacs-bidi@gnu.org, emacs-devel@gnu.org, jasonr@gnu.org, Kenichi Handa To: Eli Zaretskii Original-X-From: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Fri Sep 03 16:32:49 2010 Return-path: Envelope-to: gnu-emacs-bidi@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OrXJv-0006rU-3n for gnu-emacs-bidi@m.gmane.org; Fri, 03 Sep 2010 16:32:47 +0200 Original-Received: from localhost ([127.0.0.1]:58737 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OrXJt-0006oI-Tg for gnu-emacs-bidi@m.gmane.org; Fri, 03 Sep 2010 10:32:45 -0400 Original-Received: from [140.186.70.92] (port=60967 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OrXJp-0006nE-Sa for emacs-bidi@gnu.org; Fri, 03 Sep 2010 10:32:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OrXJo-0002V2-5F for emacs-bidi@gnu.org; Fri, 03 Sep 2010 10:32:41 -0400 Original-Received: from mail-gy0-f169.google.com ([209.85.160.169]:61672) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OrXJl-0002U1-Fs; Fri, 03 Sep 2010 10:32:37 -0400 Original-Received: by gyf3 with SMTP id 3so1033418gyf.0 for ; Fri, 03 Sep 2010 07:32:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ccyBRPcRprkd3CcfeDZqefQOQoHfcdr5ne1vJiCrsF8=; b=FLTywNRcGlYOH0jo2obYZexxyRyH2HKb9htaPJomxswJEPYSqalTLr5S3K4/1mNjQ5 fR+LIAxGcvSnBPHeDMmTAmjV4+7auQrP61rGZGBcX1uVJUm0VPmDKuZTEOVZt+fR4NCL cpIrB0eQiCBGGQvEcnUJO4ULXbmM/aIBQKSM0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jIvbQAvt8FHvbCziuNof3fwrfLbS4nmdKbQZpoPWFzm25Td8vBAichQM5kDl09u2PQ zRcIwJ1GacXUyEZjYqD+kX8Tci6H9bXCzh83jweKPG4EHEYvrgiuvqntlm7vN3/E7s/m 3QakZfezbF5hzn4kDA6AQJWqzd5O3xo7FeAto= Original-Received: by 10.151.27.15 with SMTP id e15mr261971ybj.79.1283524353179; Fri, 03 Sep 2010 07:32:33 -0700 (PDT) Original-Received: by 10.231.168.70 with HTTP; Fri, 3 Sep 2010 07:32:33 -0700 (PDT) In-Reply-To: <83pqwvhsbm.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-bidi@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of Emacs support for multi-directional text." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Errors-To: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bidi:815 gmane.emacs.devel:129648 Archived-At: --===============0691555472== Content-Type: multipart/alternative; boundary=000e0cd6a89621c145048f5bcd25 --000e0cd6a89621c145048f5bcd25 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 3, 2010 at 4:25 PM, Eli Zaretskii wrote: <- Snipped text -> > Even if everything I said above is correct, there are complications. > ABCDE could be inside an embedding with left to right override, like > this: > > foobar RLO ABCDE PDF > > This should be displayed as > > foobar ABCDE > > i.e., "ABCDE" is not reordered, but displayed in the logical order, as > forced by RLO. Therefore, the reshaped "XYZ" should also be displayed > left to right: > > foobar XYZ > > But, if I understand correctly how composition works, the > auto-composed sequence in this case will still be just "XYZ", without > the RLO and PDF control characters. So the `shape' method of the font > driver will still see just "XYZ" in the LGSTRING, without the control > characters, and will reorder "XYZ", which is incorrect. > > If we need the `shape' method to reorder glyphs, then in order for it > do its job correctly, we need to give it the entire bidi context of > the string we are asking it to reshape. In the above example, we need > to tell it about the override directive, i.e. pass it "ABCDE" with > surrounding RLO and PDF controls. This flies in the face of the > current design, which separates reordering from glyph shaping. > > Is that a typo? I think you mean LRO (U+202D) rather than RLO in all cases above. (Just commenting, to avoid further misunderstandings). Amit --000e0cd6a89621c145048f5bcd25 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Fri, Sep 3, 2010 at = 4:25 PM, Eli Zaretskii <eliz@gnu.org> wrote:

<- Snipped t= ext ->
=A0
Even if everything I said above is correct, there are complications.
ABCDE could be inside an embedding with left to right override, like
this:

=A0foobar RLO ABCDE PDF

This should be displayed as

=A0foobar ABCDE

i.e., "ABCDE" is not reordered, but displayed in the logical orde= r, as
forced by RLO. =A0Therefore, the reshaped "XYZ" should also be di= splayed
left to right:

=A0foobar XYZ

But, if I understand correctly how composition works, the
auto-composed sequence in this case will still be just "XYZ", wit= hout
the RLO and PDF control characters. =A0So the `shape' method of the fon= t
driver will still see just "XYZ" in the LGSTRING, without the con= trol
characters, and will reorder "XYZ", which is incorrect.

If we need the `shape' method to reorder glyphs, then in order for it do its job correctly, we need to give it the entire bidi context of
the string we are asking it to reshape. =A0In the above example, we need to tell it about the override directive, i.e. pass it "ABCDE" wit= h
surrounding RLO and PDF controls. =A0This flies in the face of the
current design, which separates reordering from glyph shaping.


Is that a typo? I think you mean LRO (= U+202D) rather than RLO in all cases above.
(Just commenting, to = avoid further misunderstandings).

=A0=A0 Amit

--000e0cd6a89621c145048f5bcd25-- --===============0691555472== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ emacs-bidi mailing list emacs-bidi@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-bidi --===============0691555472==--