openSUSE M17n August 2004

m17n@lists.opensuse.org

11 participants
23 discussions

No compose characters possible with asian language setting
by akimbo337＠gmx.de 16 Nov '09

16 Nov '09

Hello! I'm currently using SuSE 9.0 pro for both german and japanese input. This works fine so far, by setting the variables LC_CTYPE to ja_JP.UTF-8 and LANG to de_DE.UTF-8, but nevertheless I experienced a problem: With the LC_CTYPE set to japanese and an input method running (currently kinput2), I cannot type european language compose characters any more - at least the ones I used to produce with two sequent keystrokes ( ´ and e for é for example). The rest of my (german) keyboard layout works all fine, and with LC_CTYPE set to german, é's, à's, ô's, etc pose no problem, but then, of course, I cannot input japanese... This problem seems also to be existent for other language settings that use an input method, I tried it out with a friend who uses chinese input (also on SuSE 9.0 pro). We (my friend and I) are currently writing an article about asian language input with StarOffice/OOo, so we would really appreciate any help or hint concerning this problem. Thanks. Marcel Boeing

5 6

No skim panel in KDE 3.3
by Andrej Keiper 05 Sep '04

05 Sep '04

Hi, everybody, in my KDE 3.3 the skim panel doesn't show up in the system tray. If I start "scim-panel-kde" the two processes scim-panel-kde and skim are running but I see no panel. If I change the scim config file to the skim panel it's the same. The GTK panel works fine. Does it work for somebody? I use the packages from ftp.suse.com/pub/projects/m17n/9.1/. Andrej

2 2

Re: [m17n] GCC and Unicode
by Stephen Holmes 25 Aug '04

25 Aug '04

Fantastic - this anwers my quesiton - thanks! S t e p h e n H o l m e s Localisation Manager, Novell Tel: +353-1-605-8087 Cell: +353-833-5027 Fax: +353-1-605-8200 Novell Inc., the leading provider of information solutions "This e-mail was sent from a 100% Linux desktop. We're back, we're loud, and we're serious" >>>Mike FABIAN <mfabian(a)suse.de> 08/23/04 3:43 pm >>> Stephen Holmes <sholmes(a)novell.com> *******: >This isn't directly related to SUSE - I just happen to be using it, >but I had a question about GCC's handling of an input file encoded >as UTF-8. If I have something like > > char * lstr = Schöne Grüße > >Will the compiler compile this to UCS-4 internally, or just leave it >as a byte sequence? Here is an answer from our compiler expert Michael Matz <matz(a)suse.de>: matz> For string literals basically the byte values are transfered literally matz> from the input file to the object file. (C99 is more complicated than matz> this, but with UTF-8 files this is what it boils down to). matz> matz> With newer GCC versions (3.4 onward) normal string literals have their own matz> character set, which can be chosen by the user. By default this also is matz> UTF-8, so the behaviour is the same, i.e. UTF-8 strings are copied matz> literally to the object file. matz> matz> This is different with _wide_ character literals, i.e. strings of the form matz> LBlabla . With GCC 3.3 the input bytes are simply widened, i.e. such matz> wide character literal contains the same bytes as the UTF-8 encoding, matz> except that each byte is extended to 32 bit. With GCC 3.5 this is matz> different. There the input characters (in UTF-8) are converted into the matz> wide character set, which is UTF-32 (i.e. UCS-4) by default on machines matz> where wchar is 32 bit wide (i.e. all linux platforms). matz> matz> Hence, with gcc 3.3 there is no recoding involved. UTF-8 strings will be matz> placed into the object file. matz> matz> With newer gcc there is recoding for _wide_ string literals, from UTF-8 to matz> UCS-4 (i.e. 32 bit per character). Without user intervention there is no matz> recoding for normal string literals, i.e. UTF-8 strings remain such. matz> matz> > If I have something like matz> > matz> > char * lstr = Schöne Grüße matz> matz> So, given this (assuming the input is UTF-8): matz> char *str = Schöne Grüße; matz> wchar *wstr = LSchöne Grüße; matz> matz> with our compiler 'str' will be in UTF-8, 'wstr' will be in something matz> strange (UTF-8 but each byte extended to 32 bit). matz> matz> with newer compilers and no special options while compiling 'str' will be matz> in UTF-8, and 'wstr' will be in UCS-4. -- Mike FABIAN <mfabian(a)suse.de> http://www.suse.de/~mfabian ***** -- To unsubscribe, e-mail: m17n-unsubscribe(a)suse.com For additional commands, e-mail: m17n-help(a)suse.com

1 0

GCC and Unicode
by Stephen Holmes 23 Aug '04

23 Aug '04

Hi Folks, This isn't directly related to SUSE - I just happen to be using it, but I had a question about GCC's handling of an input file encoded as UTF-8. If I have something like char * lstr = Schöne Grüße Will the compiler compile this to UCS-4 internally, or just leave it as a byte sequence? Thanks in advance. Steve. S t e p h e n H o l m e s Localisation Manager, Novell Tel: +353-1-605-8087 Cell: +353-833-5027 Fax: +353-1-605-8200 Novell Inc., the leading provider of information solutions "This e-mail was sent from a 100% Linux desktop. We're back, we're loud, and we're serious"

2 1

RE: [m17n] GCC and Unicode
by 我不知道 23 Aug '04

23 Aug '04

Hi, Cannot read you question code in IE. Where did you use Unicode string? Identifier or literal? If it is in identifier, GCC does not support it, beacause GCC thought C99 standard has problem. If it is in literal, your usage has problem. As I remembered, accroding GCC document, source code will first be transfered to UTF-8 encoding, then be parsed. YANG RongWei 2004-8-23 Shanghai, China >From: "Stephen Holmes" <sholmes(a)novell.com> >To: <m17n(a)suse.com> >Subject: [m17n] GCC and Unicode >Date: Fri, 20 Aug 2004 15:56:01 +0200 > >Hi Folks, > >This isn't directly related to SUSE - I just happen to be using it, but I had a question about GCC's handling of an input file encoded as UTF-8. If I have something like > > char * lstr = Sch�ne Gr��e > >Will the compiler compile this to UCS-4 internally, or just leave it as a byte sequence? > >Thanks in advance. >Steve. > >S t e p h e n H o l m e s >Localisation Manager, Novell > >Tel: +353-1-605-8087 >Cell: +353-833-5027 >Fax: +353-1-605-8200 > >Novell Inc., the leading provider of information solutions >"This e-mail was sent from a 100% Linux desktop. We're back, we're loud, and we're serious" _________________________________________________________________ ��ĵ��ʼ�ϵͳ�� MSN Hotmail�� http://www.hotmail.com

1 0

kinput2 and dead keys
by Rowdy Rednose 21 Aug '04

21 Aug '04

If I enable kinput2, I am no longer able to use dead keys. Does anyone know, how I can use both?

3 3

Re:_Re:_[m17n]_Re:_[m17n]_SCIM_not_OK!
by Gustaf Kugelberg J�nsson 17 Aug '04

17 Aug '04

Hi again, >>You mean >> >>export XMODIFIERS=@im=SCIM >>emacs & > >>and then "Control+Space" doesn't work? Works >fine for me and many >>others. it didn't work, nothing at all happened, except that emacs started. (actually, once or twice the first few letters I typed turned red, but that was all) I tried launching scim and scim -d after and before the above, but it returned the same error: failure to find/load "socket server module" in both cases. I noticed that my .xim is long, complex (if clauses etc) and possibly outdated. Can that be the reason? Gustaf

2 1

Re:_[m17n]_SCIM_not_OK!
by Gustaf Kugelberg J�nsson 13 Aug '04

13 Aug '04

Sorry, I will use the mailing list! >You mean > >export XMODIFIERS=@im=SCIM >emacs & >and then "Control+Space" doesn't work? Works >fine for me and many >others. On SuSE 9.1, SLES9 and on the current >development version of >SuSE. Thanks, I think that I have tried exactly that, but I am not sure, I will try it when I get home (no internet at home). I seem to remember that I should change my .xim though, which I am not quite competent to do. It's not clear though how I choose language and and then variety (traditional). >> PS Is it my imagination or does suse get worse >> for each release, in terms >> of CJK handling? > It's your imagination. A lot has been improved > for CJK in SuSE 9.1. > Really. Oh, I didn't mean that it was your fault, and I agree that utf was badly needed. Also, it certainly is more integrated now, I was just missing those packages, and the "j" directory on ftp that made it easy to find them afterwards. > We have a much more packages than will fit > on the CDs and the people creating the CDs > always have to find a good > compromise. That was what I suspected. So is there no way to get those other packages, excepting the CJK from your site? I will download the missing packages, and the new scim. thank you. > If you still miss something, just tell me, I'll > upload it. One thing I have missed is CEDICT and CCDICT, the Chinese equivalents of Edict, though they've never been in SUSE, as far as I know. They have been part of Debian and can also be downloaded, but I suppose not everyone is aware of there existence. What I really miss most is kpackage, I think its name was, I much better tool for installing downloaded packages than YAST2, that simply doesn't work on my system, it refuses to find files on the HD, it complains that they are not on the DVD eventhough I chose an RPM from the HD. Thank you, Gustaf

2 1

Re: Autohinter and Bangla/Bengali fonts
by Mike FABIAN 10 Aug '04

10 Aug '04

Sayamindu Dasgupta <sayamindu(a)randomink.org> さんは書きました: > MuktiNarrow looks OK - maybe disabling the autohinter for Likhan would > be a good idea. OK, I did that, the fontconfig rpms in ftp://ftp.suse.com/pub/projects/m17n/9.1 contain this change now. -- Mike FABIAN <mfabian(a)suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。

1 0

newbies: japanese + polish
by Marek Wawrykiewicz 10 Aug '04

10 Aug '04

Hi, I'm new to this group. And I've big (big for me) problem. I use SuSE 9.1 Professional with polish language (coding iso-8859-2) and this work very well. But lastly I need use some japanese texts and I have problem is possible use iso-8859-2 with japanese coding? What about console? Sorry for stupid questions, but I'm ... lamer. Best regards, Marek

2 4

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

openSUSE M17n August 2004