Hebrew xlation of Emacs tutorial

Hebrew xlation of Emacs tutorial

[Yotam Medini יותם מדיני]

Should someone would volunteer to make a Hebrew translation 
of the Emacs tutorial, how can that be coordinated?

regards -- yotam

Re: Hebrew xlation of Emacs tutorial

[David Kastrup]

Yotam Medini יותם מדיני <yotam.medini@gmail.com> writes:

> Should someone would volunteer to make a Hebrew translation 
> of the Emacs tutorial, how can that be coordinated?

I think this would be rather pointless as long as Emacs does not
support editing right-to-left languages.

-- 
David Kastrup

Re: Hebrew xlation of Emacs tutorial

[Eli Zaretskii]

> Date: Fri, 2 Feb 2007 01:48:16 +0200
> From: Yotam Medini =?UTF-8?B?15nXldeq150g157Xk9eZ16DXmQ==?=
> 	<yotam.medini@gmail.com>
> 
> Should someone would volunteer to make a Hebrew translation 
> of the Emacs tutorial, how can that be coordinated?

I don't see any sense in having a Hebrew translation of the tutorial
as long as Emacs cannot display Hebrew text in a reasonably correct
way.

Re: Hebrew xlation of Emacs tutorial

[Yotam Medini יותם מדיני]

On Fri, 02 Feb 2007 15:13:16 +0200
Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Fri, 2 Feb 2007 01:48:16 +0200
> > From: Yotam Medini
> >
> > Should someone would volunteer to make a Hebrew translation
> > of the Emacs tutorial, how can that be coordinated?
>
> I don't see any sense in having a Hebrew translation of the tutorial
> as long as Emacs cannot display Hebrew text in a reasonably correct
> way.

While Emacs cannot display Hebrew text right, the TUTORIAL.he can
be converted to visual order.

I understand that Emacs tutorial in Hebrew will be much more important
once full Bidi support will be released.

Still, there is small young Linux community, that can use Emacs
to edit scripts and configuration files in Gnu/Linux.

I teach a small class of kids Python programming on Gnu/Linux.
The kids' English is poor. They understand enough, so they
can type simple code - using English letters of course.
As part of the course, I teach them basic Emacs usage. I wish I could
refer them to a tutorial.  So my thinking of the tutorial
translation, is to explain in Hebrew how to do English text editing.

May be there is also a chicken & egg situation here. The very fact
that there are too few young Emacs users who understand Hebrew,
is the reason that there are not enough people who can bring
Bidi support in Emacs to life.

Re: Hebrew xlation of Emacs tutorial

[David Kastrup]

Yotam Medini יותם מדיני <yotam.medini@gmail.com> writes:

> May be there is also a chicken & egg situation here. The very fact
> that there are too few young Emacs users who understand Hebrew, is
> the reason that there are not enough people who can bring Bidi
> support in Emacs to life.

Are you seriously suggesting that something like Bidi support could be
implemented in Emacs by people having major difficulties with the
language of its code comments and documentation?

-- 
David Kastrup

Re: Hebrew xlation of Emacs tutorial

[Yotam Medini יותם מדיני]

On Fri, 02 Feb 2007 16:33:55 +0100
David Kastrup <dak@gnu.org> wrote:

> Are you seriously suggesting that something like Bidi support could be
> implemented in Emacs by people having major difficulties with the
> language of its code comments and documentation?
> 
> -- 
> David Kastrup

Yes! not today, not this year, but may be in 4 years to come.
Smart kids who understands only Hebrew, are less likely to overcome
the learning curve of Emacs than kids who reads English fluently.

If we had more 12-year old kids using Emacs Today for trivial tasks, 
we will have some of them doing sophisticated programming in 4 years.
If they grow with Emacs and love it - they will want to contribute back.

How many years are we waiting for Bidi support in Emacs?

-- yotam

Re: Hebrew xlation of Emacs tutorial

[Eli Zaretskii]

> Date: Fri, 2 Feb 2007 17:25:51 +0200
> From: Yotam Medini =?UTF-8?B?15nXldeq150g157Xk9eZ16DXmQ==?= <yotam.medini@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> While Emacs cannot display Hebrew text right, the TUTORIAL.he can
> be converted to visual order.

Unfortunately, visual-order Hebrew is not reliably displayed in
current Emacs, either.  Depending on the toolkit, sometimes the words
are displayed reversed (because the toolkit applies bidi reordering
when it displays strings), but once you move the cursor past them,
they are converted back to the visual order.

I don't want to add to Emacs anything that ugly and unreliable, sorry.

> I teach a small class of kids Python programming on Gnu/Linux.
> The kids' English is poor. They understand enough, so they
> can type simple code - using English letters of course.
> As part of the course, I teach them basic Emacs usage. I wish I could
> refer them to a tutorial.  So my thinking of the tutorial
> translation, is to explain in Hebrew how to do English text editing.

I'm afraid that currently your only option is to edit the translated
tutorial in OpenOffice or some such, and then print it and use the
printed copy in your classes.

Re: Hebrew xlation of Emacs tutorial

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Fri, 02 Feb 2007 16:33:55 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> Are you seriously suggesting that something like Bidi support could be
> implemented in Emacs by people having major difficulties with the
> language of its code comments and documentation?

Understanding English prose is much more difficult than understanding
code most of which is made of single English words.

Re: Hebrew xlation of Emacs tutorial

[Eli Zaretskii]

> Date: Fri, 2 Feb 2007 18:16:24 +0200
> From: Yotam Medini =?UTF-8?B?15nXldeq150g157Xk9eZ16DXmQ==?= <yotam.medini@gmail.com>
> Cc: eliz@gnu.org, emacs-devel@gnu.org
> 
> How many years are we waiting for Bidi support in Emacs?

At least 7 years, AFAIR.

Re: Hebrew xlation of Emacs tutorial

[Stefan Monnier]

>> While Emacs cannot display Hebrew text right, the TUTORIAL.he can
>> be converted to visual order.
> Unfortunately, visual-order Hebrew is not reliably displayed in
> current Emacs, either.

Indeed.  In any case, I think we should encourage people to write tutorials
for any language, whether it's well supported by Emacs or not.

In the case of Hebrew, I think the best option is to write it "right" (using
another editor) and then keep it in Emacs's repository but without offering
it in the list of languages (since Emacs can't currently display it right).

So as soon as we get bidi-support, we'll also get the online
Hebrew tutorial.  One more motivation for writing the bidi support.


        Stefan

RE: Hebrew xlation of Emacs tutorial

[Drew Adams]

> I think we should encourage people to write tutorials
> for any language, whether it's well supported by Emacs or not.

I agree strongly.

However, I'd add the caveat that (I think) we agreed to revisit the existing
tutorial after the release, to try to improve it in various ways. If it
might change a lot, translators might prefer to translate it after the
rewrite.

Re: Hebrew xlation of Emacs tutorial

[Eli Zaretskii]

> Cc: Yotam Medini <yotam.medini@gmail.com>,  emacs-devel@gnu.org
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 02 Feb 2007 14:07:44 -0500
> 
> In the case of Hebrew, I think the best option is to write it "right" (using
> another editor)

One can write logical-order Hebrew in Emacs today, no need for another
editor.  It's just the display that is broken.

> and then keep it in Emacs's repository but without offering
> it in the list of languages (since Emacs can't currently display it right).

I don't see how we can craft a tutorial without being able to display
it, since the tutorial undergoes reformatting by Emacs, as you know.

If someone wants to contribute just the text, we could perhaps keep it
in admin somewhere, but I doubt that anyone would wish to work on
something that will not be used for some time to come.

> One more motivation for writing the bidi support.

I lack time, not motivation ;-)

Re: Hebrew xlation of Emacs tutorial

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Fri, 2 Feb 2007 11:12:32 -0800
> 
> > I think we should encourage people to write tutorials
> > for any language, whether it's well supported by Emacs or not.
> 
> I agree strongly.

Do you read Hebrew?  If not, try to imagine your beloved language
hopelessly messed up by Emacs, and you will begin to understand why I
don't want to see such abomination in the Emacs distribution.

No way I will agree to something like that.

P.S. I'm the coordinator of the Hebrew team in the Translation Project
(as well as the entire team), so it's not that I don't understand the
value of translating documentation.  All the he.po files you can find
in the GNU packages are my work.  I just hate to see badly formatted
Hebrew, that's all.

RE: Hebrew xlation of Emacs tutorial

[Drew Adams]

> > > I think we should encourage people to write tutorials
> > > for any language, whether it's well supported by Emacs or not.
> >
> > I agree strongly.
>
> Do you read Hebrew?  If not, try to imagine your beloved language
> hopelessly messed up by Emacs, and you will begin to understand why I
> don't want to see such abomination in the Emacs distribution.

Who said anything about it being in the Emacs distribution?

> No way I will agree to something like that.

You also said:

> If someone wants to contribute just the text, we could perhaps
> keep it in admin somewhere

That's what I had in mind: let people think now about translating, but don't
integrate any translations into Emacs until the display can support them. I
thought that was also what Stefan had in mind, but I don't know.

However, I also added a caveat that we should let potential translators know
that their effort might be partly wasted if the tutorial is revisited after
the release.

Stefan spoke not of translating, in fact, but of "writing tutorials", which
I also agree with. That is, I think it would be good for people to think now
about possible improvements to the Emacs tutorial. Recently, people here
looked at another tutorial (with screenshots etc.), which some found useful.
I say, let's get input from all quarters on how the Emacs tutorial might be
improved.

Input should be welcome, both translation and new tutorial ideas. You may
not "agree to something like that", but that's what I meant and what I still
mean.

Re: Hebrew xlation of Emacs tutorial

[Jason Rumney]

Stefan Monnier wrote:
> Indeed.  In any case, I think we should encourage people to write tutorials
> for any language, whether it's well supported by Emacs or not.
>   

I agree. It would be a shame if we completed the bidi support and did 
not have a Hebrew tutorial because we had turned down the offer now.

Re: Hebrew xlation of Emacs tutorial

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Fri, 02 Feb 2007 16:33:55 +0100
>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>> 
>> Are you seriously suggesting that something like Bidi support could be
>> implemented in Emacs by people having major difficulties with the
>> language of its code comments and documentation?
>
> Understanding English prose is much more difficult than understanding
> code most of which is made of single English words.

"code comments and documentation" are prose.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Hebrew xlation of Emacs tutorial

[Stefan Monnier]

>> In the case of Hebrew, I think the best option is to write it "right" (using
>> another editor)
> One can write logical-order Hebrew in Emacs today, no need for another
> editor.  It's just the display that is broken.

If you want to write it with Emacs, feel free, but I personally wouldn't
spend any time writing French texts on a right-to-left-only text editor, no
matter how great it may otherwise be.

> I don't see how we can craft a tutorial without being able to display
> it, since the tutorial undergoes reformatting by Emacs, as you know.

It does?  No, as a matter of fact, I didn't know.  And taking another look
at the French tutorial, I don't see any reformatting going on.

> If someone wants to contribute just the text, we could perhaps keep it
> in admin somewhere, but I doubt that anyone would wish to work on
> something that will not be used for some time to come.

It could be printed/displayed with other tools, and thus still be usable.

>> One more motivation for writing the bidi support.
> I lack time, not motivation ;-)

I'd hope someone *else* would jump in.


        Stefan

Re: Hebrew xlation of Emacs tutorial

[Eli Zaretskii]

> Cc: yotam.medini@gmail.com,  emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Fri, 02 Feb 2007 23:39:57 +0100
> >
> > Understanding English prose is much more difficult than understanding
> > code most of which is made of single English words.
> 
> "code comments and documentation" are prose.

I talked about code and comments.  Documentation is hard to understand
for someone who doesn't have good control of English, but the
documentation doesn't say much about bidi anyway.

Re: Hebrew xlation of Emacs tutorial

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: yotam.medini@gmail.com,  emacs-devel@gnu.org
>> From: David Kastrup <dak@gnu.org>
>> Date: Fri, 02 Feb 2007 23:39:57 +0100
>> >
>> > Understanding English prose is much more difficult than understanding
>> > code most of which is made of single English words.
>> 
>> "code comments and documentation" are prose.
>
> I talked about code and comments.

If you choose to change the subject, it helps your readers if you
actually bother mentioning it.  I talked about "code comments and
documentation", and you did not bring up a different subject in your
reply.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Hebrew xlation of Emacs tutorial

[Eli Zaretskii]

> Cc: yotam.medini@gmail.com,  emacs-devel@gnu.org
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 02 Feb 2007 20:52:51 -0500
> 
> > I don't see how we can craft a tutorial without being able to display
> > it, since the tutorial undergoes reformatting by Emacs, as you know.
> 
> It does?  No, as a matter of fact, I didn't know.  And taking another look
> at the French tutorial, I don't see any reformatting going on.

I meant this part of the tutorial:

    <<Blank lines inserted around following line by help-with-tutorial>>
    [Middle of page left blank for didactic purposes.   Text continues below]

which is modified when the tutorial is displayed.

> >> One more motivation for writing the bidi support.
> > I lack time, not motivation ;-)
> 
> I'd hope someone *else* would jump in.

Me too, but after so many years, I've abandoned that hope.

Re: Hebrew xlation of Emacs tutorial

[Richard Stallman]

    Should someone would volunteer to make a Hebrew translation 
    of the Emacs tutorial, how can that be coordinated?

He just has to (1) make the translation and (2) send me email about
it.

Re: Hebrew xlation of Emacs tutorial

[Eli Zaretskii]

> Cc: yotam.medini@gmail.com,  emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Sat, 03 Feb 2007 12:11:52 +0100
> 
> I talked about "code comments and documentation", and you did not
> bring up a different subject in your reply.

"Documentation" in Emacs obviously starts with the tutorial, so
translating that would be the obvious first step.  Witness the fact
that, currently, the tutorial is the only piece of Emacs that is
translated.

Really, David, for someone who comes from a country where every
important computer-related book is translated into German, and where
most OS facilities are localized (and for a good reason), I'd expect
you to understand that without me having to explain that in so many
words.

Re: Hebrew xlation of Emacs tutorial

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: yotam.medini@gmail.com,  emacs-devel@gnu.org
>> From: David Kastrup <dak@gnu.org>
>> Date: Sat, 03 Feb 2007 12:11:52 +0100
>> 
>> I talked about "code comments and documentation", and you did not
>> bring up a different subject in your reply.
>
> "Documentation" in Emacs obviously starts with the tutorial, so
> translating that would be the obvious first step.

You changed the topic again.  How does this make "code comments and
documentation" not prose?  If you want to talk about something
completely different from what you are replying to, there is no
necessity of quoting context as if it was relevant to your point.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Hebrew xlation of Emacs tutorial

[Eli Zaretskii]

> Cc: yotam.medini@gmail.com,  emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Sat, 03 Feb 2007 12:47:32 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Cc: yotam.medini@gmail.com,  emacs-devel@gnu.org
> >> From: David Kastrup <dak@gnu.org>
> >> Date: Sat, 03 Feb 2007 12:11:52 +0100
> >> 
> >> I talked about "code comments and documentation", and you did not
> >> bring up a different subject in your reply.
> >
> > "Documentation" in Emacs obviously starts with the tutorial, so
> > translating that would be the obvious first step.
> 
> You changed the topic again.

No, I didn't.  I've already covered the code and comments, so
documentation was the last bit.

> How does this make "code comments and documentation" not prose?

Comments are very short and easier to understand than the
documentation.  Documentation, such as the tutorial and the manuals
are the prose I referred to.

> If you want to talk about something completely different from what
> you are replying to, there is no necessity of quoting context as if
> it was relevant to your point.

If you want to be a pedant, with the sole purpose of having the last
word, let's just end this ``discussion''.

Re: Hebrew xlation of Emacs tutorial

[James Cloos]

Eli,

Any idea how much work it'd take to merge the changes between
the (your, right?) emacs-bidi-base and emacs-bidi branches into
the emacs-unicode-2 branch?

There are only 3 merge failures in src files, plus a couple in
texinfo files and several in ChangeLog files.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Hebrew xlation of Emacs tutorial

[David Kastrup]

James Cloos <cloos@jhcloos.com> writes:

> Eli,
>
> Any idea how much work it'd take to merge the changes between
> the (your, right?) emacs-bidi-base and emacs-bidi branches into
> the emacs-unicode-2 branch?
>
> There are only 3 merge failures in src files, plus a couple in
> texinfo files and several in ChangeLog files.

I don't think that this is the only issue.  Eli might correct me on
that, but the last time this issue came up, he clearly stated that the
bidi branch was not production quality and had serious stability and
performance issues.  We certainly don't want it to be "merged into the
emacs-unicode-2 branch" before Emacs 23 is released: emacs-unicode-2
is a major step forward and apparently close to release quality.

There are also other issues which should probably be addressed when
reworking the display engine for bidi, like composite character
support and antialiasing, so merging the fragile bidi branch might not
actually be the best tactic for going forward.

At the current point of time, I think it prudent to leave Emacs-bidi
on the back burner, and to start thinking about what long-term
strategy to follow in a bidi-capable branch (it might well mean
abandoning the current emacs-bidi approach) when emacs-unicode-2 has
made it into the trunk and does not require major reworks before Emacs
23.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Hebrew xlation of Emacs tutorial

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Sat, 03 Feb 2007 17:21:24 +0100
> 
> I don't think that this is the only issue.  Eli might correct me on
> that, but the last time this issue came up, he clearly stated that the
> bidi branch was not production quality and had serious stability and
> performance issues.

David is right: the bidi branch is just a first attempt to make the
display engine support bidirectional languages.  It needs a lot of
debugging to become usable.  In particular, as soon as you turn on the
bidi support flag, Emacs instantly crashes.

> We certainly don't want it to be "merged into the
> emacs-unicode-2 branch" before Emacs 23 is released: emacs-unicode-2
> is a major step forward and apparently close to release quality.

I rather hope that Emacs 23 will come out with bidi support (since
Unicode requires that), but that hope has no basis whatsoever.

> There are also other issues which should probably be addressed when
> reworking the display engine for bidi, like composite character
> support and antialiasing

I'm not aware of any such issues, but then the implications of bidi
redisplay were never discussed in detail.

Re: Hebrew xlation of Emacs tutorial

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>
>> We certainly don't want it to be "merged into the emacs-unicode-2
>> branch" before Emacs 23 is released: emacs-unicode-2 is a major
>> step forward and apparently close to release quality.
>
> I rather hope that Emacs 23 will come out with bidi support (since
> Unicode requires that), but that hope has no basis whatsoever.

Uh, I hope that Emacs 23 will come out in this decade still...

>> There are also other issues which should probably be addressed when
>> reworking the display engine for bidi, like composite character
>> support and antialiasing
>
> I'm not aware of any such issues, but then the implications of bidi
> redisplay were never discussed in detail.

Oh, that is not as much an implication of bidi redisplay but rather of
missing display features of Emacs in general.  "composite character"
may be the wrong word, it is "compositing"?  Things like accents that
are supposed to overprint the following character.

Emacs does not cater for them yet, neither does it for antialiased
font display (unless we are talking isolated branches or ports).  I
thought that it would be probably imprudent to address those missing
features in isolation from bidi support, since the solutions likely
have some overlap.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Hebrew xlation of Emacs tutorial

[James Cloos]

>>>>> "David" == David Kastrup <dak@gnu.org> writes:

David> Oh, that is not as much an implication of bidi redisplay but rather of
David> missing display features of Emacs in general.  "composite character"
David> may be the wrong word, it is "compositing"?  Things like accents that
David> are supposed to overprint the following character.

David> Emacs does not cater for them yet, neither does it for antialiased
David> font display

Actually, the font-backend code in the unicode-2 branch handles aa and
simple-compositing just fine, in my experience.  At least when using
the xft backend (alone; I don't run with fallback to the x backend).
Handa-san's got that much working very well, though I did need to put
in some effort creating a reasonably complete xft fontset.

My understanding is that it also works well on the mac backend.

OTOH, I've had no luck with complex composition, such as for Brahmic
scripts.  

So the basic support for compositing seems to be there, it just needs
a full set of rules for the complex scripts.  Eg, everything that
pango can do.  (Pango is (or 'LGPL-2 'FreetypeLicence), so there
shouldn't be any problem using it as a primary reference for writing
the necessary lisp.)

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Hebrew xlation of Emacs tutorial

[Eli Zaretskii]

> Cc: cloos@jhcloos.com,  emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Sat, 03 Feb 2007 20:12:42 +0100
> 
> Oh, that is not as much an implication of bidi redisplay but rather of
> missing display features of Emacs in general.  "composite character"
> may be the wrong word, it is "compositing"?  Things like accents that
> are supposed to overprint the following character.

You mean combining character sequences (and other compatibility and
canonical decompositions).  Yes, Emacs does not yet fully support
them.  And there are several other features codified by Unicode that
AFAIK we still don't support.

> Emacs does not cater for them yet, neither does it for antialiased
> font display (unless we are talking isolated branches or ports).  I
> thought that it would be probably imprudent to address those missing
> features in isolation from bidi support, since the solutions likely
> have some overlap.

The only overlap I know of is that Hebrew and Arabic have
diacriticals, so any support for combining sequences will have to
include that.

Re: Hebrew xlation of Emacs tutorial

[James Cloos]

|> so there shouldn't be any problem using [Pango] as a primary
|> reference for writing the necessary lisp.)

Belay that.  I just read overnight that neither pango nor icu are
happy with their shaping engines for Brahmic scripts.  

But it seems (again, from what I just read) that qt's engine is up to
par, so perhaps qt's (GPL2'ed) shaping engine can be used as a primary
reference in writing an engine in lisp....

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Hebrew xlation of Emacs tutorial

[Kenichi Handa]

In article <m3r6t5eoit.fsf@lugabout.jhcloos.org>, James Cloos <cloos@jhcloos.com> writes:

>>> so there shouldn't be any problem using [Pango] as a primary
>>> reference for writing the necessary lisp.)

> Belay that.  I just read overnight that neither pango nor icu are
> happy with their shaping engines for Brahmic scripts.  

> But it seems (again, from what I just read) that qt's engine is up to
> par, so perhaps qt's (GPL2'ed) shaping engine can be used as a primary
> reference in writing an engine in lisp....

As for a shaping engine, my plan is to equip Emacs with FLT
(Font Layout Table) driver.  FLT is developped by our team
in AIST for writing a shaping rule by s-expressions to be
used with our m17n-lib <http://www.m17n.org>.

This page shows the currently supported scripts:
  http://www.m17n.org/m17n-lib-en/screenshots.html

Attached is the FLT for Devanagari.

---
Kenichi Handa
handa@m17n.org

;; DEVA-OTF.flt -- Font Layout Table for Devanagari OpenType font
;; Copyright (C) 2003, 2004
;;   National Institute of Advanced Industrial Science and Technology (AIST)
;;   Registration Number H15PRO112

;; This file is part of the m17n database; a sub-part of the m17n
;; library.

;; The m17n library is free software; you can redistribute it and/or
;; modify it under the terms of the GNU Lesser General Public License
;; as published by the Free Software Foundation; either version 2.1 of
;; the License, or (at your option) any later version.

;; The m17n library is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
;; Lesser General Public License for more details.

;; You should have received a copy of the GNU Lesser General Public
;; License along with the m17n library; if not, write to the Free
;; Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
;; Boston, MA 02110-1301, USA.

;;; <li> DEVA-OTF.flt
;;;
;;; For Devanagari OpenType fonts to draw the Devanagari script.

(category
 ;; C: consonant (except for R)
 ;; R: consonant RA
 ;; n: NUKTA
 ;; H: HALANT
 ;; m: MATRA (pre)
 ;; u: MATRA (above)
 ;; b: MATRA (below)
 ;; p: MATRA (post)
 ;; A: vowel modifier (above)
 ;; a: vowel modifier (post)
 ;; S: stress sign (above)
 ;; s: stress sign (below)
 ;; V: independent vowel
 ;; N: ZWNJ (ZERO WIDTH NON-JOINER)
 ;; J: ZWJ (ZERO WIDTH JOINER)
 ;; E: ELSE
 ;;
 (#x0900 #x097F	?E)			; ELSE
 (#x0901	?A)			; SIGN CANDRABINDU (above)
 (#x0902	?A)			; SIGN ANUSVARA (above)
 (#x0903	?a)			; SIGN VISARGA (post)
 (#x0905 #x0914	?V)			; LETTER A .. LETTER AU
 (#x0915 #x0939 ?C)			; LETTER KA .. LETTER HA
 (#x0930	?R)			; LETTER RA
 (#x093C	?n)			; SIGN NUKTA
 (#x093D	?E)			; SIGN AVAGRAHA
 (#x093E #x094C	?p)			; VOWEL SIGN (post)
 (#x093F	?m)			; VOWEL SIGN I (pre)
 (#x0941 #x0944	?b)			; VOWEL SIGN (below)
 (#x0945 #x0948	?u)			; VOWEL SIGN (above)
 (#x094D	?H)			; SIGN VIRAMA (HALANT)
 (#x0950	?E)			; OM
 (#x0951 #x0954	?S)		    ; STRESS SIGN or TONE MARK (above)
 (#x0952	?s)		    ; STRESS SIGN or TONE MARK (below)
 (#x0958 #x095E	?C)			; LETTER QA .. LETTER YYA
 (#x0960	?V)			; LETTER VOCALIC RR
 (#x0961	?V)			; LETTER VOCALIC LL
 (#x0962 #x0963	?b)			; VOWEL SIGN (below)
 (#x0964 #x0970	?E)			; DANDA .. ABBREVIATION SIGN
 (#x200C	?N)			; ZWNJ
 (#x200D	?J)			; ZWJ
 (#x097D	?x)		; internally used tag to indicate Reph
 (#x097E	?y)		; internally used tag to indicate Mpost
 (#x097F	?z)		; internally used tag to indicate Cbase
 )

;; The first stage is to extract a syllable and re-order characters in
;; it.
(generator
 (0
  (cond
   ;; If [CR]H is followed by ZWNJ/ZWJ, move ZWNJ/ZWJ to the head so
   ;; that the later stages find it quickly.
   ("([CR]n?H)([NJ])"
    < | (2 =) (1 = *) | > )

   ;; A syllable starting with RH (Reph) and ending with a vowel
   ;; and/or a vowel modifier.
   ("(RH)(([CR]n?H)*[CR]n?)([mubp][Aa]?[Ss]?|[Aa][Ss]?|[Ss])"
    < | (1 #x097D = =) (2 move-base-Halant) (4 reorder-post-base) | >)

   ;; A syllable starting with RH (Reph) and ending without a vowel
   ;; nor a vowel modifier.
   ("(RH)(([CR]n?H)*[CR]n?)(H)?"
    < | (1 #x097D = =) (2 move-base-Halant) (4 =) | >)

   ;; A syllable starting with the other consonant and ending with a
   ;; vowel and/or a vowel modifier.
   ("(([CR]n?H)*[CR]n?)([mubp][Aa]?[Ss]?|[Aa][Ss]?|[Ss])"
    < | (1 move-base-Halant) (3 reorder-post-base) | >)

   ;; A syllable starting with the other consonant and ending without
   ;; a vowel nor a vowel modifier.
   ("(([CR]n?H)*[CR]n?)(H)?"
    < | (1 move-base-Halant) (3 =) | >)

   ;; A syllable starting with an independent vowel.
   ("V[Aa]?[Ss]?"
    < | = * | > )

   ("." =))
  *)

 ;; Move Halant on a base consonant to the tail.
 (move-base-Halant
  (cond
   ("(([CR]n?H)*[CR]n?)(H)(R)"
    (1 = *)
    (4 =)
    (3 =))
   (".*"
    = *)))

 ;; Re-order post modifiers.
 (reorder-post-base
  ;; 12   3   4   5    67   8     9   10
  ("((m)|(u)|(b)|(p))?((A)|(a))?((S)|(s))?$"
   (2 =) (4 =) (10 =) (3 =) (5 =)
   #x097E
   (7 =) (9 =) (8))))

;; The second stage is to reorder Reph and Mpre.
(generator
 (0
  (cond
   (" [NJ]([^ ]*) "
    = *)
   (" (x(..))([CRnH]*) "
    | (3 = *) (2 otf:deva=rphf) |)
   (" (x(..))([CRnH]*)(m?)([^y]*)y([^ ]*) "
    | (4 =) (3 = *) (5 = *) (2 otf:deva=rphf) (6 = *) |)
   (" ([CRnH][CRnH]*) "
    = *)
   (" ([CRnH][CRnH]*)(m?)([^y]*)y([^ ]*) "
    | (2 =) (1 = *) (3 = *) (4 = *) |)
   ("." =))
  *))

;; The third stage is to drive OTF tables.  For the moment, we use
;; the default LangSys, and try all GSUB/GPOS features except for the
;; sequence followed by ZWNJ in which case try "nukt" and "haln"
;; features only.
(generator
 (0
  (cond
   (" N([^ ]*) "
    (1 otf:deva=nukt,haln))

   (" J([^ ]*) "
    (1 otf:deva))

   (" ([^ ]*)(CH) "
    (1 otf:deva=~rphf,*) (2 otf:deva=haln))

   (" ([^ ]*) "
    (1 otf:deva=~rphf,*))

   ("."
    \[ otf:deva=+ \] ))
  *))

;; Local Variables:
;; mode: emacs-lisp
;; End:

Re: Hebrew xlation of Emacs tutorial

[Kenichi Handa]

In article <85r6t7f42d.fsf@lola.goethe.zz>, David Kastrup <dak@gnu.org> writes:

> Oh, that is not as much an implication of bidi redisplay but rather of
> missing display features of Emacs in general.  "composite character"
> may be the wrong word, it is "compositing"?  Things like accents that
> are supposed to overprint the following character.

??? If you talking about the combining characters
U+0300-U+037F, they are supposed to overprint the PREVIOUS
character, and emacs-unicode-2 branch already supports it.

---
Kenichi Handa
handa@m17n.org

Re: Hebrew xlation of Emacs tutorial

[David Kastrup]

Kenichi Handa <handa@m17n.org> writes:

> In article <85r6t7f42d.fsf@lola.goethe.zz>, David Kastrup <dak@gnu.org> writes:
>
>> Oh, that is not as much an implication of bidi redisplay but rather of
>> missing display features of Emacs in general.  "composite character"
>> may be the wrong word, it is "compositing"?  Things like accents that
>> are supposed to overprint the following character.
>
> ??? If you talking about the combining characters
> U+0300-U+037F, they are supposed to overprint the PREVIOUS
> character, and emacs-unicode-2 branch already supports it.

I stand corrected.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Hebrew xlation of Emacs tutorial

[James Cloos]

>>>>> "Handa" == Kenichi Handa <handa@m17n.org> writes:

Handa> As for a shaping engine, my plan is to equip Emacs with FLT
Handa> (Font Layout Table) driver.  FLT is developped by our team
Handa> in AIST for writing a shaping rule by s-expressions to be
Handa> used with our m17n-lib <http://www.m17n.org>.

Way cool!

Especially since it is already in lisp.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Hebrew xlation of Emacs tutorial

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> CC: emacs-devel@gnu.org, eliz@gnu.org
> Date: Mon, 05 Feb 2007 09:52:28 +0900
> 
> As for a shaping engine, my plan is to equip Emacs with FLT
> (Font Layout Table) driver.  FLT is developped by our team
> in AIST for writing a shaping rule by s-expressions to be
> used with our m17n-lib <http://www.m17n.org>.

It sounds like this is a GNU/Linux-only solution, though, is that
right?

Re: Hebrew xlation of Emacs tutorial

[Kenichi Handa]

In article <u4ppu9r1l.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > As for a shaping engine, my plan is to equip Emacs with FLT
> > (Font Layout Table) driver.  FLT is developped by our team
> > in AIST for writing a shaping rule by s-expressions to be
> > used with our m17n-lib <http://www.m17n.org>.

> It sounds like this is a GNU/Linux-only solution, though, is that
> right?

I'm not going to use m17n-lib itself with Emacs.  Instead,
my plan is to implement FLT driver (i.e., parser &
interpreter) in Emacs Lisp.  Then, it should be system
independent.

---
Kenichi Handa
handa@m17n.org