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/
"Introduction to I18N" http:/
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 happy hearing you like my patch. :-)
> Here is a
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 happy hearing you like my patch. :-)
Here is a new patch. I erased all static variables from
other.c as I wrote in the last mail.
>
TK> I wrote a new patch by following your advise.
That's really cool; thank you so much.
Unfortunately, I do not have time to review it right now; I know how
frustrating it is to get no feedback, but please be patient for a few
days.
Juliusz
_
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
> bit of effort to make the ISO 20
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
TK> You mean, is->other should be a fifth slot (G0, G1, G2, G3, and other)?
Yes. is->other should be a pointer to a Other charset.
TK> And, I don't know how 'return to previous charset' escape sequence.
TK> Does ISO-2022 or luit have save/load or push/pop behavior on charsets?
Here's my unders
Nice one. Thanks a lot.
A few minor objections, though.
First, the right term is not ``nonfontenc'' -- you do use fontenc in
the GBK code. The right term should be ``other'', following ISO 2022
terminology.
I don't agree with the way you reuse the Ck slot for an ``other''
encoding; the way yo
