re people such pattern
recognition and guessing, nobody would not use X for serious purpose.
foR ExaMPle, I Don'T wAnT TO wrITe mY RepORT TO mY bOsS iN Such A
FunNy (eVEn iF READabLe) TeXT.
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
se and Korean characters.
Thus, if someone wants to develop a unified international font, it
must be Japanese style (if Chinese and Korean people agree).
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
___
I18n mailing
rmacs=\E(B:
(enacs is not needed). It works for all encodings including
legacy 8bit, legacy multibyte, and UTF-8.
I would like Thomas to adopt Juliusz's very simple solution.
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
__
w about how XKB is handled (because I am Japanese
speaker and XKB is not useful for CJK = Chinese, Japanese, and Korean),
I think it is a good idea to submit the file to i18n@xfree86 (here) to
be checked by experts and then to patch@xfree86.
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
ert of XIM.
It would be better if you could modify not only Xutf8LookupString
but also X{mb,wc}LookupString.
And, please, please test with existing XIM servers and existing
XIM clients (not only xterm but also xedit, kterm, rxvt, and so
on because xterm's XIM implementation is somewhat spec
f them. However, if you think it is not impossible,
please go ahead.
When you really try to modify XIM clients like above, pleaswe
don't forget to test the modified XIM clients with east Asian
XIM servers like kinput2 and xcin. East Asian people are
tired to find some softwares cannot use eas
ry few application softwares will
support XIM.)
---
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
ed?
(Note that Kinput2 itself must be run under ja_JP.eucJP locale.)
---
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
Hi,
At Wed, 02 Oct 2002 14:13:40 +0900,
Tomohiro KUBOTA wrote:
> Are there no objection? (I waited about three months...)
> Then I will send this to patch@xfree86.
I did, and got seq: 5416.
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introducti
aviors can be possible technically. I don't have
any opinion on which behavior should be implemented (or should be
default if both will be implemented). I think it is a good idea
to consult people who wrote bash-2.05b i18n patch about Thai people's
expectation of BACKSPACE key b
uld be added for character-element-based
movement of your 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
[E
Hi,
At Sun, 15 Sep 2002 11:05:18 +0900,
Tomohiro KUBOTA wrote:
> I wrote a patch for XTerm to add font configuration set
> for UTF-8/locale modes.
No objection for this to be sent to patch@xfree86, too?
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
&quo
Hi,
At Fri, 05 Jul 2002 00:44:23 +0900,
Tomohiro KUBOTA wrote:
> Hi,
>
> At 04 Jul 2002 13:40:59 +0100,
> juliusz chroboczek wrote:
>
> > TK> I wrote a new patch by following your advise.
> >
> > That's really cool; thank you so much.
>
> I am h
se read
http://www.cl.cam.ac.uk/~mgk25/unicode.html
Please note that there are softwares which promote themselves as they
can use Unicode while they can use only a small subset of Unicode.
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to I18N" http://www.
Bash-2.05b is aware
of this behavior and, when BACKSPACE key is pressed after
doublewidth character, bash issues 0x08 0x08 0x20 0x20 0x08 0x08
to the tty to erase the whole doublewidth character. (It is
more complex in real, to handle line folding.)
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
h
version of xterm with CVS version of luit, invoking
xterm in one of ISO-8859-15 locales will be OK.
(You will need "XTerm*Locale: true" resource.)
You will need Unicode font (either non-antialiased or antialiased).
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kub
r other UTF-8-based locale) by
editing /etc/locale.gen and invoking /usr/sbin/locale-gen ?
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/
___
e no support for multibyte characters nor combinig/doublewidth
characters.
PS. The current CVS version of XTerm can handle combining characters
of Thai in TIS-620 encoding, by using CVS version of luit. If you
have to run softwares with such problems, this may partly help you.
---
, like "uFont", "uFont2", "uWideFont4", and so on.
I think the second one is better, though the first one is simpler and
not very harmful. However, I don't have enough time to work on these
solutions.
Any comments?
---
Tomohiro KUBOTA <[EMAIL PROTE
10646-1 fonts which
are shipped with XFree86. If you want to use CJK doublewidth
characters (I am sure you want to do), there are some limitation
on font selection. Please see the above web page for detail.
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubot
Hi,
At Thu, 18 Jul 2002 11:41:18 +0900,
Tomohiro KUBOTA wrote:
> Here is a patch for xterm to call luit to support LC_CTYPE locale.
> This patch was discussed in i18n@xfree86 mailing list. Please
> refer the following messages and replying messages for them.
I got patch seq numbe
LAP^%P-5TI2&-&RC:LR`0"B
M,;T:PR",Z9-07A%(('^$:\XA8DV>5KP(6<[,-_PGY&ND^S)ZPQFBN0=Z_+!<
M052AE_6>U#G):Y_+-"]B3%VQ^4"]@FM'G5G`*H470T`R8\H>S0QJF"CYIF04
MTW@B'GPN;8;RCVT-9\A!PU*?XWW'/+:['!:/[3_S6(S#:1;C[XVKLBSV@
There are also several terminal emulators which are sensible to
LC_CTYPE locale.
Rxvt (version 2.7 series)
Eterm (version 0.9.2 series)
mlterm
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to I18N" http://www.d
]OAT9`D5P:
MK6L@!IW4B_8B=.O)<^Q:V5W/5M9=](HI%EI.HDS<7U52[J\J3[B_JJ3Z;LK=
MW,8%!2Y]PWF51N#@3/FDHH0UQNV@/];46J5&`_]6&ROQ>IPB[O[E8W>]P@MC
MF,&Z^_R,7PLB+\+%)!X>,NSIV\FZ8]FS/!Z1HC<].]"/8Z/7[J,5CV][77B"
M'BQI[#]=KX=9N9^C#12DG*`2X2"\@80-0ZL#'A'%
ople know well, because developer(s) of IMdkit
are now working in Li18nux. Please check the following URL.
http://www.li18nux.org/subgroups/im/
Please not I am not a member of Li18nux.
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to I18N" htt
Hi,
At Thu, 04 Jul 2002 02:06:33 +0900,
Tomohiro KUBOTA wrote:
> I wrote a new patch by following your advise.
> I also added SJIS as a new "OTHER" encoding.
I forgot the following point:
> Finally, I object with the stacks being static. I've gone to quite a
> bi
Hi,
At 29 Jun 2002 10:45:55 +0100,
juliusz chroboczek wrote:
> Yes. is->other should be a pointer to a Other charset.
I wrote a new patch by following your advise.
I also added SJIS as a new "OTHER" encoding.
begin 644 luit-utf8-20020606-2.diff.gz
M'XL(".4I(ST"`VQU:70M=71F."TR,#`R,#8P-BTR+F1I
Hi,
At Thu, 20 Jun 2002 01:18:53 +0900,
Tomohiro KUBOTA wrote:
> Ok, here is a patch for gbk-0.enc to fix problems. Unicode PUA
> characters are not removed.
I just sent the patch to patch@xfree86 and seq 5313 was given.
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.o
Hi,
I found curious mappings in ksc5601.1987-0.enc.gz file.
For example,
0x30C1 0xCF02
appears in the file. Since KS C 5601 is an ISO-2022-compliant
94x94 character set, 0x30C1 must not appear. Can someone explain
the origin of such curious mappings?
---
Tomohiro KUBOTA <[EMAIL PROTEC
essing). If it
is just impossible, I will ignore this problem
---
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
ional codepoints to U+E7xx and U+E8xx,
which CP936 does not have. I don't know how to handle these
codepoints. (left unremoved?)
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/
__
|9|A|B|C|D|E|F/)) {
print $_;
}
}
The script reports that gbk-0.enc.gz has 119 such bugs.
Is this already-known bug or is anyone working on this bug?
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to I18N" http://www.deb
Hi,
Here is a new patch.
- Default of "locale" resource is changed from "true" to "false".
(I still have no idea which is the best... See below.)
- Locale-related resource set-up is separated from VTInitialize()
to a new function VTInitialize_locale().
- Added "vi" (Vietnamese) for luit-u
locale_string, rather than directly
> doing a strcasecmp on the argument?
I thought strcasecmp was not portable...
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/
countries such as Thai and Vietnam
are also.
Thus, I think hard-coding of "th" and "vi" is a good way so far.
And also, I heard that systems without locale (with X_LOCALE)
do not have MB_CUR_MAX. If it is true, we also have to have
a fallback for this.
---
Tomohiro KUBOTA <[E
e names. However, this algorithm does not work well for
Thai, for which I'd like to use "3. UTF-8 with luit" behavior.
Do you have any idea to include 8bit encodings which need
special processings such as combining?
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/
C-JF`I18#A8\T$4Q^T\O9-9R+M]VP
MR]SE%*HB=ZO:;DDEJ@;=M&X"9M0:)2C)^*2,Z'%)ZP`MZZ"SJRP+Y::QA?L(
M6N)I<=@1?MQY(UU0.>G"%6AKS\1F3+^Y!]I59/?\F=X,'LG4>`OHH,<(0-XL
M`"=G.6D3!'`0'/A@>DQ6!DH-O%8%PK'/'4]5*`B]?7DI])1(GTMOB
;s command line argument handling (#5173, Tomohiro Kubota).
Though I don't have a copy of the patch nor ack from XFree86, I think
the comment says about
http://www.xfree86.org/pipermail/i18n/2002-February/002990.html
http://www.xfree86.org/pipermail/i18n/2002-February/002993.html
because it is
Hi,
At Tue, 05 Feb 2002 13:34:29 +,
Markus Kuhn wrote:
>
> Tomohiro KUBOTA wrote on 2002-02-05 07:41 UTC:
> > Markus, why don't you contribute your 12x13ja font to XFree86?
> > I mean, your version of 12x13ja has much more glyphs (for example,
> > Hangul) than
11/locale/locale.alias .
However, since I think X locale is _only_ related to LC_CTYPE,
we don't need en_US.UTF-8 but we need one universal UTF-8 locale
for X, just like /usr/X11R6/lib/X11/locale/iso8859-1 defines
all ISO-8859-1 locales. (Please correct me, since I feel I
may be wrong.)
---
T
.3 . Also, the patch includes some bugfixes
which should be adopted as soon as possible (like 002993.html).
I think Juliusz has already sent these patch to patch@xfree86, as I
did for my patches. When will these patches be adopted?
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debi
O-2022 parser and this causes garbage characters. Thus,
it is a present problem, not a future problem with future xterm+luit.
Thus, I hope this situation will be fixed as soon as possible.
And more, I think that leaving enacs/smacs/rmacs definition will
mislead terminal-emulator-developers.
Thom
package. The question (and auto building
of chosen locales) will be available by typing "dpkg-reconfigure locales"
by the root user.
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/
_
ncodings.
How can we change the definition?
---
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
mmunication" problem -- control code to specify doublewidth
character. If "luit" approach were not taken and XTerm itself were
have locale encodings support, such problems didn't appear.
I don't like "GNU screen" analogy. This is because "GNU screen"
ill agree that Xterm will
support Bidi, as Nadim is afraid... Without such consensus, any
discussions will be futile.
I remember that Markus and Juliusz have expressed an objection for
Xterm to support Bidi. Is it true even now?
PS. [offtopic] Juliusz, could you please release a new versio
emember these fonts have '-*-iso8859-1'
names, which is a bad idea against the idea of FontSet.
---
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
#x27;t have enough
skill (I am relatively a newcomer to this list).
Though there are a few projects to support "complex" languages like
Pango (http://www.pango.org/ it is not living now?), I think ST project
(http://stsf.sourceforge.net/) is the one which you may like best.
---
Hi,
I got patch sequence number 5182 for this patch.
At Sat, 16 Feb 2002 16:10:14 +0900,
Tomohiro KUBOTA wrote:
> Here is a patch for xterm to support various encodings by using
> "luit". Discussion was done in the i18n@xfree86 mailing list.
> http://www.xfree86.org/
Hi,
Here is a patch for xterm to support various encodings by using
"luit". Discussion was done in the i18n@xfree86 mailing list.
http://www.xfree86.org/pipermail/i18n/2002-January/002947.html
The patch I am sending now is a slightly modified version of
http://www.xfree86.org/pipermail/i18n/2002
Hi,
I got a patch sequence number of 5181 for this patch.
At Sat, 16 Feb 2002 10:45:29 +0900,
Tomohiro KUBOTA wrote:
> Here is a patch for the manual page of luit, which should
> accompany with the previous patch #5177.
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.o
" name"
Set the child's name (as passed in argv[0]).
+.TP
+.BI \-encoding " encoding"
+Set up
+.B luit
+to use
+.I encoding
+rather than the current locale's encoding.
.TP
.B +oss
Disable interpretation of single shifts in application output.
---- till here
---
Tom
Hi,
At Thu, 14 Feb 2002 11:45:25 +0100,
Pablo Saratxaga wrote:
>
> Kaixo!
>
> On Thu, Feb 14, 2002 at 02:37:46PM +0900, Tomohiro KUBOTA wrote:
>
> > Robert Brady's patch to be merged into the xterm. One is license
> > problem; Robert's patch contain
t can be used
from other terminal emulators and it can keep source code of xterm
simple. Though the latter can be achieved by careful implementation,
the former cannot be achieved by monolithic xterm with bidi support.
Thus, I think one solution is to develop FriBidi-like library
with non-problem
bandoning kanji (using hiragana) or abandoning all of
kanji, hiragana, and katakana (using Latin script). Such scholers
are today completely ignored in major Japanese language.
I read somewhere an interview of such scholers. The interviewer
noted that even such scholers used kanji for int
Hi,
Thank you for checking my patch.
At 11 Feb 2002 17:54:58 +,
Juliusz Chroboczek wrote:
> Unless I'm missing something, there's a bug: -encoding should set up
> inputState in addition to outputState (keyboard input).
I think it is OK because mergeIso2022() is called after parseOptions()
plement "-encoding" in, at least, near future.
(I also think "utf8" resource for Xterm is not a very good idea, also,
from exactly the same reason. How do you think about this?)
> TK> Another improvement is to accept UTF-8 locales.
> Yep. I'm planning to do that
" are welcome,
but not "auto".
- Resource of "locale: UTF-8" is equivalent to "utf8: true", which
is already implemented in the last patch. Similary, other encodings
will be available here, like "local
;xterm*locale: eucJP".)
Another improvement is to accept UTF-8 locales. In such case,
luit will work as "doing-nothing-filter". This will simplify
the needed work of caller of luit. (So far, the caller of luit
has to check UTF-8 locale whether to call luit or not.)
---
To
Hi,
At 04 Feb 2002 19:19:44 +0100,
Juliusz Chroboczek wrote:
> Please find attached an implementation of an obscure ISO 2022 feature.
> According to Tomohiro Kubota, this is needed for proper support of the
> EUC-JP character set, and probably other EUC thingies.
This patch doesn&#x
Hello,
During I am trying to implement "luit -- " in xterm,
I found that luit doesn't work with "luit "
while it works well with "luit ".
Here is a patch to fix this. Juliusz, please check my modification
is right or not and send it to patch@xfree86.
--from here
diff -ruN luit-2002020
Hello,
Markus, why don't you contribute your 12x13ja font to XFree86?
I mean, your version of 12x13ja has much more glyphs (for example,
Hangul) than corresponding font in XFree86. It will benefit
Korean people who will use XTerm in UTF-8 mode (or with luit).
License problem?
---
Tom
you think is best.
PS. I would be glad if you also release corresponding luit-0.x
series which can be compiled without XFree86 4.2, because it is
easier to test by people who have not installed XFree86 4.2 yet.
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.deb
trol sequence and
use it until release of XFree86 4.3 because we will need debug
period.
---
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
-579,7 +594,12 @@
}
code = *s;
} else {
-charset = GR(is);
+switch(is->shiftState) {
+ case S_NORMAL: charset = GR(is); break;
+case S_SS2: charset = G
quot;ISO8859-11", 0, 2, "ASCII", NULL, "ISO 8859-11", NULL},
+{ "TIS620", 0, 2, "ASCII", NULL, "ISO 8859-11", NULL},
+{ "ISO8859-13", 0, 2, "ASCII", NULL, "ISO 8859-13", NULL},
+{ "ISO8859-14&q
Hi,
At Fri, 01 Feb 2002 13:21:00 +0900,
Tomohiro KUBOTA wrote:
> Thank you. I tried implementation last night and it is working
> almost well.
Here is the patch.
This patch adds following command line options:
-/+lc to turn on/off calling "luit"
--lcc to specify path
uld 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
support it. See his message at
http://mail.nl.linux.org/linux-utf8/2001-11/msg00093.html
for detail.
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/
_
)
- whether xterm or luit will support BiDi or not. Usage of fribidi
may have license problem (like Robert Brady's patch).
However, my work above will be able to be started without waiting
for conclusions of these discussions.
Any comments?
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
h
Hi,
At Mon, 21 Jan 2002 11:24:05 +0900,
Tomohiro KUBOTA wrote:
> I propose to remove these alias names. For people who really need
> compatibility to HPUX system (though I don't think there are any
> such people, because these locale names are aliases), some instructions
> ho
Hi,
At Mon, 21 Jan 2002 19:18:09 +0900,
Tomohiro KUBOTA wrote:
> I found the 2nd public review of Li18nux Locale Name Guideline
> has started.
>
> http://www.hauN.org/ml/b-l-j/a/800/840.html
> http://www.li18nux.org/subgroups/sa/locnameguide/index.html
One important note. I
Hi,
At Thu, 17 Jan 2002 12:19:52 +0900,
Tomohiro KUBOTA wrote:
> I found that xc/lib/Xt/Converters.c calls XCreateFontSet()
> few times and the parameter for it is not appropriate.
I submitted a patch. (#5152)
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.o
Hi,
I found the 2nd public review of Li18nux Locale Name Guideline
has started.
http://www.hauN.org/ml/b-l-j/a/800/840.html
http://www.li18nux.org/subgroups/sa/locnameguide/index.html
The page says that comments are welcome until 14 Feb 2002.
Any additions from Li18nux insiders?
---
Tomohiro
re aliases. Use the original names or other aliases
and people will be happy.
I am planning to propose similar thing for GNU libc's locale.alias
file.
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to
ot; in order to use any fonts if available.
I think it is a mess to prepare a long long list of patterns in order
to get slightly better proportion. I am now using a modified version
of Xt for a few days and it seems to work well without any side effects.
Any comments?
---
Tomohiro K
Hi,
At Tue, 15 Jan 2002 08:33:13 +0900,
Tomohiro KUBOTA wrote:
> Sorry, I found my patch causes luit to abort silently when I try to
> display JIS X 0201 Kana (G2) in EUC-JP. I don't know why. Thus,
> I'd like you to check my patch carefully (please don't simply subm
't know why. Thus,
I'd like you to check my patch carefully (please don't simply submit
my patch).
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/
___
Hi,
At Sun, 13 Jan 2002 03:12:44 +0900,
Tomohiro KUBOTA wrote:
> I think luit uses JIS X 0212 (i.e., G3 character set) via GL.
> This is not true. EUC-JP uses JIS X 0212 via GR.
I think I found the reason. In luit, SS2 and SS3 are implemented
to invoke G2 and G3 to GL. However, I hav
S X 0212 demo. http://www.pps.jussieu.fr/~jch/software/luit/
though this page is not available now...
---
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
Hi,
At Wed, 09 Jan 2002 18:07:03 +,
Markus Kuhn wrote:
> .. unless an explicit subrange specification is present, such that
> people have to write
>
> *-iso10646-1[0_0x]
>
> if they are sure that they want to have the full font.
>
> In other words, allow the specification of a defau
uot;
font as a default. CJK people don't want to suffer from such foolish
developers (and the foolishness is common, not a rare case). The
limitation of glyph range can offer a new method to annoy CJK people,
if no mechanism to avoid the limitation on needed cases are supplied.
---
ocale-
enabling), I got "bug" reports from such people like "i18n is only
for asian people and please stop doing i18n in the upstream level"
and I was forced to write a code to manage locale-ignorant people.
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.d
is having this
> input ability without messing up the locale. I still want a C locale.
It is illegal.
If you really want to do that, replace ISO-8859-1 fonts with ISO-8859-15
fonts. You can get an illegal but working system.
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~k
also
a large group. However, in the Open Source Software world, most of
developers don't think about supporting such languages. Even with
such huge popularity of BiDi + CJK + Indic + ... , we are still a
minority in Open Source World. Thus we have to improve our situation
by ourselves.
ls such as Linux console. For such cases, libraries such as
curses may supply BiDi support, though I don't know this works well
or not.
For my case, Linux console doesn't support Japanese. Thus, I have
lines like:
if [ "$TERM" = "linux" ] ; then
LANG=C
el
~jch/software/luit/
http://www.cl.cam.ac.uk/~mgk25/unicode.html#xterm
However, they are not native speakers of RTL languages and I think
native speakers' opinion should be respected.
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to
are assumed to be run on
non-BiDi-supporting terminals or they use display-order text file.
I'd like also to ask native Arab speakers on this point. Note that
mlterm supports Arab shaping also. Any comments?
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introdu
support should be enabled
by default or should be disabled by default?
mlterm: http://mlterm.sourceforge.net/
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/
__
you will be interested in joining the English mailing list.
---
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
pe fonts. I observed that nothing is displayed
when I try to display True-Type fonts using Xft in the size that the
font has built-in bitmaps for.
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to I18N" http://www.debia
't know how deeply Thai people depend on the de-facto
standard of fonts.
Of course, if Thai people think the modification of the fonts doesn't
cost very much, we (people from all over the world) can attend the
discussion on the detailed technical design of Thai fonts.
---
Tomohiro KUBO
ome recommendation? (though I have not read the document yet).
Unicode Standard Annex #9 The Bidirectional Algorithm
http://www.unicode.org/unicode/reports/tr9/
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to I1
that tis620-0
font is slightly different from tis620.-x fonts. Combining characters
in tis620-0 fonts have negative expand (i.e., glyphs are written leftward
from the specified location) while all characters in tis620.-x fonts
are exactly fixed-width. Can we rely on the structures of fonts?
am web page of
mlterm is:
http://mlterm.dnsalias.net/ken/mlterm/mlterm.shtml
Note that "tis620-0" fonts are not supported yet.
Of course I'd like to read reports from people from other countries.
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
.cvs20010801
xfonts-intl-asian 1.2-2
xfonts-thai-nectec 2526-2
---
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
ible for this
problem. Since I don't know at all about TrueType font format,
I cannot check it.
Kochi Gothic and Kochi Mincho fonts:
http://www.on.cs.keio.ac.jp/~yasu/jp_fonts.html
Though this page is written in Japanese, I think you can easily
find .tar.bz2 files for kochi-gothic and koc
lyphs whose widths are
exactly equal to the specified XFT_WIDTH.
This behavior is not documented. Is it an intended behavior?
In other words, can I rely on this behavior when I write a
softwares which use Xft?
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Intr
manuals or documents on specification of Xft API?
---
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]
ht
don't think that will be much of a problem. If it is, we'll see
> what can be done.
Sure. If we will single shifts only, we can have more simple
sequence.
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to I18N" http://w
1 - 100 of 122 matches
Mail list logo
