sudarsana narashiman wrote:
I am Sudarsan.I tried for TAMIL LANGUAGE phonetic keyboard support in
Linux(X11R6).But Linux does not support phonetic keyboard layouts.
The current character displayed depends on the previous character
and the current key pressed.
Not only TAMIL language
On Wed, 17 Dec 2003, David Dawes wrote:
On Thu, Dec 18, 2003 at 09:37:04AM +0800, James Su wrote:
This patch fixes a bug in locale.alias which breaks the zh_CN.GB2312 locale.
I've committed both of your patches there.
Could you commit the following patch (to locale.alias) as well?
Although I
On Mon, 15 Dec 2003, Federic Zhang wrote:
Choe Hwanjin wrote:
I make utf8 text file for test. It contains utf8-encoded
ksx1001(ksc5601) chars. When I convert it to EUC-KR with iconv, no
conversion error occur.
On X environment, I made TextProperty from Xutf8TextListToTextProperty
On Wed, 12 Nov 2003, Greg Davey wrote:
* 1)Locale not supported by Xlib, setting locale to 'C'
* 2)X locale modifiers not supported, using default
You didn't tell us what your locale was when you got the error. There
are some known mismatches between Linux glibc locale names and
On Sat, 6 Sep 2003, Anuradha Ratnaweera wrote:
Let me put this in a simple point form using a hypothetical example:
Now, if I want to render character 51 of X inplace of the composite
character 4001+4010, how should I proceed? Is there a way to map
unicode sequences to actual (physical)
On Fri, 1 Aug 2003, Jungshik Shin wrote:
I'm wondering if anyone has an idea of a possible cause of
crash in _XimThaiCloseIM() apparently triggered by Flash plugin
for Mozilla (Konqueror also has a similar problem). Flash plugin
can work around this, but the crash is occuring
Hi,
I just generated the font encoding file for big5hkscs-0 (Big5HKSCS without
US-ASCII and U+0080) and uploaded to
http://bugs.xfree86.org/show_bug.cgi?id=575
It was generated from Anthony's mapping table at
http://www.thizlinux.com/~anthony/hkscs/Correct-Big5HKSCS-to-Unicode-by-b5.txt
I
On Thu, 7 Aug 2003, Mike FABIAN wrote:
Jungshik Shin [EMAIL PROTECTED] :
On Sat, 2 Aug 2003, Chisato Yamauchi wrote:
Have you seen CJK's *TYPICAL* fonts.dir of TrueType fonts?
It is following:
Not many people would be fond of tweaking fonts.dir/scale files
these days
On Sat, 9 Aug 2003, Jungshik Shin wrote:
On Fri, 8 Aug 2003, Pablo Saratxaga wrote:
That being said, it would be nice to have the ability to do
user-configuration
of glyph substitutions in gtk2; eg telling that when a given font is
choosen, then characters of range 0x00-0xff should
On Fri, 8 Aug 2003, Mike FABIAN wrote:
Jungshik Shin [EMAIL PROTECTED] :
On Thu, 7 Aug 2003, Mike FABIAN wrote:
It can be automatically generated. The /usr/sbin/fonts-config script
on SuSE Linux generates such TTCap entries automatically into the
make some people frustrated if it just
On Fri, 8 Aug 2003, Pablo Saratxaga wrote:
On Fri, Aug 08, 2003 at 06:59:43PM +0900, Chisato Yamauchi wrote:
But Gtk2 has not complete font-substitution mechanism.
Therefore, Gtk2 is insufficient in CJK environment.
GTk2, using pango, has builtin fontset mechanism.
(it is always
On Thu, 7 Aug 2003, Steve Sullivan wrote:
For example, the Terminal edit current profile gui shows
the Miriam font, but Miriam isn't listed by xfontsel or xlsfonts.
There are two separate font systems, the X11 core font system and
the client-side system with Xft/fontconfig. What you get
On Sat, 2 Aug 2003, Chisato Yamauchi wrote:
Although the pliability of handling such special fonts is also important,
non BMP plane in XLFD is now the most important problem. Confusion is
already seen such as linux-utf8 list. An official definition should be
indicated right now. Why has
Hi,
I'm wondering if anyone has an idea of a possible cause of
crash in _XimThaiCloseIM() apparently triggered by Flash plugin
for Mozilla (Konqueror also has a similar problem). Flash plugin
can work around this, but the crash is occuring in _XimThaiCloseIM()
so that there appears to be a
On Mon, 28 Jul 2003, Hans Deragon wrote:
Jungshik Shin wrote:
On Mon, 28 Jul 2003, Hans Deragon wrote:
The problem is, from my understanding, that the keyboard mapping is
intertwined with the locale. It is imperative that I use standard
locales as setup by Red Hat's preference's
On Wed, 9 Jul 2003, Yu Shao wrote:
Jungshik Shin wrote:
On Tue, 8 Jul 2003, Yu Shao wrote:
I don't get you here, the first version of the patch was made for Red
Hat 7.3, at that time we have to use Mozilla with X core font. Since
then the patch has been there almost unchanged
On Wed, 9 Jul 2003, Yu Shao wrote:
Jungshik Shin wrote:
On Tue, 8 Jul 2003, Yu Shao wrote:
I don't get you here, the first version of the patch was made for Red
Hat 7.3, at that time we have to use Mozilla with X core font. Since
then the patch has been there almost unchanged
On Tue, 8 Jul 2003, Tomohiro KUBOTA wrote:
You should have dropped either Korean (Japanese are not supposed
to understand Korean script unless they're interested in learning)
or used 'glyphes of CJK Ideographs widely used in China or Korea'
in the following.
Japanese people may even fail to
On Sun, 6 Jul 2003, Yong Li wrote:
Hi Rigel,
Thanks for your kind comments. I fully agree with you on most, if not all,
points.
1. To my knowledge the gb18030.2000-0 and gb18030.2000-1 encodings are
invented by Sun and used in their Solaris 9. The only application on Linux
As I wrote on
On Tue, 8 Jul 2003, Yu Shao wrote:
Thanks for your answer.
Because RedHat XFree86 18030 patch's compound text encoding part was
based on James Su's patch which was derived from UTF-8' code, it doesn't
really need GB18030.2000-0.enc and GB18030.200-1.enc to be functioning.
GB18030.2000*
On Tue, 8 Jul 2003, Andrew C Aitchison wrote:
On Tue, 8 Jul 2003, Yu Shao wrote:
Right now, the four Asian locales' definition in X are:
zh_CN.UTF-8 locale is using en_US.UTF-8's definition,
zh_TW.UTF-8 is using zh_TW.UTF-8
ko_KR.UTF-8 is using ko_KR.UTF-8
ja_JP.UTF-8 is using
Hi,
I sent the following to James Su to seek his opinion, but it was bounced. Now
I'm sending to 1i8n and fonts list expecting him or other Chinese experts to
pick this up.
Jungshik
Hi,
Could you make a comment on
http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=441?
On Tue, 10 Dec 2002, Anthony Fok wrote:
Thank you for bringing up this important issue.
I was assigned with the task of dealing with s p a c e d - o u t CJK
fixedPitch font issue in konsole.
In addition to Konsole, gnome-terminal, Mozilla-xft(for rendering
text/plain or a portion of html
On 10 Dec 2002, Juliusz Chroboczek wrote:
JS Even with this weakness, Xprint is by far the best printing
JS solution available at the moment for Mozilla under Unix/X11
JS because postscript printing module of Mozilla does not work very
JS well yet
JC Xprint might work for CJK fonts,
It
disabled Xprint in their Mozilla RPM.
Xft, Xprint and PS printing module can coexist in Mozilla without
much problem as far as I can tell. Perhaps, that blocking I mentioned
above may not be acceptable?
Jungshik Shin
P.S. I'm CCing to fonts list of XF86
On 6 Dec 2002, David Monniaux wrote:
Hi,
Please replace the UTF-8 Compose file referred to in patch #5495 by the
one at:
http://www.di.ens.fr/~monniaux/download/Compose_autogen.3.utf-8
Could you add to your Compose file what I sent you the other day
that is still available at
On Sun, 1 Dec 2002, Jungshik Shin wrote:
While trying to make Mozilla-Xft support non-BMP characters with fonts
like CODE2001.TTF (with pid=3/eid=10 Cmap), I found that freetype
and Xft need a little change. Details are sent to linux-utf8 list
(http://mail.nl.linux.org/linux-utf8/2002-12
On Tue, 3 Dec 2002, Jungshik Shin wrote:
Attached is my patch(a bit revised) to extend XftTextExtents16 to
support UTF-16 and to fix a typo in fstr.c of fontconfig(which makes the
conversion from UTF-16 to UCS-4 not work correctly for characters in
Sorry I forogot to attach
Hi,
While trying to make Mozilla-Xft support non-BMP characters with fonts
like CODE2001.TTF (with pid=3/eid=10 Cmap), I found that freetype
and Xft need a little change. Details are sent to linux-utf8 list
(http://mail.nl.linux.org/linux-utf8/2002-12/msg0.html) and Bugzilla
On Tue, 22 Oct 2002, Keith Packard wrote:
Thank you for your explanation.
Around 12 o'clock on Oct 22, Jungshik Shin wrote:
1. get a pattern from an application(fontconfig client)
2. apply configuration-specified editing rules to the pattern.
For each font:
3. read in font
On Fri, 18 Oct 2002, Keith Packard wrote:
Around 7 o'clock on Oct 18, Jungshik Shin wrote:
For some unknown reason, 'New Gulim' is picked up by 'fontconfig' or 'Xft'
for a certain characters when CODE2000 is explicitly requested by
applications like Mozilla and gedit (via Pango) More
On Fri, 18 Oct 2002, Keith Packard wrote:
Around 12 o'clock on Oct 18, Jungshik Shin wrote:
One possible explanation is that Code2000 isn't marked as supporting 'ko'
in font-cache for some reason while Ngulim is.
This explanation only makes sense when those two chars are NOT
included
On Mon, 14 Oct 2002, Pablo Saratxaga wrote:
Thank you for your reply.
On Mon, Oct 14, 2002 at 10:00:34AM -0400, Jungshik Shin wrote:
I've been trying to come up with Xkb and Compose for Korean Hangul.
I activated the attached Xkb file(made by PARK Won-kyu) with 'xkbcomp
Multi_key
of input modules as is possible with some XIM's and under MS Windows
and MacOS.
BTW, it'd be nice if Qt3 provides a similar mechanism.
Jungshik Shin
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
On Wed, 16 Oct 2002, David Monniaux wrote:
Thank you for compiling this up.
I prepared some UTF-8 Compose tables by automatic generation from the
official Unicode tables.
http://www.di.ens.fr/~monniaux/download/Compose_autogen.2.utf-8
I'd like people working in exotic languages to test
Hi,
I've been trying to come up with Xkb and Compose for Korean Hangul.
I activated the attached Xkb file(made by PARK Won-kyu) with 'xkbcomp
-R/usr/X11R6/lib/X11/xkb/ /full/path/3fin.xkb'. It worked fine as
intended under both en_US.UTF-8 locale and ko_KR.UTF-8 locale.
Under ko_KR.UTF-8
Since the release of a new CODE2000 font(by James Kass at
http://home.att.net/~jameskass) with glyphs for Hangul Jamos, I've
been trying to test how it works with various browsers. Mozilla
with direct access to truetype fonts works fine, but Mozilla
with Xft patch has a problem with
On Sat, 7 Sep 2002, Keith Packard wrote:
Around 9 o'clock on Sep 7, Jungshik Shin wrote:
I'm not sure adding U+115F/U+1160 to the blank glyph list is the best
way, but it works. Keith, could you consider this?
The blank glyph list is supposed to be filled with all of the Unicode
On Tue, 20 Aug 2002, Baiju M wrote:
I have created a XKB file for Malayalam languages based on the new
standared keyboard layout proposed by our govt.
Our language code is ml_IN
I have created a Compose file for mapping 5 glyphs.
So this Compose file should be included in ml_IN.UTF-8
On Wed, 14 Aug 2002, Owen Taylor wrote:
The current Korean orthography looks like a combination
of KSC-5607.1987 with the complete Hangul Syllables
area of Unicode.
I'm sorry to be 'pedantic'. Strictly speaking, this way of talking
about Korean orthography (in terms of precomposed
On Wed, 14 Aug 2002, Owen Taylor wrote:
Jungshik Shin [EMAIL PROTECTED] writes:
On Wed, 14 Aug 2002, Owen Taylor wrote:
The current Korean orthography looks like a combination
of KSC-5607.1987 with the complete Hangul Syllables
area of Unicode.
I'm sorry to be 'pedantic
On Mon, 22 Jul 2002, Keith Packard wrote:
Around 8 o'clock on Jul 22, Brian Stell wrote:
Will there be a way to get the localized name using the ascii only name?
How about the other way around? Given a localized name+lang, would
it be possible to get the ascii name? Put differently,
On Wed, 10 Jul 2002, Marius Gedminas wrote:
On Tue, Jul 09, 2002 at 06:09:01PM -0700, Keith Packard wrote:
Around 18 o'clock on Jul 9, Jungshik Shin wrote:
b) use $LANG or $LC_CTYPE?
If this road is taken, it has to be determined which env.
variables have
On Tue, 9 Jul 2002, Keith Packard wrote:
Ok, so now what do I do with applications which haven't called
setlocale (LC_ALL, )? Do I:
a) call setlocal (LC_ALL, ) myself?
I'm afraid this can have an unexpected side effect, which could
surprise/upset some application program
On Tue, 9 Jul 2002, Keith Packard wrote:
Ok, so now what do I do with applications which haven't called
setlocale (LC_ALL, )? Do I:
a) call setlocal (LC_ALL, ) myself?
I'm afraid this can have an unexpected side effect, which could
surprise/upset some application program
On Mon, 8 Jul 2002, Keith Packard wrote:
Around 14 o'clock on Jul 8, Owen Taylor wrote:
+locale = (FcChar8 *)setlocale (LC_CTYPE, NULL);
Don't you mean LC_MESSAGES?
I believe it should be LC_CTYPE. Some people like me
have the following because English menu and (error) messages
in Taiwan
or just some small (not so extensive) dictionaries supposedly used by
(elementary) school children?
Jungshik Shin
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
On Mon, 8 Jul 2002, Keith Packard wrote:
Around 14 o'clock on Jul 8, Owen Taylor wrote:
+locale = (FcChar8 *)setlocale (LC_CTYPE, NULL);
Don't you mean LC_MESSAGES?
I believe it should be LC_CTYPE. Some people like me
have the following because English menu and (error) messages
On Mon, 8 Jul 2002, Jungshik Shin wrote:
On Mon, 8 Jul 2002, Keith Packard wrote:
Around 14 o'clock on Jul 8, Owen Taylor wrote:
+locale = (FcChar8 *)setlocale (LC_CTYPE, NULL);
Don't you mean LC_MESSAGES?
I believe it should be LC_CTYPE. Some people like me
...
LC_CTYPE
On Sat, 29 Jun 2002, Jungshik Shin wrote:
On Fri, 28 Jun 2002, Keith Packard wrote:
I'm confused by this; my exposure to Chinese fonts says that simplified
Chinese and traditional Chinese have significant overlap in Unicode
codepoints, but that the glyphs are quite a bit different
On Sat, 29 Jun 2002, Keith Packard wrote:
Ooops. My message crossed yours in mail :-)
Around 9 o'clock on Jun 29, Jungshik Shin wrote:
IMHO, most problems with Han Unification arise not from using a _single_
font targeted at one of zh_TW/zh_CN/ja/ko to render a run of text in
another
to
agree with this. This is better than what I sent earlier. Just forgetting
about GB18030/GBK coverage and concentrating on GB2312 and Big5 coverage
is simpler as well as better.
Jungshik Shin
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org
mappings?
Are you sure you have the latest version of the file? The file used
to have some spurrious entries, but all of them have been removed
at least in the CVS repository. They were removed in two stages
on Nov 2 and on Dec. 24, 2001.
Jungshik Shin
On Fri, 21 Jun 2002, Jungshik Shin wrote:
On Fri, 21 Jun 2002, Tomohiro KUBOTA wrote:
I found curious mappings in ksc5601.1987-0.enc.gz file.
...
appears in the file. Since KS C 5601 is an ISO-2022-compliant
94x94 character set, 0x30C1 must not appear. Can someone explain
Are you
encoding file with FIRSTINDEX. I filed a bug report on this along with
a patch to ttmkfdir in RedHat bugzilla because I thought it's not
font encoding files but ttmkfdir that has to be fixed. For details,
see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=61769
Jungshik Shin
Hi,
FYI, below is my message sent to [EMAIL PROTECTED] to address newly
found problems in ksc5601.1987-0.enc (a part of which was
originally introduced in v1.2 of the file) as well as old problems
for which I submitted patches to [EMAIL PROTECTED] a few months
ago.
Jungshik Shin
---
Hello
OT fonts.
Jungshik Shin
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
) have (this is actually what I use):
LANG=ko_KR.UTF-8
LC_PAPER=en_US.UTF-8 # I need this because otherwise psutils uses A4.
LC_MESSAGES=C # Korean translation is a bit too cryptic to understand ;-)
Jungshik Shin
___
I18n mailing list
[EMAIL PROTECTED
in Korean
XIM (e.g. Ami), I'll be able to typeset Middle Korean with LaTeX
sooner or later. (LaTeX side is almost ready, too)
/a bit off-topic
Jungshik Shin
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
on a few fronts in cooperation: font developers/package
builders and application/desktop developers.
Jungshik Shin
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
to standardize on preferred
MIME names for existing encodings such as ISO-8859-1, EUC-JP, EUC-KR
and UTF-8. Therefore, perhaps it's not a bad idea to make them
available across all locales in X locale.alias ?
Jungshik Shin
___
I18n mailing list
On 13 Nov 2001, Juliusz Chroboczek wrote:
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
of
that of CJK glyphs.
Jungshik Shin
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
' to go not
only for multilingual use but also for Korean alone in Korea.
Jungshik Shin
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
64 matches
Mail list logo
