(Please do not reply to this address.)
"Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> wrote:
> How does the CJK-patch maintainers see this patch?
I'm not a maintainer of the patch but...
First note that CJK-patch is based on 1.1.4 and does not use Painter.
> I think we all would like to see the CJK-patch integrated properly into
LyX,
> but so far, the patch was a bit to rough to be included. With Dekels great
> work, it might be possible to do the CJK patch is a clean and
well-integrated
> way...
In order to support multibyte languages, at least three things have to be
implemented:
1. Input Method interface,
2. data conversion between external (saved file, user input at editing
session, clipboard,...) multibyte and internal wide character foramt,
3. screen output of the language characters.
As for 1., Kawakami-ChangGil's patch implements all the required stuffs in
(IMHO) a clean and elegant way. I think this part can be integrated into
LyX without problems.
Let me elaborate. Please notice that even if we use thousands of
characters, our keyboard has only 100+ keys. Also we do not memorize
dozens of keymap and switch them. Instead we use an Input Method
server and let them convert keyboard inputs to multibyte/wide character
strings. In fact LyX already has this capability to communicate an IM
server: XmbLookupString() called in LyXLookupString() let an IM server
to preprocess user keyboard events before they are passed to clients,
unlike XLookupString() which just delivers raw keyboard events to clients.
But the current official code has two problems. If the IM server is
external to Xlib (Xlib has an internal IM server which handles compose
key events), then it might crash or explicitely killed during a LyX
session which causes LyX to crash along with it. Kawakami-ChangGil's
patch handles this situation properly. Another problem is that the
conversion of keyboard inputs to multibyte/wide character strings may
not be unique. In this occasion, IM servers usually displays a
candidate(s) on screen and let users to choose. If the official version
is used, which actually discard all the multibyte character inputs
in LyXFunc::processKeyEvent(), then the candidates are displayed on
the root window, while CJK version let IM server to display candidates
on the LyX window at the cursor position, which is more convenient
at least for Japanese/Korean inputs.
If we are going to use Unicode as the internal format, then I agree
with Dekel's approach in regard to 2. I'm not very eager to use
Unicode as the internal format of LyX, though. Please do not take
the attached diff literary. It is only proposed here as a possible
extention to support multibyte encodings. Besides Painter::text()
and lyxfont::width() requires some modification if what you see below
is really applied.
3. is clearly addressed in Dekel's patch. However, the approach is rather
problematic from the point of view of CJK-support. My main concern is
the availability of ISO 10646 fonts. Although it shouldn't be a problem
on systems where truetype font renderers (e.g. XFree86 ver4.0 server/xfs)
are running, this is not always the case. The traditional approach on X
window system, which is portable, is to combine several font files to
make a single logical font. XFontSet is a facility offered by Xlib for
such purpose. The essential idea is that a user requests a XLFD >>WITHOUT<<
a font norm and Xlib appends font norms according to the locale:
For example, if I aliase Japanese gothic(which is in fact a sans serif) to
helvetica and requests
oc = XCreateOC(om, XNBaseFontName,
"-*-helvetica-medium-r-normal-*-14-*-*-*-*-*", NULL);
under LC_CTYPE=ja_JP, then
-*-helvetica-medium-r-normal-*-14-*-*-*-*-*-iso8859-1
-*-helvetica-medium-r-normal-*-14-*-*-*-*-*-jisx0201.1976-0
-*-helvetica-medium-r-normal-*-14-*-*-*-*-*-jisx0208.1983-0
-*-helvetica-medium-r-normal-*-14-*-*-*-*-*-jisx0212.1990-0
will be loaded and I can access the XFontStructs via
XFontsOfFontSet(oc, &FS, &charlist);
and
XmbDrawString(dpy, win, oc, gc, x, y, mb_string, num_bytes);
will draw a multibyte string automatically switching the real fonts used.
As I already noted, a quite amount of Kawakami-ChangGil's patch related
to 3. is already obsolete and must be rewritten. Also they are incorrect
in the sense that font norms are specified in XLFD. But this traditional
approach is, at least at present, much more portable than the approach
of Dekel's using a single ISO10646-0 font.
Regards,
SMiyata
begin 666 mb.diff.gz
M'XL("$+?93D"!FUB+F1I9F8`[5EM;]I($/YL_XHY*E4F-K`V&#B2]M*F29J4
MYJ(2="=%$3+V&ILZ-O)+0Y3+_?:;71N#"2@O4JH3)=H8>SSSC'=FGQVOUW)M
M&RK),(0@=$<UZIN!Y?JCZ@%<#Q>NQ$JELJPA7#@)G"8>0!-(HZ.W.KH&&B%$
ME&6Y:"X<A6ZJV@)5[6CU7'5_'RIUK:4T068_;0WV]T40[HA"[J%6`S*U;1'N
M=T40Y5JM)HRH3T/7A,-I3'V+6M#WW2D<!!:M`IR'P=`8>K=H91`P?(N;0^0$
MB6?!D`*IBG+B1^[(1TO3,4(P`S^*(3:&@^NA1_U1[`P.^P>7FMZ\@G=P)\H`
M0)17;=R'JKQJVR@?/R,?FO*J;4-\B#(R4TZ9B;2IC"=PX\8.Q`Z%TY/>WT0C
M;<[#]$+5:ME)'2@C<.0B_9[(R=/S+2LW@Y4X<NHORP?9LO+Q1F:L?./:[(*1
M\\!Q?1I1.#-BI)SA02]&6AJA!1//P#LLCVBJ-O!?YXQ5FUA0SX(8DHA:3Z3H
MQ5];BFX&11LOSL>6HD^GZ!M\A77M60'M.:X=LTJ)Q+MPW&CVWFH&/V@(>>$T
M(KBAGO<42O;0:,O(_SDC7WTDDPV)U4\OFKBTM%VDUV?#'R7>,\MA__.'L^-^
M=TN_7YU^VY7D2PLB\L\,+`H7H>%'-M;`HR"\-F)H/XE_%T?M+?E^]<\XF_*I
MJ*X\KS76-'VA-7DC\]H'A]D'6W"CH-W6?Q^H4LG#%:.OEA1&KEQ<WEVAK&7*
M6E%96ZG<R)0;1>4&*O-/PO6&4@>YH1)%)?R3\`.$5H;0*B*T"N[,B:KINE1*
M?U/-]+R@]CUPVU*)'2MAJL3.R_R%(%<:NB-=JNU`Z>-(+\%.+8I#%$ME!<[Z
MW:Z"\I-C=/%@5<Q@<I#14*NK&H<Y_K@2!<6/8-#$'(PG'`-?\%>"L(]QI^<K
M@$[/"U`16W,,QF[$T7KKX/@-Y>'BHH#U/3+U)E$YTI?UC_7EVV/]2V)[T.8P
M;!)?"<1O*`]G?,2QUNQH.(4M"6?%CH:S8D>CN7I'PUG<T="T3J/941=V--0&
MV]#`8XN/71'>N+[I)5C+2MT>[TO5*2U*O=MI:#*9G,OVL/CY/ZK.>V8?WTZH
M16W(RQZN#<,87#^&/JN`;'^$.=9:BJJ#K+65>NI:$([^_/9U\/7PT\F'+EZR
MG10!BZM8$6;QEM+H9D7T+7A*BID)=H"645OH0->(Z?3,N*8#R2N#`K-H##`-
M'I5H&>[N1?D9N#BW"0(LJ;E8L.?Y7E7G=^`:==A(*#.`)ST84\0W>XG"NP53
MP;00B0=Z$$RH+\T&EELU!_@04ID-3$&@7D3G^E)J$)<QT1T4LTZSD,K"OWG?
MR]E+!Z1NT>ZWHF'J/Q687A!1U.'.[K,$@;`4F+R7")[*[EA^0QHGH;\0`Y;A
M^SS+:<@3,Y*60CD'J>0@Q<!=FE?L@=8A["QBS,);`&!]GL=ZC8]+<L7="$5T
M)#6&>D;N!35^-TCB86)?-E(1CR+&3X&W)OZC"1Y3%3RI`TXE39Q%TERFP%*&
M0*Y@#\BT3<KP!ZC0X2.2_RUI4*ZA00?J'&86%<0BZ4,@%\?YU8WC8O\EYNP]
MC&4Y#0%7E_"XMP?-,OP#$IFV;,QMYFM\E3YC%JK$7,PE&Q!8\$Q.=)W/,*W6
JK#S.!DMQ&*1F2ZPKQ'\W'[O9V`33FLO6L"]+RFZV,0OB?\8>WWU&'@``
`
end
