Re: [I18n]xterm to invoke luit

[Juliusz Chroboczek]

Tomohiro KUBOTA <[EMAIL PROTECTED]>:

Hi Tomohiro,

I agree with the general idea.  I would like to change a few details.

I would suggest one new resource:

  XTerm*utf8Filter: /usr/X11R6/bin/luit

If utf8Filter is set, and XTerm is in UTF-8 mode, XTerm will spawn

   prog args

instead of 

  prog args

In addition, I suggest that the utf8 resource should be changed to a
tri-valued flag: it can be false, true, or auto, the latter meaning
that XTerm should run in UTF-8 mode if the locale is multi-byte, and
in eight-bit mode if it is not.

The defaults for these resources should be

  XTerm*utf8Filter: /bin/luit
  XTerm*utf8: auto  (or perhaps true?)


TK>  - emulate doublewidth de-facto standard for east Asian encodings
TK>(using http://www.cl.cam.ac.uk/~mgk25/ucs/scw-proposal.html ?)

With all due respect, I refuse to implement Markus' proposal.

TK>  - luit to support more encodings
TK>(http://mail.nl.linux.org/linux-utf8/2001-11/msg00093.html)

Yep.  Boring, but must be done.

TK>  - whether xterm or luit will support BiDi or not.  Usage of fribidi
TK>may have license problem (like Robert Brady's patch).

My personal opionion is that BIDI belongs above the terminal emulator.

And the number 1 item: include your fix for SS in EUC-JP (actually a
slightly improved version).

Thanks for your comments,

Juliusz
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n

Re: [I18n]xterm to invoke luit

[Juliusz Chroboczek]

JS> Does luit support the encodings that do not compatible with iso-2022? 

Yes, but currently only 128 character encodings (e.g. CP1252), 128x128
character encodings and 128x256 character encodings (e.g. Big 5).

GB 18030 and UTF-8 are on my to-do list; remember, however, that I
work on that stuff in my free time, and I'm not giving any deadlines.

LH> # LANG=zh_TW.Big5 xterm -u8 -e luit
LH> Warning: couldn't find charset data for locale zh_TW.Big5; using ISO 
LH> 8859-1.

Either luit or XFree86 are incorrectly installed (luit can't get at
the locale.alias file).

LH> # xterm -u8 -e luit -g2 'Big 5'

Try running luit with the `-v' flag and see what that gives.

Juliusz


___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n

Re: [I18n]xterm to invoke luit

[Juliusz Chroboczek]

JC> 128x256 character encodings (e.g. Big 5).

Sorry, that was 96x192.  Or somesuch.

Juliusz
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n

Re: [I18n]bdftruncate again ;)

[Moe Elzubeir]

 
I think you may want to elaborate on your statement about the Unicode
Arabic glyphs being a short-term solution. It seems quite adequate to
me.
It's a shame on who? Obviously XFree86 is not going to the effort
of implementing such a display engine for Arabic or any other 
scripted
language to my knowledge. Shame on people concerned with Arabization?
And for what? For X? for the console? As far as we are concerned
at Arabeyes, the only stand-alone application we have (that is not in
support for another application) with such a rendering engine is
Akka (for the linux console).. and yes, it does consider all those
languages (even the exitnct Syriac). 
 
It seems that this "Unicode is not a good glyph encoding" gets
echoed over and over.. and going through most of the posts, I don't
know where anyone has suggested they were? We have gotten over
that since we learnt of Unicode ;) Who else needs to get over that?
 
Actually, if you really want to look at internationalization, if you 
can
claim that something works for Arabic.. you can pretty much claim it 
can
work for any other language (almost). So, that's our new symptom,
"if it works for Arabic, it must be international" ;)
>>> [EMAIL PROTECTED] 01/25/02 09:55AM >>>RP> 
But isn't it a suitable glyph encoding for Arabic?Only to a certain 
extent.With its presentation forms for Arabic, Unicode provides a fixed 
glyphset for Arabic.  While this glyph set is suitable for some 
simplestyles of Arabic typography, there is enough variation 
intypographical traditions to make the use of Unicode Arabic glyphs 
ashort-term solution.
(While it is true that the same could be said of Latin typography, 
withLatin ligatures are not used for on-screen display (or at least 
mostof us find their use incomfortable).)Furthermore, I think it is 
a shame to go to the effort of implementingan Arabic display engine and not 
make it support related scripts(Syriac being the obvious example) which may 
not have encodedpresentation forms.Folks, get over it: Unicode is 
not a good glyph encoding.  The factthat we're using it as such is a 
symptom of what is wrong with Unixinternationalisation.  (``If it works 
for English and Japanese, itmust be international.)
—-
Mohammed Elzubeir
 

Re: [I18n]bdftruncate again ;)

[Moe Elzubeir]

And who do I submit this to? I have emailed you privately (or 
at least I think I did, to an acm.org
account) for some other issues before I submit 
them.
 
But, since I am getting no reply, I will go ahead and submit 
what I have. Does this
go to patches@... ?
 
 
Thank you
—
Mohammed Elzubeir>>> [EMAIL PROTECTED] 01/24/02 
07:35PM >>>If you really want to install an arabic subset of 
10x20.bdf and need anew XLFD for it, then I suggest that you generously 
follow the XLFDnaming guidelines on  http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.htmland 
call the new XLFD  
-Misc-Fixed-Medium-R-Normal-ar-20-200-75-75-C-100-ISO10646-1  
^^ ISO 639-1 code for Arabic languageI know that having a different 
subset is stretching the concept of astyle variant quite a bit, but it is a 
convenient place to put languageidentifiers for fonts that have been 
tailored for specific languages.Nevertheless, I find the idea of having 
the same font installed in twosubsets rather 
disturbing.Markus-- Markus G. Kuhn, Computer Laboratory, 
University of Cambridge, UKEmail: mkuhn at acm.org,  WWW: ___I18n 
mailing list[EMAIL PROTECTED]http://XFree86.Org/mailman/listinfo/i18n

Re: [I18n]bdftruncate again ;)

[Juliusz Chroboczek]

ME> It's a shame on who?

I used ``it is a shame'' in the sense of ``it is a pity''; while I'm
not a native speaker, I believe that this is standard usage in
English.  The intention was not to cast blame on anyone, but to imply
that if you go to the significant effort of implementing an Arabic
typesetting system, it would be a pity (colloquialy termed ``a
shame'') not to go all the way and make a system that is extensible.

ME> I think you may want to elaborate on your statement about the Unicode
ME> Arabic glyphs being a short-term solution.

In my opinion, any solution that is intimately wedded to a single
glyph encoding is a short term solution.

The set of possible ligatures and contextual forms in Arabic is
open-ended.  While it may very well be that the set of Arabic glyphs
encoded in Unicode is sufficient for your immediate needs (and perhaps
it is, who am I to know?), there is a significant chance that this
will no longer be the case in the future.

Thus, I would like to encourage you to consider a solution that uses
dynamically generated glyph encodings rather than using Unicode as a
fixed glyph encoding.  The former is not (easily) doable with core
fonts, whence my suggestion to avoid them.

The other reason I would like to encourage you not to use core fonts
is that the core fonts system is obsolete.  I do believe that we have
already pushed it to its limits.  If you do use the core fonts system,
you will request more features, something that we will have no choice
but to refuse, leading to further pleasant conversations such as this
one.

ME> It seems that this "Unicode is not a good glyph encoding" gets
ME> echoed over and over.

The set of possible glyphs for any single language (even English) is
open-ended.  Thus, unless I've missed something, there is no such
thing as a ``good'' glyph encoding for text (as opposed to dingbats).

Regards,

Juliusz Chroboczek
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n

Re: [I18n]bdftruncate again ;)

[Moe Elzubeir]

I think there is a misunderstanding here. I am differntiating 
between the actual
glyphs and the glyph encodings. The Unicode glyph encodings 
are completely
irrelevant and are of no use to us. What I understood from you 
is that the actual
set of glyphs are a short-term solution, which is not true in 
the case of Arabic.
I don't know how it can be 'open-ended'. Arabic requires a 
certain set of glyphs
to be able to render words properly, that is a fixed number of 
glyphs. How they
are encoded, is again, irrelvant.
 
It is understood that the core font system is both inadequate for i18n 
and
quickly becoming obsolete. The use of the core font system as far as I 
am
concerned is limited to applications such as xterm, and other 
miscellaneous
applications which expect/require fixed-width fonts. Any other kind of 
application,
say, a Word-processor or a web browser, would make use of TrueType 
fonts.
 
Backward-compatibilty is the reason we would like to have the Arabic 
fonts
available on the core font collection. It is by no means intended to be 
what
all future applications will depend on. That would be a gross mistake, 
seeing
how limited their use is.
 
We have asked for no features, as far as I recall. Our requests have 
been
quite reasonable, although perhaps misunderstood. In any case, Markus
has agreed to take a subset of the ISO10646-1, and that is what I will 
do.
If that too is unacceptable, then I don't know what else 
to do?
I have asked on several occasions what an alternative solution would be, 
and
the answer was often to use libraries that aren't even stable yet.
 
In fact, I am now even more confused ;) So please bare with me and 
explain
to me, if you may. There are core fonts, and there is a core font 
system.
Then there is the Xft library interface. My question is, what fonts does 
the
Xft use? Where does it get them from? 
 
Thank you.
Mohammed Elzubeir
 
>>> [EMAIL PROTECTED] 01/31/02 09:37AM >>>ME> I 
think you may want to elaborate on your statement about the UnicodeME> 
Arabic glyphs being a short-term solution.In my opinion, any solution 
that is intimately wedded to a singleglyph encoding is a short term 
solution.The set of possible ligatures and contextual forms in Arabic 
isopen-ended.  While it may very well be that the set of Arabic 
glyphsencoded in Unicode is sufficient for your immediate needs (and 
perhapsit is, who am I to know?), there is a significant chance that 
thiswill no longer be the case in the future.Thus, I would like to 
encourage you to consider a solution that usesdynamically generated glyph 
encodings rather than using Unicode as afixed glyph encoding.  The 
former is not (easily) doable with corefonts, whence my suggestion to avoid 
them.The other reason I would like to encourage you not to use core 
fontsis that the core fonts system is obsolete.  I do believe that we 
havealready pushed it to its limits.  If you do use the core fonts 
system,you will request more features, something that we will have no 
choicebut to refuse, leading to further pleasant conversations such as 
thisone.ME> It seems that this "Unicode is not a good glyph 
encoding" getsME> echoed over and over.The set of possible glyphs 
for any single language (even English) isopen-ended.  Thus, unless I've 
missed something, there is no suchthing as a ``good'' glyph encoding for 
text (as opposed to 
dingbats).Regards,    
Juliusz Chroboczek___I18n 
mailing list[EMAIL PROTECTED]http://XFree86.Org/mailman/listinfo/i18n

Re: [I18n]bdftruncate again ;)

[Keith Packard]

Around 10 o'clock on Jan 31, "Moe Elzubeir" wrote:

> Then there is the Xft library interface. My question is, what fonts does the
> Xft use? Where does it get them from? 

Xft uses the FreeType library and any fonts that are supported through 
that.  FreeType supports most scalable formats, and is working on support 
for more of them.  It also supports the standard .pcf fonts provided in 
XFree86, so all of your bitmap fonts will be usable, even those with a 
large encoding space.  The XFree86 4.2 version of Xft doesn't have support 
for those bitmap fonts, but the next version does.

The next version of Xft also uses a separate font configuration library; I 
intend to use that configuration within the X server at some point to 
unify font configuration on the display.  I'm also working on various 
other projects to get them interested in shared font configuration so that 
in the future, you'll need edit only one file to configure fonts in all of 
the packages on the system.

Xft will also no longer require the Render extension for client-side text,
it has fall-back code using the core protocol so that applications are 
assured of running even on legacy X servers.

Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab


___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n

Re: [I18n]bdftruncate again ;)

[Brian Stell]

Moe Elzubeir,

I'm not an expert on Arabic display so if I misspeak please
forgive me and let me know.

> Then there is the Xft library interface. My question is, what fonts does the
> Xft use? Where does it get them from?

Xft uses TrueType font directly. Thus it is not affected by X 
server font issues. With the alternate presentation forms I
suspect you can probably make readable Arabic text.

> Xft will also no longer require the Render extension for client-side text,
> it has fall-back code using the core protocol so that applications are
> assured of running even on legacy X servers.

This means that if you were to build an "Arabic Xterm" and static 
link Xft it will work on older X servers as well as newer X servers.

Regarding *accurate* Arabic shaping: I'm not sure how this would 
be done using Xft since it tends to work at the character level 
not the glyph level and does not have code to handle Arabic 
shaping.

The X environment needs work here. Perhaps you could discuss the 
requirements and possible solutions with Keith and this group.

-- 
Brian Stell
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n

[I18n]Re: Cedilla: a manic text printer

[Bruno Haible]

Juliusz Chroboczek writes:
> A first beta of Cedilla, the manic text printer, is available from
> 
>   http://www.pps.jussieu.fr/~jch/software/cedilla/

If you happen to run it in CLISP 2.26, you need to apply the following
bug fix to clisp, and also use "ext:quit" instead of "lisp:quit".

Bruno


*** clisp-2.26/src/io.d.bak 2001-04-17 09:31:13.0 +0200
--- clisp-2.26/src/io.d 2002-01-31 04:12:46.0 +0100
***
*** 3108,3142 
  TheIarray(hstring)->data = token; # Datenvektor := O(token_buff_1)
  token = TheIarray(token)->data; # Normal-Simple-String mit Token
  var uintL pos = 0; # momentane Position im Token
! loop { # Suche nächstes Hyphen
!   if (len-pos == 1) # einbuchstabiger Charactername?
! break;
!   var uintL hyphen = pos; # hyphen := pos
!   loop {
! if (hyphen == len) # schon Token-Ende?
!   goto no_more_hyphen;
! if (chareq(TheSstring(token)->data[hyphen],ascii('-'))) # Hyphen gefunden?
!   break;
! hyphen++; # nein -> weitersuchen
!   }
!   # Hyphen bei Position hyphen gefunden
!   var uintL sub_len = hyphen-pos;
!   TheIarray(hstring)->dims[0] = pos; # Displaced-Offset := pos
!   TheIarray(hstring)->totalsize =
! TheIarray(hstring)->dims[1] = sub_len; # Länge := hyphen-pos
!   # Jetzt ist hstring = (subseq token pos hyphen)
!   # Displaced-String hstring ist kein Bitname -> Error
!   pushSTACK(*stream_); # Wert für Slot STREAM von STREAM-ERROR
!   pushSTACK(copy_string(hstring)); # Displaced-String kopieren
!   pushSTACK(*stream_); # Stream
!   pushSTACK(S(read));
!   fehler(stream_error,
!  GETTEXT("~ from ~: there is no character bit with name ~")
! );
!  bit_ok: # Bitname gefunden, Bit gesetzt
!   # Mit diesem Bitnamen fertig.
!   pos = hyphen+1; # zum nächsten
! }
  # einbuchstabiger Charactername
  {
var chart code = TheSstring(token)->data[pos]; # (char token pos)
--- 3108,3114 
  TheIarray(hstring)->data = token; # Datenvektor := O(token_buff_1)
  token = TheIarray(token)->data; # Normal-Simple-String mit Token
  var uintL pos = 0; # momentane Position im Token
! if (len-pos == 1) # einbuchstabiger Charactername?
  # einbuchstabiger Charactername
  {
var chart code = TheSstring(token)->data[pos]; # (char token pos)
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n

Re: [I18n]bdftruncate again ;)

[Juliusz Chroboczek]

ME> What I understood from you is that the actual set of glyphs are a
ME> short-term solution, which is not true in the case of Arabic.  I
ME> don't know how it can be 'open-ended'. Arabic requires a certain
ME> set of glyphs to be able to render words properly, that is a fixed
ME> number of glyphs.

I may be misunderstanding something, but I had the notion that the set
of possible ligatures for Arabic rendering is open-ended, just as it
is for Latin rendering.  There are most definitely ligatures that I
have seen which do not appear in Unicode.

I'm not claiming here that there is a demonstrated need for you to
support anything beyond basic Naskh right now; I'm only saying that
nobody knows what the future will bring.  (And think of the demo value
of having a text editor that renders Diwani...)

ME> It is understood that the core font system is both inadequate for
ME> i18n and quickly becoming obsolete.

Definitely so for the former, hopefully so for the latter.

ME> The use of the core font system as far as I am concerned is
ME> limited to applications such as xterm, and other miscellaneous
ME> applications which expect/require fixed-width fonts. Any other
ME> kind of application, say, a Word-processor or a web browser, would
ME> make use of TrueType fonts.

Core fonts can be TrueType fonts, or any technology you may want.
XFree86 4 and later supports presenting TrueType fonts as core fonts.

The keyword is *client-side* fonts, not TrueType (or Type 1, or whatever).

ME> We have asked for no features, as far as I recall.

I haven't claimed you did.  I'm simply saying that if you use the core
fonts system, you'll quickly run into its limitations; and then you'll
ask for features which we'll be unable to provide.

Regards,

Juliusz
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n

Re: [I18n]bdftruncate again ;)

[Keith Packard]

Around 8 o'clock on Jan 31, Brian Stell wrote:

> Regarding *accurate* Arabic shaping: I'm not sure how this would 
> be done using Xft since it tends to work at the character level 
> not the glyph level and does not have code to handle Arabic 
> shaping.

Xft is not a text layout library (but it does play one on TV).  What it 
does provide is complete access to the underlying FreeType API -- 
applications can access any available font information that might assist 
in layout.  I'm still scheming on how to package some of that information; 
in particular, PCF fonts provide a lot of the information found in OS/2 
tables in TrueType fonts and AFM files for Type1 fonts.  It would be nice 
to wrap that in common interfaces.

The new version of Xft also provides cleaner APIs for accessing unencoded
glyphs as well as APIs that take position information for each glyph so
that the application has complete control over glyph placement without
having to draw one character at a time.

> The X environment needs work here. Perhaps you could discuss the 
> requirements and possible solutions with Keith and this group.

Yes, it does need work -- I'd like to see existing layout schemes ported 
to Xft so that we can start to build a rough concensus on what a 
reasonable general API would look like.

Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab


___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n

[I18n]Help! LocaleSetting -> UTF-8

[Nguyen quoc Binh]

Dear all

 

Currently I’m using RedHat7.1 (Xfree86-4.0.3;
glibc-2.2.2) and happy enough with few Unicode supports for my lang (vietnamese) in Xwindow enviroment (LANG=vi_VN.UTF-8
startx).

 

I mean, the system can display correctly menu,
desktop items, warning messages... – all with Unicode (ISO10646) fonts.

(I made myself translations for some small utilities,
ex: gnumeric, gedit, ..(*.po; .directory files) – and
of cource using the UTF-8 format)

 

Followings are settings on my box

 

+ For Xfree86 config files (/usr/X11R6/lib/X11/locale):

locale.dir -> I inserted: en_US.UTF-8/XLC_LOCALE:
vi_VN.UTF-8 

locale.alias -> I did nothing

compose.dir -> I inserted: en_US.UTF-8/Compose:
vi_VN.UTF-8 (The Compose file is the good one received from MandrakeSoftGroup - [EMAIL PROTECTED], but I think the
“Compose” file is not critical here. It’s main role is just for typing issue –
Maybe I’m wrong ??)

 

+ For locale definition at libc level

localedef -i vi_VN -f UTF-8 vi_VN.utf8

(vi_VN and UTF-8 files: already included with RedHat
distro CD sets: They reside in /usr/share/i18n/locale and
/usr/share/i18n/charmaps respectively)

 

+ For default LANG at startup

/etc/sysconfig/i18n -> LANG=vi_VN.UTF-8

 

Now I’d like to switch to RedHat7.2 (Xfree86-4.1.0;
glibc-2.2.4) cause they say: RedHat7.2 is capable to
support wider range of both:

VGA and soundCards.

 

But things go stranger when applying configurations
mentioned above -> newly installed RedHat7.2 system.

Instead of real
unicode characters, Xwindow just displays the coresponding UTF-8 strings (the problem happenned
with all accented unicode characters). For example:

 


 : "ừ" U1eeb -> ừ

(uhorn <-> U01b0)

 

Trying a
while, I found that: vi_VN files included in RedHat7.1 and RedHat7.2 are so different
(by using ‘diff’ utility). Maybe it’s a reason ??

Can anyone of
you point me the right way??

 

 

The second
thing annoying me so much during last 3 moths is: “Tying unicode characters in
Xwindows – with LANG=vi_VN.UTF-8” (on RedHat7.1: Xfree86-4.0.3;
glibc-2.2.2)

Here is a
configuration I made for xkb 

/etc/X11/Xf86Config -> {

#XkbDisable

 

XkbKeycodes "Xfree86"

XkbTypes    "default"   

XkbCompat   "default"

XkbSymbols  "us(pc101)"

XkbGeometry "pc"  

XkbRules    "xfree86"

XkbModels   "pc101" 

XkbLayout   "vn_utf8"   

}

(Typing mode is based on keysym combinations defined in “Compose”
file:  + something;  + something)

 

When starting X with LANG=en_US.UTF-8 -> I can type, and have
correct unicode characters displayed in serveral apps: Mozilla, gnumeric,
OpenOffice, ...

 

But If I start X with LANG=vi_VN.UTF-8 -> all accented
unicode characters I typed  are being displayed in form of corr UTF8
strings – in all apps, except OpenOffice (stranger ??)

 

I wrote to [EMAIL PROTECTED],
got some good tips to cope with it. But the final solution is still somewhere
in the “AIR” 

 

(I don't
mention here the file "/usr/X11R6/lib/X11/xkb/symbols/vn_utf8"
(including key, dead_key definitions for xkb) as it works very well in
en_US.UTF-8 env.)

 

Any tips for
this issue ??

 

 

 

 

Nguyen quoc
Binh

 

 

 

 

 

 

 

 

Re: [I18n]xterm to invoke luit

[Tomohiro KUBOTA]

Hi,

At 31 Jan 2002 13:28:22 +,
Juliusz Chroboczek wrote:

> Hi Tomohiro,
> 
> I agree with the general idea.  I would like to change a few details.

Thank you.  I tried implementation last night and it is working
almost well.

> I would suggest one new resource:
> 
>   XTerm*utf8Filter: /usr/X11R6/bin/luit

I added it, with name "localeConverter".  (I prefer to use "locale"
in the keyword, than to use "utf8".  Thus, "localeFilter" would be
also OK.)

> If utf8Filter is set, and XTerm is in UTF-8 mode, XTerm will spawn
> 
>prog args
> 
> instead of 
> 
>   prog args

Yes, but I am using "locale" now.


> In addition, I suggest that the utf8 resource should be changed to a
> tri-valued flag: it can be false, true, or auto, the latter meaning
> that XTerm should run in UTF-8 mode if the locale is multi-byte, and
> in eight-bit mode if it is not.

A good idea.  In "auto" mode, luit should be used not only in multibyte
encodings but also in combining-character encodings such as Thai TIS-620
(ISO-8859-11).

An another idea is that luit should be used in all non-ISO-8859-1 locales
in "auto" mode, or to prepare two different "auto" modes.  It depends
on whether people from various countries tend to hope to use luit or
to prefer manual font configuration  (For example, Russian users have
to write resource to use Russian font unless using luit).  It is a
tradeoff between convenience and performance.

> The defaults for these resources should be
> 
>   XTerm*utf8Filter: /bin/luit
>   XTerm*utf8: auto  (or perhaps true?)

I prefer "true", but I am afraid that many people will complain
because it breaks compatibility.  Thus, "auto" is a good candidate.


> TK>  - emulate doublewidth de-facto standard for east Asian encodings
> TK>(using http://www.cl.cam.ac.uk/~mgk25/ucs/scw-proposal.html ?)
> 
> With all due respect, I refuse to implement Markus' proposal.

I know you don't like to introduce "state".  I think we can use
a subset of Markus' proporsal without state.  Indeed, all what we
have to use is "CSI 1 w" sequence.  Inserting the sequence before
each EastAsianAmbiguous character (and a few more characters written
in "Width problems" in http://www.debian.or.jp/~kubota/unicode-symbols.html)
is enough.


> TK>  - whether xterm or luit will support BiDi or not.  Usage of fribidi
> TK>may have license problem (like Robert Brady's patch).
> 
> My personal opionion is that BIDI belongs above the terminal emulator.

Though I don't have enough motivation to discuss on this point because
I am not a native speaker of RTL/BIDI languages, all people who speak
Arab/Hebrew who I know wanted terminal emulators to support BIDI (though
only a few people).  If these people really want it, it would be these
people's labor to persuade you (and others with same opinion).


> And the number 1 item: include your fix for SS in EUC-JP (actually a
> slightly improved version).

Yes.  However, I don't know how to improve my patch.  Do you have
any idea?

---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to I18N"  http://www.debian.org/doc/manuals/intro-i18n/
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n