EW I have written an xkb file for Upper and Lower Sorbian
Wow.
(bugzilla.xfree86.org.)
Juliusz
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
MK The X.Org Foundation has given me access to their CVS just last week to
MK ammend the X11 protocol specification and to make this convention
MK official. I was on a phone conference with them last Monday and they all
MK agreed that adding the 0x0100 convention to the standard would be
MK
AK while trying to develop a keymap which includes mathematical symbols, I am
AK wondering about the exact status of the UCS keysyms 0x0100 and
AK above... Are these already standardized?
They are under discussion at X.Org.
AK Do any X servers except XF86 currently use them?
You can use
YL 1. To my knowledge the gb18030.2000-0 and gb18030.2000-1 encodings are
YL invented by Sun and used in their Solaris 9. The only application on Linux
YL that supports them is Mozilla (maybe Java1.4 as well?) at the request of
YL Sun (see mozilla bug 72525). IMHO, if you want to extend the system
A I tried to install Lao OT fonts and got the following error message.
A (none):/usr/share/fonts/defaults/TrueType# ttmkfdir fonts.scale
A unknown font foundry code JG
A unknown font foundry code LSW
The fonts use font foundry codes that were not registered with
Microsoft. Both ttmkfdir and
IP And I still doubt is the ASCII characters a special case or they
IP should be processed in the same way.
From your description only, it does indeed sound like there's no
reason to treat ASCII separately. If you've got the time and
inclination to do so, you could wait until 4.3.0 is out, then
Wow. Could you please explain what's going on here?
Juliusz
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
'A knot!' said Alice. 'Oh, do let me help to undo it!'
Could you please put an xscope dump on the web somewhere ?
Thanks,
Juliusz
P.S. You'll find xscope on http://keithp.com/~keithp/download/ .
___
I18n
ES -- for example, Arabic-Indic numbering, plus, minus, Arabic shadda to
ES name a few.
ES Would be it safe to assume that those charactes should be assigned a
ES unicode codepoint instead of directly going to keysymdef.h?
No.
If a key has an ad hoc keysym definition, it *must* use it for
DW Is there a definitive way to determine what character
DW encoding XmbLookupString() is going to return text in?
You cannot. That's the whole point of the CSI ideology.
(Code Set Independence. n. The notion that a client is not supposed
to know anything about the character encoding.
But my question is always unanswered.
Will Xutf8LookupString supports Unicode KeySyms without strings
Good question. I've always assumed it did, but I've really got no
idea.
JL So can I modify the X11 Xutf8LookupString function ?
If it doesn't have this functionality yet, go for it, by all
TK So far, XTerm uses *-iso8859-1 fonts as default. Though the
TK default settings have been good, I think it is not always good now
TK or in future, because current XTerm supports UTF-8 mode and it can
TK activate UTF-8 mode automatically.
Currently, there are two defaults files for XTerm,
KP While I've never seen ñ in my limited exposure to French,
Neither have I (with over 20 years exposure to the language). I
suggest you remove it -- it's not in the Adobe Standard encoding, so
some fonts may lack it.
KP The only questionable thing I believe I've done is to eliminate the OE
ZL Under X, you may want to follow XIM (the mechanism you are asking)
ZL to implement a input method server.
No, you don't. XIM is a morass of complexity which should only be
used for scripts that need it. Avoid its use for simple alphabetic
scripts.
BB xterm -u8 -fn \
BB -misc-fixed-medium-r-normal--16-120-75-75-c-0-unicode-0 \
BB -e luit -g2 'GB 2312'
BB the xterm will display chinese but the xterm is somewhat insane.
BB the text is spread out to a follows
BB should be:-test
BB is :-t e
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
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
JS For jisx0212.1990-0.enc and gb2312.1980-0.enc, FIRSTINDEX should be
JS be '0x20 0x20'. For gbk-0.enc, it appears to have to be
JS '0x81 0x40'.
I'd rather you sent the patch -- this way, you'll become the contact
person if something's wrong. You're doubtless better qualified than I
am to do
Hi,
While testing the FreeType 2 backend the other day, I noticed that
quite a few of the matrix encodings in fonts/encodings/large still
fail to include a FIRSTINDEX line. I'm wondering if somebody
competent could fix that.
(FIRSTINDEX lines should *not* be included in linear encodings.)
TK XFree86's table has additional codepoints to U+E7xx and U+E8xx,
TK which CP936 does not have. I don't know how to handle these
TK codepoints. (left unremoved?)
I suggest going ahead and removing them. If somebody complains, we'll
know what they are for.
TK I have to study about your suggestion and how to use
TK XtAppAddConverter.
Don't bother, then. Just encapsulate the parsing into a separate
function (the code is already spaghetti-like enough).
Why do you copy the argument into locale_string, rather than directly
doing a strcasecmp on the
Nice work. Just a few minor comments.
I would suggest modularising the parsing of the argument. The
officially sanctioned way is to define a converter, say
CvtStringToTristate, and register it with Xt. See lib/Xt/Converters.c
and man XtAppAddConverter(3x). Or modularise it by hand (just
JS I had to make up ko_KR.UTF-8 different from en_US.UTF-8 to make my
JS transition to ko_KR.UTF-8 work as I intended.
Fair point.
Of course, the long-term solution is to use font technologies that do
language-dependent and contextual font and glyph substitution.
Client- or server-side.
WKP STARTMAPPING unicode
WKP -UNDEFINE 0 0x
WKP +UNDEFINE 0 0xFEFE
This doesn't make sense to me. What is it you're trying to achieve?
Juliusz
___
I18n mailing list
[EMAIL PROTECTED]
TK It defines alternate character set-related capabilities like:
TK enacs=\E)0
TK smacs=^N
TK rmacs=^O
TK which are indeed using G1 of ISO-2022. This works well for 8bit
TK encodings which use G0 and G2. However, G1 is used in several
TK encodings such as EUC-JP and EUC-KR. Thus,
NS - What are your comments on mlterm, patch27, biditext (have you
NS used 'em) ?
I haven't, as I don't speak any Semitic language. Which is exactly
why I cannot make up an opinion before I see a description of what
they are supposed to do.
NS - Irrespective of various minor issues, what
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
filter prog args
instead of
¸
A best-effort text printer
Juliusz Chroboczek
Cedilla is a simple text printer that uses Unicode internally.
Using Unicode means that the set of characters that can appear in the input
is very large, and the user may
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 glyph
set for Arabic. While this glyph set is suitable for some simple
styles of Arabic typography, there is enough variation in
typographical
Tomohiro KUBOTA [EMAIL PROTECTED]:
TK I think I found the reason. In luit, SS2 and SS3 are implemented
TK to invoke G2 and G3 to GL. However, I have read a textbook that
TK SS2 and SS3 are re-defined by ISO 2022 to invoke G2 and G3 to
TK _both of GL and GR_. I imagine this modification is for
MK You could for example simply cut the Unicode character space into 16
MK intervals 0x0XXX, 0x1XXX, etc. and open each interval as soon as you
MK encounter a glyph from it.
If you are a client developer, however, it would be much more
productive, both in the short and long term, to implement
MK So I think, we can now drop bdftruncate from the ucs-fonts installation
MK procedure, as people merely have to add [0_0x31ff] to an XLFD to achieve
MK the same effect.
MK Any opinions?
JC I don't think it is a good idea.
Sorry, I was in a rush yesterday evening and didn't have time to be
[Back to the list in case somebody knows for sure.]
xfd -fn '-misc-fixed-medium-r-semicondensed--13-*-75-75-c-*-iso8859-1[65_90]'
MK Very nice, I hadn't seen that! Works fine for my XFree86 4.0.3
MK installation here. Since which release exactly did this work?
For as long as I can
Moe Elzubeir [EMAIL PROTECTED]:
ME Seeing that I know _nothing_ about the internals of XFree86, I would
ME really appreciate alll the pointers you can offer. Ranging from
ME pieces of code that affect this to documents and papers that can help.
1. look into include/X11/Xlib.h, and
dv Let me rephrase my question: how in X can I work in an english
dv environment, but still have bindings for latin 15[1], as if I were
dv working with a french locale ?
Set LC_CTYPE to fr_FR@euro but LC_MESSAGES to either C or en_US. Set
the other LC_* variables to your liking.
(I am running
Aidan Kehoe [EMAIL PROTECTED]:
The correct solution (TM) is to use Xft rather than the core protocol
for Arabic.
AK I think his original message implied that he was considering
AK implementing font subsetting, as his first link
AK
Try
xfd -fn '-misc-fixed-medium-r-semicondensed--13-*-75-75-c-*-iso8859-1[65_90]'
MK Very nice, I hadn't seen that! Works fine for my XFree86 4.0.3
MK installation here. Since which release exactly did this work?
For as long as I can remember. I've got a 3.3.6 machine here, and it
works.
The question is whether it can be useful for a Unix shell session.
JS I'm not sure I understand your point...
Luit is designed to provide support for legacy encodings to UTF-8
terminal emulators. It is not a general-purpose encoding converter.
Viewing mails or web pages is a different
Jungshik Shin:
JS Much more useful is, although I hate to 'endorse' MS's
JS proprieatary extension, Windows-949/CP949/Unified Hangul
JS Code. There are numerous web pages and emails in this encoding
JS floating around the net disguised as EUC-KR (or a complete
JS non-sense-name of
However, XIM support imposes that we use font sets, thus pulling in
a whole new range of bugs.
TK Are you saying that nothing should be added to XTerm?
No. I am not objecting to the use of fontsets. I am objecting to the
facts that XIM (i) imposes the use of a specific output mechanism, and
40 matches
Mail list logo
