From roozbeh at gmail.com Sun Feb 1 07:42:03 2009 From: roozbeh at gmail.com (Roozbeh Pournader) Date: Sat, 31 Jan 2009 23:42:03 -0800 Subject: Lost in translation, part II: Lost in orthographies Message-ID: I was trying to avoid fontconfig, but it caught me at the end. Trying to figure out which languages in comps are supported by which font, to be able to include them in the language group, I compared the list of languages in F11's comps file with the orthography lists fontconfig supports. To my surprise, some were missing/problematic. The list is here: http://fedoraproject.org/wiki/I18N/LanguageSupportCriteria/Missing_fontconfig I also found quite a few problems with existing orth files in fontconfig that I'm working on fixing: http://tinyurl.com/dbk6a8 Since fontconfig support is critical for any language Fedora claims to support [1], I think we should remove the language groups from comps file if we don't have a fontconfig orthography file for it. I went and updated the language criteria page we have here, adding a fontconfig step: https://fedoraproject.org/wiki/I18N/LanguageSupportCriteria For the specific language cases, I went and filed upstream bugs against fontconfig for all I could find, except for Berber, which is a bit problematic by nature (language code used is actually for a family of languages, glibc locales are incomplete, Latin/Tifinagh/Arabic script division is not along country lines...). This is a report. I would appreciate help and feedback, especially your thoughts about fontconfig .orth requirements for claiming language support in Fedora. Roozbeh [1]: Ask fc-list which fonts support Kinyarwanda (rw) by running "fc-list :lang=rw": it gives you nothing, while in real life, almost every font on your machine supports it. From nicolas.mailhot at laposte.net Sun Feb 1 10:40:46 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 01 Feb 2009 11:40:46 +0100 Subject: Lost in translation, part II: Lost in orthographies In-Reply-To: References: Message-ID: <1233484846.6961.24.camel@arekh.okg> Le samedi 31 janvier 2009 ? 23:42 -0800, Roozbeh Pournader a ?crit : > I was trying to avoid fontconfig, but it caught me at the end. Trying > to figure out which languages in comps are supported by which font, to > be able to include them in the language group, I compared the list of > languages in F11's comps file with the orthography lists fontconfig > supports. > > To my surprise, some were missing/problematic. The list is here: > > http://fedoraproject.org/wiki/I18N/LanguageSupportCriteria/Missing_fontconfig I'd be very careful to redefine tagalog for example. The tagalog script is definitely not latin and has a specific unicode block, iso 15924 script tag, and specific supporting fonts http://www.unicode.org/iso15924/iso15924-codes.html http://fedoraproject.org/wiki/Pmorrow_Tagalog_Doctrina_1593_fonts IMHO we've been conflating too many different notions (country, region, language, script) in a few short locale tags and what you see is just the system breaking appart for non-mainstream languages/scripts. > I also found quite a few problems with existing orth files in > fontconfig that I'm working on fixing: http://tinyurl.com/dbk6a8 This is something for Behdad. I hear he's cutting a new fontconfig version right now, you may want to catch him before he's done and the projects wents back to its usual 6-8 months sleepiness ;). > Since fontconfig support is critical for any language Fedora claims to > support [1], I think we should remove the language groups from comps > file if we don't have a fontconfig orthography file for it. That's not really helpful, all the different parts of language support are done by different groups with different agendas and different time scales so of course initial support is going to be incomplete. Expecting one contributor to provide all the parts in one go is illusory. What you want is to help the different contributors to a language group to: ? identify other bits are missing ? ping in the right place so they get added Otherwise everyone will just wait for everyone else. Some people will claim that ? full ? language support means a system dictionnary and thesaurus BTW, completeness is a slipery slope. > I went and > updated the language criteria page we have here, adding a fontconfig > step: > > https://fedoraproject.org/wiki/I18N/LanguageSupportCriteria > > For the specific language cases, I went and filed upstream bugs > against fontconfig for all I could find, except for Berber, which is a > bit problematic by nature (language code used is actually for a family > of languages, glibc locales are incomplete, Latin/Tifinagh/Arabic > script division is not along country lines...). This again is because iso-639 is not well suited to identify scripts. > This is a report. I would appreciate help and feedback, especially > your thoughts about fontconfig .orth requirements for claiming > language support in Fedora. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From roozbeh at gmail.com Sun Feb 1 13:34:12 2009 From: roozbeh at gmail.com (Roozbeh Pournader) Date: Sun, 1 Feb 2009 05:34:12 -0800 Subject: Lost in translation, part II: Lost in orthographies In-Reply-To: <1233484846.6961.24.camel@arekh.okg> References: <1233484846.6961.24.camel@arekh.okg> Message-ID: On Sun, Feb 1, 2009 at 2:40 AM, Nicolas Mailhot wrote: > I'd be very careful to redefine tagalog for example. The tagalog script > is definitely not latin and has a specific unicode block, iso 15924 > script tag, and specific supporting fonts > > http://www.unicode.org/iso15924/iso15924-codes.html > http://fedoraproject.org/wiki/Pmorrow_Tagalog_Doctrina_1593_fonts No worries. I know all that. According to the Unicode Standard, that script has not been much used for Tagalog since mid-1700s. The Tagalog script in Unicode is an archaic script only, mostly for scholarly use: http://bugs.freedesktop.org/show_bug.cgi?id=19846 > IMHO we've been conflating too many different notions (country, region, > language, script) in a few short locale tags and what you see is just > the system breaking appart for non-mainstream languages/scripts. That's very true. I've been talking with Behdad to try to do a bit or redesigning, and we had a few ideas, like this bug, trying to get BCP 47 into fontconfig and somehow solving the glibc locale naming problem: http://bugs.freedesktop.org/show_bug.cgi?id=19869 I would appreciate your feedback. (Of course, we can't fix this in this release.) > This is something for Behdad. I hear he's cutting a new fontconfig > version right now, you may want to catch him before he's done and the > projects wents back to its usual 6-8 months sleepiness ;). I'm working with him. Actually he insisted that I rush it :) > all the different parts of language support > are done by different groups with different agendas and different time > scales so of course initial support is going to be incomplete. Expecting > one contributor to provide all the parts in one go is illusory. > > What you want is to help the different contributors to a language group > to: > ? identify other bits are missing > ? ping in the right place so they get added > > Otherwise everyone will just wait for everyone else. I'm sorry Nicolas, but I don't understand. Would you consider rewording? Are you saying that I should not have been trying to create the missing orth files myself? Or fix the buggy ones? > Some people will claim that ? full ? language support means a system > dictionnary and thesaurus BTW, completeness is a slipery slope. I agree. But we are talking about very basic language support here. If we cannot bring up and show a language in a proper font, we cannot claim to support it. Our layout system would not know what which font to use, so it will be just DejaVu first, instead of a font that actually supports the full glyph set for a language. Since we're also doing the automatic language detection in RPM thing, wouldn't that be based on orth files too? How can we claim we support a language in Fedora if none of our font rpms would report that they support it? Also, the orth files are very simple, much easier to create than glibc locale files for example. Thanks a lot for all your time, :) Roozbeh From nicolas.mailhot at laposte.net Sun Feb 1 13:46:26 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 01 Feb 2009 14:46:26 +0100 Subject: Lost in translation, part II: Lost in orthographies In-Reply-To: References: <1233484846.6961.24.camel@arekh.okg> Message-ID: <1233495986.13582.22.camel@arekh.okg> Le dimanche 01 f?vrier 2009 ? 05:34 -0800, Roozbeh Pournader a ?crit : > On Sun, Feb 1, 2009 at 2:40 AM, Nicolas Mailhot > > What you want is to help the different contributors to a language group > > to: > > ? identify other bits are missing > > ? ping in the right place so they get added > > > > Otherwise everyone will just wait for everyone else. > > I'm sorry Nicolas, but I don't understand. Would you consider > rewording? Are you saying that I should not have been trying to create > the missing orth files myself? Or fix the buggy ones? No, I'm saying completeness should not be a requirement to create a new language group, but the aim should be to help people identify the missing bits so they can ping someone else (like you:;)) to provide them. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From roozbeh at gmail.com Sun Feb 1 13:50:15 2009 From: roozbeh at gmail.com (Roozbeh Pournader) Date: Sun, 1 Feb 2009 05:50:15 -0800 Subject: Lost in translation, part II: Lost in orthographies In-Reply-To: <1233495986.13582.22.camel@arekh.okg> References: <1233484846.6961.24.camel@arekh.okg> <1233495986.13582.22.camel@arekh.okg> Message-ID: On Sun, Feb 1, 2009 at 5:46 AM, Nicolas Mailhot wrote: > No, I'm saying completeness should not be a requirement to create a new > language group, but the aim should be to help people identify the > missing bits so they can ping someone else (like you:;)) to provide > them. Got it. I guess this really means I should try to document the process, like the great documentation I'm seeing at the fonts sig! (not that i can reach the quality ;)) Roozbeh From petersen at redhat.com Mon Feb 2 23:13:09 2009 From: petersen at redhat.com (Jens Petersen) Date: Mon, 2 Feb 2009 18:13:09 -0500 (EST) Subject: fedora-i18n meeting In-Reply-To: <82236762.2066861233559082670.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <393623752.2465691233616389277.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Reminder that there will be a Fedora I18n meeting in just under 6 hours time. If you have points for discussion please post them here or on the meeting page: https://fedoraproject.org/wiki/I18N/Meetings Hope to see you there, Jens From sankarshan at randomink.org Tue Feb 3 04:14:00 2009 From: sankarshan at randomink.org (=?UTF-8?B?U2Fua2Fyc2hhbiAo4Ka44KaZ4KeN4KaV4Kaw4KeN4Ka34KajKQ==?=) Date: Tue, 3 Feb 2009 09:44:00 +0530 Subject: fedora-i18n meeting In-Reply-To: <393623752.2465691233616389277.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <82236762.2066861233559082670.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <393623752.2465691233616389277.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: On Tue, Feb 3, 2009 at 4:43 AM, Jens Petersen wrote: > Reminder that there will be a Fedora I18n meeting in just under 6 hours time. > > If you have points for discussion please post them here or on the meeting page: > > https://fedoraproject.org/wiki/I18N/Meetings I realize that this might be an annoyance, but would it be possible to post the agenda in the mail body itself ? Helps to read through them without having to open up a browser ie. an additional application. Thank you. -- >From Untruth, lead me to the Truth, >From Darkness, Lead me towards the Light, >From Death, Lead me to Life Eternal From nicolas.mailhot at laposte.net Tue Feb 3 22:50:16 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 03 Feb 2009 23:50:16 +0100 Subject: BPG Georgian Unicode fonts - packagers wanted Message-ID: <1233701416.26332.26.camel@arekh.okg> Dear all, Yesterday I took the time to find the current address of a well-known Georgian font creator, Besarion Paata Gugushvili. Our current Georgian support is rather limited: one set of glyphs in Dejavu, and nothing else (This set was created by the very same author BTW). Imagine using the same font all day long everywhere :( Some of his other fonts had long found their way in other major distributions (Mandriva, OpenSuse, Debian, Ubuntu?), at a time Fedora was largely ignoring this problem-space, but there was no public licensing statement of his part on any of his web sites. Which meant we could not just lift the files from the internet, and package them to reach Georgian support parity with others. So took the time to write the author a long nice mail asking to confirm the licensing. I didn't expect much, this kind of request usually takes ages to be answered, and the answer is usually not the one we'd like (when we don't hit language barriers). Anyway this time the reply was awesome: 1. less than 9 hours later (most of them night I'm sure) 2. a *new* font pack release (not the old files everyone else ships) 3. with *new* fonts (not just updates of the fonts everyone else ships) 4. with a clear licensing statement on the author web site (not a third-party site like before) 5. and adding the FSF font exception to the GPL statement (people who tried know how hard it is to get this one usually, many font authors just don't understand the need) So, Fedora would seriously suck if we took ages to package those fonts now. Or if other distros beat us to it. Unfortunately, I'm a *tad* busy right now, and can't possibly work on it short term. Therefore, I'm doing a public call on Fedora lists, for someone to package those, and prove Besarion Paata Gugushvili was right to trust Fedora. All the relevant technical information is here: http://fedoraproject.org/wiki/BPG_fonts Let's rock! Best regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From giomac at gmail.com Thu Feb 5 07:02:10 2009 From: giomac at gmail.com (George Machitidze) Date: Thu, 5 Feb 2009 11:02:10 +0400 Subject: BPG Georgian Unicode fonts - packagers wanted In-Reply-To: <1233701416.26332.26.camel@arekh.okg> References: <1233701416.26332.26.camel@arekh.okg> Message-ID: <519a81d30902042302g39bf5623rc02311ce013871b1@mail.gmail.com> Hi Nicolas! Thank you for initiating this issue - I didn't expect to see this message here :) I will talk with him directly and package files - I'm very experienced with rpmbuild and spec-s. Actually, I planned to release it, but I was little busy... btw, one of our friends just few hours ago finished first georgian psfu console font too, now we are testing it... 2009/2/4 Nicolas Mailhot > Dear all, > > Yesterday I took the time to find the current address of a well-known > Georgian font creator, Besarion Paata Gugushvili. Our current Georgian > support is rather limited: one set of glyphs in Dejavu, and nothing else > (This set was created by the very same author BTW). Imagine using the > same font all day long everywhere :( > > Some of his other fonts had long found their way in other major > distributions (Mandriva, OpenSuse, Debian, Ubuntu?), at a time Fedora > was largely ignoring this problem-space, but there was no public > licensing statement of his part on any of his web sites. Which meant we > could not just lift the files from the internet, and package them to > reach Georgian support parity with others. > > So took the time to write the author a long nice mail asking to confirm > the licensing. I didn't expect much, this kind of request usually takes > ages to be answered, and the answer is usually not the one we'd like > (when we don't hit language barriers). > > Anyway this time the reply was awesome: > 1. less than 9 hours later (most of them night I'm sure) > 2. a *new* font pack release (not the old files everyone else ships) > 3. with *new* fonts (not just updates of the fonts everyone else ships) > 4. with a clear licensing statement on the author web site (not a > third-party site like before) > 5. and adding the FSF font exception to the GPL statement (people who > tried know how hard it is to get this one usually, many font authors > just don't understand the need) > > So, Fedora would seriously suck if we took ages to package those fonts > now. Or if other distros beat us to it. Unfortunately, I'm a *tad* busy > right now, and can't possibly work on it short term. > > Therefore, I'm doing a public call on Fedora lists, for someone to > package those, and prove Besarion Paata Gugushvili was right to trust > Fedora. > > All the relevant technical information is here: > http://fedoraproject.org/wiki/BPG_fonts > > Let's rock! > > Best regards, > > -- > Nicolas Mailhot > > -- > Fedora-i18n-list mailing list > Fedora-i18n-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-i18n-list > -- BR, George Machitidze -------------- next part -------------- An HTML attachment was scrubbed... URL: From giomac at gmail.com Thu Feb 5 07:20:01 2009 From: giomac at gmail.com (George Machitidze) Date: Thu, 5 Feb 2009 11:20:01 +0400 Subject: BPG Georgian Unicode fonts - packagers wanted In-Reply-To: <519a81d30902042302g39bf5623rc02311ce013871b1@mail.gmail.com> References: <1233701416.26332.26.camel@arekh.okg> <519a81d30902042302g39bf5623rc02311ce013871b1@mail.gmail.com> Message-ID: <519a81d30902042320t51e5062bg9849578d28106b3c@mail.gmail.com> FYI wasn't subscribed to all needed lists... On Thu, Feb 5, 2009 at 11:02 AM, George Machitidze wrote: > Hi Nicolas! > Thank you for initiating this issue - I didn't expect to see this message > here :) > I will talk with him directly and package files - I'm very experienced with > rpmbuild and spec-s. > Actually, I planned to release it, but I was little busy... > btw, one of our friends just few hours ago finished first georgian psfu > console font too, now we are testing it... > 2009/2/4 Nicolas Mailhot > >> Dear all, >> >> Yesterday I took the time to find the current address of a well-known >> Georgian font creator, Besarion Paata Gugushvili. Our current Georgian >> support is rather limited: one set of glyphs in Dejavu, and nothing else >> (This set was created by the very same author BTW). Imagine using the >> same font all day long everywhere :( >> >> Some of his other fonts had long found their way in other major >> distributions (Mandriva, OpenSuse, Debian, Ubuntu?), at a time Fedora >> was largely ignoring this problem-space, but there was no public >> licensing statement of his part on any of his web sites. Which meant we >> could not just lift the files from the internet, and package them to >> reach Georgian support parity with others. >> >> So took the time to write the author a long nice mail asking to confirm >> the licensing. I didn't expect much, this kind of request usually takes >> ages to be answered, and the answer is usually not the one we'd like >> (when we don't hit language barriers). >> >> Anyway this time the reply was awesome: >> 1. less than 9 hours later (most of them night I'm sure) >> 2. a *new* font pack release (not the old files everyone else ships) >> 3. with *new* fonts (not just updates of the fonts everyone else ships) >> 4. with a clear licensing statement on the author web site (not a >> third-party site like before) >> 5. and adding the FSF font exception to the GPL statement (people who >> tried know how hard it is to get this one usually, many font authors >> just don't understand the need) >> >> So, Fedora would seriously suck if we took ages to package those fonts >> now. Or if other distros beat us to it. Unfortunately, I'm a *tad* busy >> right now, and can't possibly work on it short term. >> >> Therefore, I'm doing a public call on Fedora lists, for someone to >> package those, and prove Besarion Paata Gugushvili was right to trust >> Fedora. >> >> All the relevant technical information is here: >> http://fedoraproject.org/wiki/BPG_fonts >> >> Let's rock! >> >> Best regards, >> >> -- >> Nicolas Mailhot >> >> -- >> Fedora-i18n-list mailing list >> Fedora-i18n-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-i18n-list >> > > > > -- > BR, > George Machitidze > > -- BR, George Machitidze -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.mailhot at laposte.net Thu Feb 5 07:31:51 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 05 Feb 2009 08:31:51 +0100 Subject: BPG Georgian Unicode fonts - packagers wanted In-Reply-To: <519a81d30902042320t51e5062bg9849578d28106b3c@mail.gmail.com> References: <1233701416.26332.26.camel@arekh.okg> <519a81d30902042302g39bf5623rc02311ce013871b1@mail.gmail.com> <519a81d30902042320t51e5062bg9849578d28106b3c@mail.gmail.com> Message-ID: <1233819111.3865.19.camel@arekh.okg> Le jeudi 05 f?vrier 2009 ? 11:20 +0400, George Machitidze a ?crit : > On Thu, Feb 5, 2009 at 11:02 AM, George Machitidze > wrote: > Hi Nicolas! Hi George, > Thank you for initiating this issue - I didn't expect to see > this message here :) > I will talk with him directly and package files - I'm very > experienced with rpmbuild and spec-s. Tom has started packaging those fonts here: https://bugzilla.redhat.com/show_bug.cgi?id=483865 However I'm sure a native speaker that can propose great package summaries (upstream pages are 100% Georgian), and help bridge the communication gap with upstream (there are still a few legal nits to take care of apparently) would be very appreciated as co-maintainer. > Actually, I planned to release it, but I was little busy... > btw, one of our friends just few hours ago finished first > georgian psfu console font too, now we are testing it... I don't deal with console fonts, but I'm sure that if it was packaged it would be appreciated by Georgian Fedora users too. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From petersen at redhat.com Fri Feb 6 07:38:33 2009 From: petersen at redhat.com (Jens Petersen) Date: Fri, 6 Feb 2009 02:38:33 -0500 (EST) Subject: fedora-i18n meeting 2009-02-03 In-Reply-To: <393623752.2465691233616389277.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <603930439.3593621233905913926.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> The log of the meeting is now up at: https://fedoraproject.org/wiki/I18N/Meetings/2009-02-03 From pnemade at redhat.com Sun Feb 8 10:04:01 2009 From: pnemade at redhat.com (Parag Nemade) Date: Sun, 08 Feb 2009 15:34:01 +0530 Subject: wordxtr-0.1.0 released Message-ID: <498EAE11.1090200@redhat.com> Hi all, wordxtr-0.1.0 is now available for download at: https://fedorahosted.org/releases/w/o/wordxtr/wordxtr-0.1.0.tar.gz wordxtr-0.1.0.tar.gz md5sum: 4d873dc5a7f1cd05c83efe628634f2f8 This is a minor bug fix release. What is wordxtr ============ Wordxtr project aims at creating dictionary of words for a given language text. This dictionary is based on hunspell format where you need .dic and .aff files. wordxtr is command line application that takes 2 input parameters. First input parameter is language isocode along with country code like hi_IN for Hindi language or for Nepali language use ne_NP. Second input parameter is path to directory where plain text unicode files have stored from which words will be extracted. wordxtr is hosted at following location https://fedorahosted.org/wordxtr Overview of Changes from wordxtr 0.0.1 to 0.1.0 ============================================== - Enable existing hunspell dictionary .dic file as input data - rewrite usage help Regards, Parag. From mclasen at redhat.com Mon Feb 16 03:24:09 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Sun, 15 Feb 2009 22:24:09 -0500 Subject: IBus UI review Message-ID: <1234754649.3520.20.camel@matthiasc> Not sure if this is the correct place to send this, but I'll send it here anyway (please tell me if there's a better place). I've recently installed ibus in order to get some impression of how our new im framework will integrate in the desktop. While playing with it, I took some notes, that I'd like to share. Matthias --- Status icon - The tooltip "IBus - Running" is pretty pointless less and should be removed until there is something useful to say - There is no way to switch back to "no input method" from the status icon. I have to press Ctrl-space to go back. Maybe add an "None" entry at the bottom of the menu ? Toolbar - Why do input methods seem to fancy these weird undecorated floating toolbars ? Does it add anything that is not already present in the status icon ? - If we can't drop it, can there at least be a way to turn it off ? - The toolbar seems useless if "focus-follows-mouse" is turned on, since it becomes inactive on focus out. This also affects the status icon. Menus - What is the plan, going forward, wrt to im-chooser ? I'd hate to have 2 input method related menuitems in the default install. My preference would be to not install the im-chooser by default, since it is only needed to switch back to 'legacy' frameworks. - It would be great if we could use the generic "Input Method" menuitem for the ibus preferences, and maybe rename im-chooser to "Input Method Framework" or something like that. - Alternatively, if we can't get rid of im-chooser by default, maybe ibus-setup should not have its own menu item (I notice that scim-setup doesn't have one either), since it is available via im-chooser. - There is a mismatch between the menuitem and the ibus-setup window, both the window title and icon don't match the menu, as they should. Preferences, General tab - "Aauto start IBus on session login" is very techno babble. Can we make that something like "Enable Input Methods" ? I don't think there is any need to talk about sessions and autostart here. - Keyboard shortcuts: I would love to see these moved to the keyboard shortcuts capplet, which has support for handling application-defined shortcuts. As a bonus, you get automatic conflict handling. The one restriction is that currently, only one key-combination per action is possible. If having multiple is essential, you could either split it into "Trigger", "Alternative Trigger", "Second Alternative Trigger", or file a bug and I'll look into enabling multiple shortcuts per action in the keybinding capplet - "UI" is a bad section label. How about "Fonts & Style" instead ? Even better would be to split it into two sections, a la Input Window Lookup table orientation: [Vertical] [ ] Use the system font Input Window Font: [Sans 10] Language Bar [ ] Show language bar [ ] Hide language bar when it is not needed Preferences, Engine tab - "Engine" is a technical term that is not really helpful here. How about "Languages" instead ? - There are some icons missing in the combo box, e.g Telugu-apple, Telugu-rts, Marathi-phonetic, Marathi-itrans... - The main list needs to repeat the language name (like the status icon menu already does) otherwise it is not clear if "phonetic" is Oriya or Marathi. Preferences, About tab This should not be done as a tab, it is very much against the style of our preference tools. There is already an About menu item on the status icon. If you absolutely want to have an "About" in the preferences, it should be a left-aligned "About" button in the action area that brings up an about dialog. But I'd really just get rid of it. From sergio.puas at hotmail.com Mon Feb 16 17:01:11 2009 From: sergio.puas at hotmail.com (sergio.puas at hotmail.com) Date: Mon, 16 Feb 2009 09:01:11 -0800 Subject: =?iso-8859-1?q?Respuesta_autom=E1tica?= In-Reply-To: <20090216170037.6A765618880@hormel.redhat.com> Message-ID: An HTML attachment was scrubbed... URL: From tagoh at redhat.com Wed Feb 18 02:19:40 2009 From: tagoh at redhat.com (Akira TAGOH) Date: Wed, 18 Feb 2009 11:19:40 +0900 (JST) Subject: IBus UI review In-Reply-To: <1234754649.3520.20.camel@matthiasc> References: <1234754649.3520.20.camel@matthiasc> Message-ID: <20090218.111940.776924184590170396.tagoh@redhat.com> Hi, Thank you for your review. that would be good input to improve it. Let me have some comments where I can say something. >>>>> On Sun, 15 Feb 2009 22:24:09 -0500, >>>>> "MC" == Matthias Clasen wrote: MC> Status icon MC> - There is no way to switch back to "no input method" from the status MC> icon. I have to press Ctrl-space to go back. Maybe add an "None" entry MC> at the bottom of the menu ? I'm not sure what you expect to "no input method" though, if it's something like "Disable input method" at im-chooser, it won't work as expected. probably imsettings applet may wants to integrate the status icon with IM-specific operations such as changing engines etc. or do you want a kind of "English" entry as SCIM has? in either case that would be better filing a bug to bugzilla. MC> Toolbar MC> - Why do input methods seem to fancy these weird undecorated floating MC> toolbars ? Does it add anything that is not already present in the MC> status icon ? Yes, it does. and it's supposed to provide similar feature in SCIM and IMs where is running at Windows say. which provides facilities to change various conditions such as the input-mode, style etc. MC> - If we can't drop it, can there at least be a way to turn it off ? That would be a good idea. please file a bug :) MC> - The toolbar seems useless if "focus-follows-mouse" is turned on, since MC> it becomes inactive on focus out. This also affects the status icon. Indeed. there are same problem on SCIM too. do you have any idea to get this working on even "focus-follows-mouse" mode? MC> Menus MC> - What is the plan, going forward, wrt to im-chooser ? I'd hate to have MC> 2 input method related menuitems in the default install. My preference MC> would be to not install the im-chooser by default, since it is only MC> needed to switch back to 'legacy' frameworks. And to "disable input method" too. since im-chooser is just a frontend application for imsettings, we've tried to kick it out from the dependencies chain, but we missed the way to disable input method from GUI then. now applet could do that but it's hidden by default as you suggested. MC> - Alternatively, if we can't get rid of im-chooser by default, maybe MC> ibus-setup should not have its own menu item (I notice that scim-setup MC> doesn't have one either), since it is available via im-chooser. I'd prefer this idea since other IMs follows that. MC> - There is a mismatch between the menuitem and the ibus-setup window, MC> both the window title and icon don't match the menu, as they should. Can you file a bug for that? MC> Preferences, General tab MC> - "Aauto start IBus on session login" is very techno babble. Can we make MC> that something like "Enable Input Methods" ? I don't think there is any MC> need to talk about sessions and autostart here. Actually incomplete feature so far. since the environment variables still needs to be set to get all things working. and that feature doesn't take care of it. IMHO we should drop it from preference to avoid any confusion. MC> - Keyboard shortcuts: I would love to see these moved to the keyboard MC> shortcuts capplet, which has support for handling application-defined MC> shortcuts. As a bonus, you get automatic conflict handling. The one MC> restriction is that currently, only one key-combination per action is MC> possible. If having multiple is essential, you could either split it MC> into "Trigger", "Alternative Trigger", "Second Alternative Trigger", or MC> file a bug and I'll look into enabling multiple shortcuts per action in MC> the keybinding capplet That sounds promising. I'd love to see that too :) Cheers, -- Akira TAGOH -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phuang at redhat.com Wed Feb 18 03:38:08 2009 From: phuang at redhat.com (Huang Peng) Date: Wed, 18 Feb 2009 11:38:08 +0800 Subject: IBus UI review In-Reply-To: <1234754649.3520.20.camel@matthiasc> References: <1234754649.3520.20.camel@matthiasc> Message-ID: <499B82A0.7070700@redhat.com> Hi Matthias Clasen, Thanks for your reviewing. I embedded my comments below. please check them. Matthias Clasen wrote: > Not sure if this is the correct place to send this, but I'll send it > here anyway (please tell me if there's a better place). > > I've recently installed ibus in order to get some impression of how our > new im framework will integrate in the desktop. While playing with it, I > took some notes, that I'd like to share. > > > Matthias > > --- > > Status icon > > - The tooltip "IBus - Running" is pretty pointless less and should be > removed until there is something useful to say I'd like use "IBus" as other applications do to indicate this icon is for ibus. > > - There is no way to switch back to "no input method" from the status > icon. I have to press Ctrl-space to go back. Maybe add an "None" entry > at the bottom of the menu ? It is useful. I will add it. > > > Toolbar > > - Why do input methods seem to fancy these weird undecorated floating > toolbars ? Does it add anything that is not already present in the > status icon ? > > - If we can't drop it, can there at least be a way to turn it off ? > > - The toolbar seems useless if "focus-follows-mouse" is turned on, since > it becomes inactive on focus out. This also affects the status icon. It is useful for some input methods. Some IMs need it to show current IM status, and user can use it to change the IME's status and behaviours. BTW, ibus has a setting for it. User could hide it when the input method is not active. Maybe adding a configure item to always hide the bar is better. > > Menus > > - What is the plan, going forward, wrt to im-chooser ? I'd hate to have > 2 input method related menuitems in the default install. My preference > would be to not install the im-chooser by default, since it is only > needed to switch back to 'legacy' frameworks. > > - It would be great if we could use the generic "Input Method" menuitem > for the ibus preferences, and maybe rename im-chooser to "Input Method > Framework" or something like that. I think we need discuss it with other i18n team members. > > - Alternatively, if we can't get rid of im-chooser by default, maybe > ibus-setup should not have its own menu item (I notice that scim-setup > doesn't have one either), since it is available via im-chooser. SCIM has one, named 'SCIM Input Method Setup'. > > - There is a mismatch between the menuitem and the ibus-setup window, > both the window title and icon don't match the menu, as they should. Fixed. I use "IBus Preferences" now. > > > Preferences, General tab > > - "Auto start IBus on session login" is very techno babble. Can we make > that something like "Enable Input Methods" ? I don't think there is any > need to talk about sessions and autostart here. How about "Start ibus on login"? > > - Keyboard shortcuts: I would love to see these moved to the keyboard > shortcuts capplet, which has support for handling application-defined > shortcuts. As a bonus, you get automatic conflict handling. The one > restriction is that currently, only one key-combination per action is > possible. If having multiple is essential, you could either split it > into "Trigger", "Alternative Trigger", "Second Alternative Trigger", or > file a bug and I'll look into enabling multiple shortcuts per action in > the keybinding capplet What's the keybinding capplet? Is it the 'Keyboard Shortcuts' in Preferences->Pernson menu? I tested some keyboard shortcuts, they do no work. I use compiz as my windows manager. Is it the reason? > > - "UI" is a bad section label. How about "Fonts & Style" instead ? Even > better would be to split it into two sections, a la > > Input Window > Lookup table orientation: [Vertical] > [ ] Use the system font > Input Window Font: [Sans 10] > > Language Bar > [ ] Show language bar > [ ] Hide language bar when it is not needed > > > Preferences, Engine tab > > - "Engine" is a technical term that is not really helpful here. How > about "Languages" instead ? I think "Input Methods" is better. But it is too long, isn't it? > > - There are some icons missing in the combo box, e.g Telugu-apple, > Telugu-rts, Marathi-phonetic, Marathi-itrans... It is a bug. It has already been fixed. > > - The main list needs to repeat the language name (like the status icon > menu already does) otherwise it is not clear if "phonetic" is Oriya or > Marathi. It is reasonable. > > > Preferences, About tab > > This should not be done as a tab, it is very much against the style of > our preference tools. There is already an About menu item on the status > icon. If you absolutely want to have an "About" in the preferences, it > should be a left-aligned "About" button in the action area that brings > up an about dialog. But I'd really just get rid of it. It exists before About menu item on the status icon. now it is duplicated. I will remove it. From mclasen at redhat.com Wed Feb 18 06:03:07 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 18 Feb 2009 01:03:07 -0500 Subject: IBus UI review In-Reply-To: <499B82A0.7070700@redhat.com> References: <1234754649.3520.20.camel@matthiasc> <499B82A0.7070700@redhat.com> Message-ID: <1234936988.4504.20.camel@matthiasc> On Wed, 2009-02-18 at 11:38 +0800, Huang Peng wrote: > > > > - The toolbar seems useless if "focus-follows-mouse" is turned on, since > > it becomes inactive on focus out. This also affects the status icon. > > It is useful for some input methods. Some IMs need it to show current IM > status, and user can use it to change the IME's status and behaviours. > BTW, ibus has a setting for it. User could hide it when the input method > is not active. Maybe adding a configure item to always hide the bar is > better. Did you understand what I said about focus-follows-mouse ? Anyway, another way in which the toolbar is problematic is caused by the odd way in which input methods are started before the rest of the session. The toolbar appears way before other parts of the desktop, and hangs there, naked, in front of the background. Can we keep it hidden until the status icon has been embedded in the panel, please ? > > > > - Alternatively, if we can't get rid of im-chooser by default, maybe > > ibus-setup should not have its own menu item (I notice that scim-setup > > doesn't have one either), since it is available via im-chooser. > > SCIM has one, named 'SCIM Input Method Setup'. Yes, but that does not show up in the menus. afaics. Another case of 'menu pollution' that I only spotted after doing the review is that IBus puts another menu item at Applications -> Accessories -> IBus. That is not good, imo. First of all, the menu label does not explain at all what it does, and second, it just duplicates the functionality for starting an im framework that is already present with im-chooser. Such duplication is just confusing, please drop it. > > Preferences, General tab > > > > - "Auto start IBus on session login" is very techno babble. Can we make > > that something like "Enable Input Methods" ? I don't think there is any > > need to talk about sessions and autostart here. > > How about "Start ibus on login"? First of all, does this not just duplicate functionality of im-chooser again ? (Of course, I would love to get rid of im-chooser, so in that case it won't duplicate it anymore...) But also, I don't think this should be only about starting at login. It would be better to let the checkbox start and stop ibus in general. Of course, at login time, you will also use the last value of that preference to decide if ibus should be started or not. > > What's the keybinding capplet? Is it the 'Keyboard Shortcuts' in > Preferences->Pernson menu? I tested some keyboard shortcuts, they do no > work. I use compiz as my windows manager. Is it the reason? The window manager should only have an influence on the window management keybindings (but then, the tool is smart enough to show the right keybindings, depending on which window manager is running, I believe. Anyway, the keybinding capplet is really just a uniform way to set gconf keys that represent keybindings. Actually grabbing the keys and doing something still needs to be done by the applications that use the keybindings. From phuang at redhat.com Wed Feb 18 08:14:24 2009 From: phuang at redhat.com (Peng Huang) Date: Wed, 18 Feb 2009 16:14:24 +0800 Subject: IBus UI review In-Reply-To: <1234936988.4504.20.camel@matthiasc> References: <1234754649.3520.20.camel@matthiasc> <499B82A0.7070700@redhat.com> <1234936988.4504.20.camel@matthiasc> Message-ID: <499BC360.6020801@redhat.com> On 02/18/2009 02:03 PM, Matthias Clasen wrote: > On Wed, 2009-02-18 at 11:38 +0800, Huang Peng wrote: > > > >> > >> > - The toolbar seems useless if "focus-follows-mouse" is turned on, since >> > it becomes inactive on focus out. This also affects the status icon. >> >> It is useful for some input methods. Some IMs need it to show current IM >> status, and user can use it to change the IME's status and behaviours. >> BTW, ibus has a setting for it. User could hide it when the input method >> is not active. Maybe adding a configure item to always hide the bar is >> better. >> > > Did you understand what I said about focus-follows-mouse ? Anyway, > another way in which the toolbar is problematic is caused by the odd way > in which input methods are started before the rest of the session. The > toolbar appears way before other parts of the desktop, and hangs there, > naked, in front of the background. Can we keep it hidden until the > status icon has been embedded in the panel, please ? > > I do not understand 'focus-follows-mouse' well. Please explain it to me. Another question, how do I know when the systray is ready? >> > >> > - Alternatively, if we can't get rid of im-chooser by default, maybe >> > ibus-setup should not have its own menu item (I notice that scim-setup >> > doesn't have one either), since it is available via im-chooser. >> >> SCIM has one, named 'SCIM Input Method Setup'. >> > > Yes, but that does not show up in the menus. afaics. > > Another case of 'menu pollution' that I only spotted after doing the > review is that IBus puts another menu item at Applications -> > Accessories -> IBus. That is not good, imo. First of all, the menu label > does not explain at all what it does, and second, it just duplicates the > functionality for starting an im framework that is already present with > im-chooser. Such duplication is just confusing, please drop it. > OK. I will hide them. > >> > Preferences, General tab >> > >> > - "Auto start IBus on session login" is very techno babble. Can we make >> > that something like "Enable Input Methods" ? I don't think there is any >> > need to talk about sessions and autostart here. >> >> How about "Start ibus on login"? >> > > First of all, does this not just duplicate functionality of im-chooser > again ? (Of course, I would love to get rid of im-chooser, so in that > case it won't duplicate it anymore...) > > But also, I don't think this should be only about starting at login. It > would be better to let the checkbox start and stop ibus in general. Of > course, at login time, you will also use the last value of that > preference to decide if ibus should be started or not. > Actually, before user starts ibus-setup, ibus is already running, and ibus-setup needs ibus-daemon to provide configure storage service. When use click this checkbox, ibus-setup just create a symbol link in ~/.config/autostart/ . So 'Start ibus on login' is better. Although it duplicates the function of im-chooser, but for other Linux distribution without im-chooser, it is useful. > >> What's the keybinding capplet? Is it the 'Keyboard Shortcuts' in >> Preferences->Pernson menu? I tested some keyboard shortcuts, they do no >> work. I use compiz as my windows manager. Is it the reason? >> > > The window manager should only have an influence on the window > management keybindings (but then, the tool is smart enough to show the > right keybindings, depending on which window manager is running, I > believe. > > Anyway, the keybinding capplet is really just a uniform way to set gconf > keys that represent keybindings. Actually grabbing the keys and doing > something still needs to be done by the applications that use the > keybindings. > It does not work on my box. I changed shortcut of 'Run Dialog', but 'Alt + F2' still works and the new shortcut key does not work. I guess the windows manager metacity handles those global hotkeys, but compiz does not use those settings. From mclasen at redhat.com Wed Feb 18 20:09:17 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 18 Feb 2009 15:09:17 -0500 Subject: IBus UI review In-Reply-To: <499BC360.6020801@redhat.com> References: <1234754649.3520.20.camel@matthiasc> <499B82A0.7070700@redhat.com> <1234936988.4504.20.camel@matthiasc> <499BC360.6020801@redhat.com> Message-ID: <1234987757.3472.18.camel@localhost.localdomain> On Wed, 2009-02-18 at 16:14 +0800, Peng Huang wrote: > On 02/18/2009 02:03 PM, Matthias Clasen wrote: > >> > > > > Did you understand what I said about focus-follows-mouse ? Anyway, > > another way in which the toolbar is problematic is caused by the odd way > > in which input methods are started before the rest of the session. The > > toolbar appears way before other parts of the desktop, and hangs there, > > naked, in front of the background. Can we keep it hidden until the > > status icon has been embedded in the panel, please ? > > > > > I do not understand 'focus-follows-mouse' well. Please explain it to me. > Another question, how do I know when the systray is ready? By focus-follows-mouse, I mean the "Select windows when the mouse moves over them" option in the "Windows" capplet. If you turn that on, and move the move from the window you are working in towards the toolbar or statusicon, the window looses focus and the status icon/toolbar turn inactive, so you can't do whatever you wanted to there in the first place... To know when the statusicon is embedded in the panel, you can listen for the "notify::embedded" signal on the GtkStatusIcon. Matthias From mclasen at redhat.com Wed Feb 18 20:17:16 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 18 Feb 2009 15:17:16 -0500 Subject: IBus UI review In-Reply-To: <20090218.111940.776924184590170396.tagoh@redhat.com> References: <1234754649.3520.20.camel@matthiasc> <20090218.111940.776924184590170396.tagoh@redhat.com> Message-ID: <1234988236.3472.26.camel@localhost.localdomain> On Wed, 2009-02-18 at 11:19 +0900, Akira TAGOH wrote: > > MC> - There is no way to switch back to "no input method" from the status > MC> icon. I have to press Ctrl-space to go back. Maybe add an "None" entry > MC> at the bottom of the menu ? > > I'm not sure what you expect to "no input method" though, if > it's something like "Disable input method" at im-chooser, it > won't work as expected. probably imsettings applet may wants > to integrate the status icon with IM-specific operations > such as changing engines etc. or do you want a kind of > "English" entry as SCIM has? I was basically looking for a way to do what the "trigger" key does. If "English" is an appropriate description of that, then sure. But I doubt that "English" is the right name when I'm e.g. logged in in German. > MC> - Why do input methods seem to fancy these weird undecorated floating > MC> toolbars ? Does it add anything that is not already present in the > MC> status icon ? > > Yes, it does. and it's supposed to provide similar feature > in SCIM and IMs where is running at Windows say. which > provides facilities to change various conditions such as the > input-mode, style etc. Ok. Would it not be better to provide this functionality through the status icon as well ? Having to places related to im control (the status icon in the upper left, and the toolbar somewhere else) seems suboptimal. And the naked toolbar looks really quite foreign to anybody who hasn't had years of conditioning by other im frameworks... > > MC> - Alternatively, if we can't get rid of im-chooser by default, maybe > MC> ibus-setup should not have its own menu item (I notice that scim-setup > MC> doesn't have one either), since it is available via im-chooser. > > I'd prefer this idea since other IMs follows that. It would be so much better to have one input method framework, and make that work for everything, rather than wrapping a framework selection framework around it. I think I have stated that opinion several times already... I'll see about filing some of my comments as bugs tonight. Feel free to close them if they have already been handled. Matthias From phuang at redhat.com Thu Feb 19 03:11:39 2009 From: phuang at redhat.com (Peng Huang) Date: Thu, 19 Feb 2009 11:11:39 +0800 Subject: IBus UI review In-Reply-To: <1234987757.3472.18.camel@localhost.localdomain> References: <1234754649.3520.20.camel@matthiasc> <499B82A0.7070700@redhat.com> <1234936988.4504.20.camel@matthiasc> <499BC360.6020801@redhat.com> <1234987757.3472.18.camel@localhost.localdomain> Message-ID: <499CCDEB.7080800@redhat.com> On 02/19/2009 04:09 AM, Matthias Clasen wrote: > On Wed, 2009-02-18 at 16:14 +0800, Peng Huang wrote: > >> On 02/18/2009 02:03 PM, Matthias Clasen wrote: >> > > >>>> >>>> >>> Did you understand what I said about focus-follows-mouse ? Anyway, >>> another way in which the toolbar is problematic is caused by the odd way >>> in which input methods are started before the rest of the session. The >>> toolbar appears way before other parts of the desktop, and hangs there, >>> naked, in front of the background. Can we keep it hidden until the >>> status icon has been embedded in the panel, please ? >>> >>> >>> >> I do not understand 'focus-follows-mouse' well. Please explain it to me. >> Another question, how do I know when the systray is ready? >> > > By focus-follows-mouse, I mean the "Select windows when the mouse moves > over them" option in the "Windows" capplet. If you turn that on, and > move the move from the window you are working in towards the toolbar or > statusicon, the window looses focus and the status icon/toolbar turn > inactive, so you can't do whatever you wanted to there in the first > place... > I understood the problem now. We could make the panel close to the input cursor or window. But it will be a little annoying. Do you have any idea? > To know when the statusicon is embedded in the panel, you can listen for > the "notify::embedded" signal on the GtkStatusIcon. > It could work. But how to deal some desktop without sys tray? Do you know other ways to check if the session startup is over? From mclasen at redhat.com Thu Feb 19 03:42:15 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 18 Feb 2009 22:42:15 -0500 Subject: IBus UI review In-Reply-To: <499CCDEB.7080800@redhat.com> References: <1234754649.3520.20.camel@matthiasc> <499B82A0.7070700@redhat.com> <1234936988.4504.20.camel@matthiasc> <499BC360.6020801@redhat.com> <1234987757.3472.18.camel@localhost.localdomain> <499CCDEB.7080800@redhat.com> Message-ID: <1235014935.3926.10.camel@localhost.localdomain> On Thu, 2009-02-19 at 11:11 +0800, Peng Huang wrote: > > By focus-follows-mouse, I mean the "Select windows when the mouse moves > > over them" option in the "Windows" capplet. If you turn that on, and > > move the move from the window you are working in towards the toolbar or > > statusicon, the window looses focus and the status icon/toolbar turn > > inactive, so you can't do whatever you wanted to there in the first > > place... > > > I understood the problem now. We could make the panel close to the input > cursor or window. But it will be a little annoying. Do you have any idea? Oh, yes, please don't go there. The one thing more annoying than a naked floating toolbar is a naked floating toolbar that moves on its own and follows the cursor around... > > To know when the statusicon is embedded in the panel, you can listen for > > the "notify::embedded" signal on the GtkStatusIcon. > > > It could work. But how to deal some desktop without sys tray? Do you > know other ways to check if the session startup is over? I wouldn't worry too much about desktops without a systray. If you don't have a systray, you don't have NetworkManager, don't have a lot of other things. To cover that case, you probably want to make the toolbar appear regardless of systray if the user toggles the (not yet existing) 'show toolbar' checkbox. The easiest way to appear at the right point in the session startup is to be part of the session startup instead of being started outside the session. The new gnome-session starts apps in several phases, the panel being one of the first ones. So simply starting the im service in a later phase would solve the problem. gnome-keyring solves a similar problem (the daemon being started by a pam module, when important session infrastructure is not there yet) by having a little helper program that gets autostarted at the right point in the session startup and tells the daemon what it needs to know. Note that all this extra complication follows from the decision to start something before the session. (In the gnome-keyring case, it is somewhat unavoidable, since only the pam module has access to the user password thats needed to unlock the login keyring.) Matthias From roozbeh at gmail.com Tue Feb 24 21:31:53 2009 From: roozbeh at gmail.com (Roozbeh Pournader) Date: Tue, 24 Feb 2009 13:31:53 -0800 Subject: Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10) In-Reply-To: References: Message-ID: On Tue, Feb 24, 2009 at 12:23 AM, Nicolas Mailhot wrote: > I suspect the only reason that does not happen is we have a lot more > CJK packages than Arabic packages (and no Fraktur packages that I know > of). :-) You may be very right. > It would be nice if our intended priorities and fontconfig settings > for CJK fonts were documented somewhere (for every concerned locale). > Then I could pester Behdad so he tells us how to achieve them cleanly. > Right now, I'm not even sure this is clear to anyone but the concerned > packagers. And every time I open a CJK fontconfig file I see magic of > the blackest sort. So, would you recommend a process and some high priorities? fedora-i18n has a stake in this too, and we may be able to ask them for some help. (I would love to help in doing this, but I don't have much experience with either CJK or fontconfig rules. I will jump in whenever Unicode skills were called in. I also have a copy of the tome I mentioned before, but haven't really spent much time with it.) Roozbeh From ivazqueznet at gmail.com Wed Feb 25 02:18:34 2009 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Tue, 24 Feb 2009 21:18:34 -0500 Subject: Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10) In-Reply-To: References: Message-ID: <1235528314.10605.52.camel@ignacio.lan> On Tue, 2009-02-24 at 13:31 -0800, Roozbeh Pournader wrote: > On Tue, Feb 24, 2009 at 12:23 AM, Nicolas Mailhot > wrote: > > It would be nice if our intended priorities and fontconfig settings > > for CJK fonts were documented somewhere (for every concerned locale). > > Then I could pester Behdad so he tells us how to achieve them cleanly. > > Right now, I'm not even sure this is clear to anyone but the concerned > > packagers. And every time I open a CJK fontconfig file I see magic of > > the blackest sort. > > So, would you recommend a process and some high priorities? > fedora-i18n has a stake in this too, and we may be able to ask them > for some help. > > (I would love to help in doing this, but I don't have much experience > with either CJK or fontconfig rules. I will jump in whenever Unicode > skills were called in. I also have a copy of the tome I mentioned > before, but haven't really spent much time with it.) https://bugzilla.redhat.com/show_bug.cgi?id=485562#c5 -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pnemade at redhat.com Wed Feb 25 02:19:46 2009 From: pnemade at redhat.com (Parag Nemade) Date: Wed, 25 Feb 2009 07:49:46 +0530 Subject: Iok-1.2.1 released Message-ID: <49A4AAC2.6030404@redhat.com> FYI, In case you have not updated iok since a week, you may like to have a look at new iok release. This is minor release which enhances its UI. iok 1.2.1 can be download at: https://fedorahosted.org/releases/i/o/iok/iok-1.2.1.tar.gz http://downloads.sf.net/iok/iok-1.2.1.tar.gz Overview of Changes from iok 1.2.0 to 1.2.1 ============================================== - Make iok UI to be always on top - Add tooltips to iok UI - when used toggle "ToEnglish", inactivate keyboard selection list. This release is already built for all Fedora active branches and for EL5 also. Regards, Parag. From cchance at redhat.com Wed Feb 25 04:24:38 2009 From: cchance at redhat.com (Caius "kaio" Chance) Date: Wed, 25 Feb 2009 14:24:38 +1000 Subject: Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10) In-Reply-To: References: Message-ID: <49A4C806.30108@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Roozbeh Pournader wrote: >> It would be nice if our intended priorities and fontconfig settings >> for CJK fonts were documented somewhere (for every concerned locale). >> Then I could pester Behdad so he tells us how to achieve them cleanly. >> Right now, I'm not even sure this is clear to anyone but the concerned >> packagers. And every time I open a CJK fontconfig file I see magic of >> the blackest sort. I have patched the cjkuni-fonts on rawhide (and cjkunifonts on f10) which priority of such Chinese fonts are at higher priority in condition of "zh" (Chinese) locale. The fedora 10 patch will be pushed to update-testing very soon. - - kaio - -- Caius Chance, Soft Eng, I18N, Red Hat APAC, cchance AT redhat DOT com JP (Qual), RHCE, MCSE, CCNA, JLPT4, http://apac.redhat.com/disclaimer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkmkyAYACgkQmo+B7bGj5dJ0LACfQsMIHrQb4oxv0xrn7ULeGwGc nyEAnAx77c1Yo2NQzaStpbX0F4/5jgK9 =C40I -----END PGP SIGNATURE----- From cchance at redhat.com Wed Feb 25 04:35:07 2009 From: cchance at redhat.com (Caius "kaio" Chance) Date: Wed, 25 Feb 2009 14:35:07 +1000 Subject: Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10) In-Reply-To: <49A4C806.30108@redhat.com> References: <49A4C806.30108@redhat.com> Message-ID: <49A4CA7B.9080903@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Caius "kaio" Chance wrote: > I have patched the cjkuni-fonts on rawhide (and cjkunifonts on f10) > which priority of such Chinese fonts are at higher priority in condition > of "zh" (Chinese) locale. > > The fedora 10 patch will be pushed to update-testing very soon. http://kojipkgs.fedoraproject.org/packages/cjkunifonts/0.2.20080216.1/11.fc10/noarch/cjkunifonts-uming-0.2.20080216.1-11.fc10.noarch.rpm http://koji.fedoraproject.org/koji/buildinfo?buildID=86225 - - kaio - -- Caius Chance, Soft Eng, I18N, Red Hat APAC, cchance AT redhat DOT com JP (Qual), RHCE, MCSE, CCNA, JLPT4, http://apac.redhat.com/disclaimer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkmkynsACgkQmo+B7bGj5dIHeQCeMnBDdu0tyMDRnz1HakdYJpvB AzQAn0L62dgbP1rlN2qhjB8VPHu6Z+Sc =E5jL -----END PGP SIGNATURE----- From fangqq at gmail.com Wed Feb 25 06:36:17 2009 From: fangqq at gmail.com (Qianqian Fang) Date: Wed, 25 Feb 2009 01:36:17 -0500 Subject: Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10) In-Reply-To: <49A4C806.30108@redhat.com> References: <49A4C806.30108@redhat.com> Message-ID: <49A4E6E1.3000805@gmail.com> Caius "kaio" Chance wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Roozbeh Pournader wrote: > >>> It would be nice if our intended priorities and fontconfig settings >>> for CJK fonts were documented somewhere (for every concerned locale). >>> Then I could pester Behdad so he tells us how to achieve them cleanly. >>> Right now, I'm not even sure this is clear to anyone but the concerned >>> packagers. And every time I open a CJK fontconfig file I see magic of >>> the blackest sort. >>> > > I have patched the cjkuni-fonts on rawhide (and cjkunifonts on f10) > which priority of such Chinese fonts are at higher priority in condition > of "zh" (Chinese) locale. > I think this basically means the Japanese fonts are now having higher priorities under non-CJK locales, is this really what we want? > The fedora 10 patch will be pushed to update-testing very soon. > > - - kaio > > - -- > Caius Chance, Soft Eng, I18N, Red Hat APAC, cchance AT redhat DOT com > JP (Qual), RHCE, MCSE, CCNA, JLPT4, http://apac.redhat.com/disclaimer > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkmkyAYACgkQmo+B7bGj5dJ0LACfQsMIHrQb4oxv0xrn7ULeGwGc > nyEAnAx77c1Yo2NQzaStpbX0F4/5jgK9 > =C40I > -----END PGP SIGNATURE----- > > -- > Fedora-i18n-list mailing list > Fedora-i18n-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-i18n-list > > > > From tagoh at redhat.com Wed Feb 25 08:22:54 2009 From: tagoh at redhat.com (Akira TAGOH) Date: Wed, 25 Feb 2009 17:22:54 +0900 (JST) Subject: Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10) In-Reply-To: <49A4E6E1.3000805@gmail.com> References: <49A4C806.30108@redhat.com> <49A4E6E1.3000805@gmail.com> Message-ID: <20090225.172254.907329729220785007.tagoh@redhat.com> >>>>> On Wed, 25 Feb 2009 01:36:17 -0500, >>>>> "QF" == Qianqian Fang wrote: QF> I think this basically means the Japanese fonts are now QF> having higher QF> priorities under non-CJK locales, is this really what we QF> want? Current fontconfig policy doesn't really helps in this case. if one really wants to see a text with proper font, they need to set PANGO_LANGUAGE with the appropriate locales ordered or embed Pango attributes in text for GNOME. However right now cjkunifonts fontconfig config affected Japanese desktop too because current fontconfig policy in Fedora suggests having a recipe to override default substitution lists for specific locale and all of Japanese fonts has already followed these rules, but cjkunifonts didn't and fontconfig reads it prior to Japanese fonts'. -- Akira TAGOH -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sergio.puas at hotmail.com Wed Feb 25 17:00:37 2009 From: sergio.puas at hotmail.com (sergio.puas at hotmail.com) Date: Wed, 25 Feb 2009 09:00:37 -0800 Subject: =?iso-8859-1?q?Respuesta_autom=E1tica?= In-Reply-To: <20090225170035.E3D1E8E05BB@hormel.redhat.com> Message-ID: An HTML attachment was scrubbed... URL: From pnemade at redhat.com Fri Feb 27 10:48:43 2009 From: pnemade at redhat.com (Parag Nemade) Date: Fri, 27 Feb 2009 16:18:43 +0530 Subject: Iok-1.3.1 released Message-ID: <49A7C50B.8070203@redhat.com> Hi all, iok 1.3.1 is now available for download at: https://fedorahosted.org/releases/i/o/iok/iok-1.3.1.tar.gz http://downloads.sf.net/iok/iok-1.3.1.tar.gz iok-1.3.1.tar.gz md5sum: 9682116f61764ab3be2a9b7bdc147a54 This is a bug fix as well as UI enhancement release in the 1.3 series. What is iok ============ iok is Indic Onscreen Keyboard. It shows keymaps in GUI for inscript maps installed in /usr/share/m17n directory. If no inscript maps found in /usr/share/m17n then this application will work as English on screen keyboard. Iok also supports default keymap loading based on current locale and its inscript map availability in /usr/share/m17n. Other functionality this application provides is customization of system installed inscript map. Since iok-1.3.0 release, partial support for some indic xkb layouts has been added. iok is hosted at following locations http://iok.sourceforge.net and https://fedorahosted.org/iok Overview of Changes from iok 1.2.1 to 1.3.1 ============================================== - Added Fn keys. - improve keymap loading faster. - Add partial xkb layout parsing support - Enhance open_file() function. - Make non-supported keymaps opened to be added to the end of combo list. Regards, Parag.