Dare to Dream?

Mapper - still very hackish, but works - atleast to be used in case of emergency - much much better than reading the keymap manually

Download - Mapper (PyGtk)

Dear Mayank Jain,
We are pleased to inform you that you are now part of the GNOME
Foundation Membership. You are now eligible to become a candidate
for election and to vote in the annual Board of Directors elections
held each November…

All the hard work - bugs, patches & keymaps I’ve been contributing to upstream (Gnome majorly) have not gone waste… & I was paid in gold this morning when I got an email from the GNOME Foundation Membership Committee confirming my membership.

Also, part of this credit goes to Red Hat - where everyday, my efforts get streamlined into measureable outputs.

Thanks everyone

---

Doh! I’m so sorry, I mistook 2.4.6 as 2.6 version. 2.4.x series had no support for Indic languages. I’ll update my testing again for version 2.5.1 (devel) and blog again about my findings. This post should aint be of any good use. Sorry again.

---

Some days ago, I had responded on one of the Abiword blogs (msevior) that I was interetsed in testing the new Abiword release - 2.6.0 for Indic i18n. And today, after almost two weeks, I managed to get 2 free hours, after having a turbo charged “Exotica” pizza from Pizza Hut [Who says caffiene stimulates your nervous system! Pizza does it equally well - probably better!]

Abiword seems pretty nicely designed, but had some issues with rendering. I tested Abiword on following three aspects

• Rendering
• Inputting text
• Printing

Though printing & inputting Indic text worked as expected, rendering Indic text was my major concern. The first & most critical problem I found was that for indic text to be visible, the text had to be marked with the corresponding Indic font, otherwise the text would appear as circles! & the reverse was also equally frightening - if you type text with a hindi font (say Lohit Hindi) and SCIM is not activated, ie - the input is in plain english, the text is rendered as square boxes instead of plain english text. I think there’s some serious problem with the way Abiword uses fallback font or does font selection.

Other issues included ability to add more vovels to an existing vovel, giving something like this…

Another screenshot of interest - http://bugzilla.abisource.com/attachment.cgi?id=4113

Here is a complete bug list
10812 - Abiword does not selects font automatically according to …
10813 - Unable to render complex indic characters
10814 - Typing english text when indic font is selected, gives sq…
10815 - Unable to render ZWNJ properly
10816 - Vovels are not rendered properly for indic scripts.
10817 - Preedit window is randomply placed on the screen
10818 - Abiword cannot print when indic text is written, but corr…

Apart from this, I also found two very interesting things in Abiword.

1. The right click menu in text area gives an option to select the Input Method Engine (IME)- which is very very nice as compared to OO.writer - for which if the IME does not works, you cannot tell if it started or not or was there any other problem or that is GTK_IM_MODULE variable is set or not!
2. Abiword uses a preedit window to display the preedit text - as compared to the underlined text which is displayed by GTK+ apps.

With this, they have managed to escape preedit replication problems like Bug 166231 and Bug 199551, but got caught in a problem of preedit window placement - which currently seemed very random (unlike at the bottom of preedit string everytime in Gedit).

But all this being said, Abiword seems to be a very nice app, had very fast responses & has the ability to be ported to embedded devics like N800 maybe [wink]

…looking forward to use Abiword on my N800

An excellent event! & as usual, Ramky was onto his clicking spree just as the event started - even he & the professional photographer kinda conducted their own BOF at the event

Here is what Ramky had to offer me this morning

Me @ my presentation

Kartik & Me attending Karunakar’s presentation
Coincidence - well, not much - it was expected - Me & Karunakar were speaking on the same topic… but luckily enough, his & my audience were different - thanks to the 10 AM schedule wink; wink;

The amazing GNUnify staff - each one had an equivalent amount of such high energy levels that attending the event, for anyone - speakers & audience was a pleasure! Three cheers for them!
(Check out Ramky’s photo set for GNUnify 07)

For more pictures of the event, please head over to Ramky’s Flickr. His lens has some real magic!

I’m writing this entry while attending a Font development workshop by Karunakar & Ravi. The day went pretty well, with my presentation kickstarting the Localization track in Room 407

Everything went perfect, except that…

• The projector did not picked up my ATI display
• I had to give Fedora’s presentation on a Suse machine - thank god, it was atleast Linux!
• The Suse machine did not had any Indic fonts installed besides Hindi font
• Rendering in Suse was broken - probably it was using an older version of libicu (OO.org)
• OO.org presenter was crashing every time I was escaping from the presentation mode
• I had no root access to the machine, the machine’s owner was too nervous to enter it rightly
• I was unable to run most of my examples as I had no root access to install the translations
• SCIM was not in sight - not installed

Anyways, nothing hampered the presentation Things went pretty nicely with quite a lot of discussion during the presentation, though I had expected more.

I sincerely thank the GNUnify team for the event & for inviting me (& Red Hat) for a talk

Okay… back to the event, there’s an interesting presentation on “Debugging with GDB” coming up at 4pm!

PS: BTW, I was about to attend a presentation - “Web Automation & Testing with Sahi” - but the moment I entered the hall, I saw the guys configuring a Windows machine & I knew that it was time to leave for another presentation! Ramky has taken some interesting shots of the scene, I’ll add them as soon as I can grab them

Event’s pictures to come… stay tuned!

Tomorrow at GNUnify!

If you have used Evolution’s Calendar, this might be a regular window for you…

But change the “hours” scheme to a 24 hour format and it would look something like this…

Look again at the marked 00’s in the image above - dont they look like a translation error, as if AM/PM strings are being displayed as “00″?
Bug 223210 was filed on the same lines - & after a bit of investigation, it turned out to be a feature rather than a bug!

Actually, these 00’s are the markers for 0th minute (starting of the hour) & since there’s no meaning of the “AM/PM” string in a 24 hour format, these were added as markers.

But really, these markers even confused me at the first & after realizing that this is no bug, but can still confuse others, I came up with this…

The patch which does this is here

BTW, right clicking just near the 00 marker would show you the least used & almost hidden menu! - try it out

This Saturday/Sunday, I’ll be off to GNUnify’07 for a presentation on Fedora, titled - Internationalization on Fedora - What & How.

 

GNUify - Schedule | Wiki

Okay, just found out, I have the first presentation slot in the morning! phew! That means getting up again at around 6… whoa!

Straight to the solution…

If you want to determine more of such key mappings, have a look at “xev” command output. Run it in a terminal & hit the key you want the keymapping for.

Many thanks to Takahashi-san for this solution.

Just finished rebasing m17n-db-1.3.3 to m17n-db-1.3.4
It took a lot of time to make & remake the rpms to check for their validity, but finally m17n-db-1.3.4-1.fc7 is out in the wild.

—
ChangeLogs (straight from m17n-db.spec)

* Resolves: Bug 221794 - Rebased to new release m17n-db-1.3.4
* Removed patch: si-wijesekera_surrounding_to_preedit.patch
* Added directive to delete si-wijesekera from the upstream tarball as it used
surrounding text
* Commented directive to copy bopo-kbd.mim
* Commented directive using variable.mim and command.mim - added global.mim in place of them
* Added sections for new Uyghur.
* Added copy directive for Mizuochi (grc-*) keymap for classical greek
* Added directives to install translations for japanese translations.
* Added patch to rename si-wijesekera-preedit to si-wijesekera and add key
summary as Patch2

Next up… is an update for m17n-lib!

In the morning, I tried uploading pics from my yesterday’s “beach’y picnic” to zoto but zoto is not responding… I hope it comes back online asap. I’m even planning to buy a paid account on Flickr. Unlimited storage & 3gb monthly uploading should suffice all my needs… but it all has a price - USD 24.5

Meanwhile, here are some pics from yesterday’s saga

This is me, standing on top of our Sumo, trying into the deep valley behind us hahaha

Rama in the white, facing Manglesh (straighting his back) and Ravi (besides me).

When we gave Rama a “Sand Treatment”

Thanks to Ratish to take his Camera along… a trip worth remembering - more details when I upload all my pics

On wednesday, I reopened the bug 206439 when Aman pointed the following to us…

Okay, this seemed a translation bug. Down to the debugging & I found that Comment 12 was where the bug coming from. Giving it a round of translation was the first thing on my mind… which was not very well received by the code. The code was parsing the translation & separating it for day names on the basis of length… not a good thing.

Ankit then suggested to keep the day names in separate strings, so they can be separately be translated. This would bring sanity to both the code & the translations. But however, this induced another problem… Since the day names were being used as “MTWTFSS” (initials!), marking Saturday’s S and Sunday’s S separately was another issue. Gettext has a rule to mark duplicate strings as a single translatable string. Carlos at #i18n (irc.gnome.org) suggested to use contexts in strings which are to be marked for translation… which led to this patch.

…now Evo rests in peace… atleast for two days of this weekend - during which I plan to hack m17n-db for bug 198325 to move my Mapper from a pre-pre-alpha+buggy version to a alpha version atleast!

It looks like this in its current state…

Just fixed Gnome Bz 385414 with this one line patch!

I was revolving around & around this line but not actually getting to it for about 6 days now! Initially I was following pure debugging approach to see how the bug is getting into the code, why i18n chars are being displayed as “???” when viewing message source… but was getting nowhere!

Then I decided to follow the approach I took in solving Gnome Bz 355766. I studied that why the bug (385414) was only in view source & not in normal message display. If Camel was to blame, the error would have been in the both views! Hence, I compared how is the implementation for both differing? & this led me straight to the html filter being added to the stream in function efh_format_source … & voila! Changing “CAMEL_MIME_FILTER_TOHTML_ESCAPE_8BIT” to “CAMEL_MIME_FILTER_TOHTML_PRESERVE_8BIT” did the trick!

Sometimes… solving a bug really means hacking the code!

Buggy screenshot and fixed screenshot.

I managed to squash one more Evolution bug - (downstream bug) 203058, (upstream bug) 324604. This fix has one of my biggest patches …infact, this bug required two of them, one for evolution & other for evolution-data-server.

I wonder why this bug creeped in when we already have a Quoted Printable strings parser in evolution-data-server code.

Chk this out…

The buggy screenshot!

The not so buggy one!

BTW… if you have a good look at my patches (patch for - e-d-s, evo), you’ll realize that i’m very bad at managing strings! I had to deal with lots of segfaults before making this patch run! …one more reason i love python!

When I saw this bug “[mail] Multi-lang text in Body is not printed”, I knew that it is something with the encoding of the message thats causing this bug.

After investigating, I found that HTML mails & those stored in drafts used to get printed nicely & not the ones which were composed (ASCII mode) & then printed.

Some code reading & I found that all the cases in which mails were getting printed, had them converted to text/html somewhere in the process.

Bingo! This patch does the same for printing (& print-preview’ing) of Ascii mails
Sometimes… working intelligently is better than working hard

Lots of time I’ve seen & answered this question…

“How do I enable language support for my XXX language”

So let me answer this once more & i’ll point everyone back to this post… lazy me

The word “support” might mean getting fonts for your language, seeing correct rendering for characters of your language, getting to type in your language… etc

So follow these generic steps…

Assumptions - We are setting up Hindi support, we have an internet connection

*1)* Fire up gnome-terminal & execute “su -”
*2)* Perform “yum install scim scim-m17n”
—> Scim is “Smart Common Input Method” and is an input method engine which we’ll use to input language characters.
*3)* Update pango with “yum update pango”
—> Pango needs to be kept updated always as newer versions have a high possibility of more & more bugs being ironed out.
*4)* Install hindi fonts with “yum install fonts-hindi”
—> If you see boxes in the interface when starting gedit as “LANG=hi_IN gedit”, its a sure shot sign that you are missing fonts for your language (hi_IN in our case). Fedora uses Lohit font family.
*5)* Now install m17n support for HIndi with “yum install m17n-db-hindi”
—> This is the package for keyboard layouts.

Now,
*1)* Run gedit, right click in the editor area, go to “Input Methods” submenu, select “SCIM”
*2)* Hit [ctrl]+[space] to activate scim. Select Hindi (inscript) from the scim toolbar & start typing Hindi text.
*3)* To stop & switch back to English mode, hit [ctrl]+[space] again.

If on right clicking in gedit, there’s no submenu as “Input Methods”, try running

gconftool-2 --type bool --set '/desktop/gnome/interface/show_input_method_menu' true

from the terminal.

How to tackle problems you might face…
*A)* Rendering issues
—> Log onto Fedora Bugzilla & file a bug. The more bugs you file, the better support will be for your language.

*B)* You cannot find your language’s fonts in Lohit project
—> Google for your fonts, put them in /usr/share/fonts & run “fc-cache”. Otherwise, Fedora bugzilla is always there.

*C)* Inputting problems
—> Check if the keyboard layout for your language is correct. All m17n layouts are stored in /usr/share/m17n/ as .mim files. You can ping me or file a bug in Fedora bugzilla if you need any help regarding this.

*D)* All others…
—> Join fedora-i18n discussion list & let the concerned ones know that you have found a bug or are facing a problem. You’ll be amazed at how readily you’ll get help
—> You can also log onto #fedora-i18n channel on irc.freenode.net IRC server for instant help.

Good luck

*Comments/suggestions welcome :)*