1. Meera font was small compared to other fonts. This was not really a problem in Gnome environment since fontconfig allows you to define a scaling factor to match other font size. But it was an issue in Libreoffice, KDE and mainly in Windows where this kind of scaling feature does not work. Thanks to P Suresh for a rework on glyphs and fixing this issue.
2. Rachana, Meera and Dyuthi had wrong glyphs used as placeholder glyphs. Bugs like these are fixed.
3. Virama 0D4D had a wrong LSB that cause the cursor positioning and glyph boundary go wrong. Fixed that bug
   
4. Atomic Chilu code points introduced in Unicode 5.1 was missing in all the fonts that SMC maintained because of the controversial decision by Unicode and SMC’s stand against that. Issues still exist, but content with code point is present, to avoid any difficulties to users, added those characters to Meera and Rachana fonts.
   
5. Rupee Symbols added to Meera and Rachana. Thanks to Hiran for designing Sans and Serif glyphs for Rupee.
   
6. Dot Reph(0D4E) – The glyphs for this was already present in Meera but unmapped to any unicode point. GSUB Lookup tables added to the glyphs according to unicode specification.
   

For a more detailed change description see this mail thread. There are some minor changes as well.

Thanks to Hussain K H (designer of both Meera and Rachana) , P Suresh, Hiran for their valuable contribution. And thanks to SMC community and font users for using the fonts and reporting bugs. We hope that we can bring this new version in your favorite GNU/Linux distros soon. Wikimedia’s WebFonts extension uses Meera font and the font will be updated there soon. Next release of GNU Freefont is expected to update Malayalam glyphs using Meera and Rachana for freefont-sans and freefont-serif font respectively. We plan to update other fonts we maintain also with these changes in next versions. There are still some glyphs missing in these fonts with respect to the latest unicode version.

Releasing the offline version of a wikisource is a challenging project. The technical aspects of the project was designed and implemented by myself. So let me share the details of the project.

As you know a Wikisource contains lot of books, and each book varies in its size, it is divided to chapters or sections. There is no common pattern for books. Each having its own structure. A novel presentation is different from a collection of poems from a Poet. Wikisource also has religious books like Bible, Quran, Bhagavat Geeta, Ramayana etc.  Since books are for continuous reading for a long time, the readabilty and how we present the lengthy chapters in screen also matters. Offline wikipedia tools for example, Kiwix does not do any layout modification of the content and present as it is shown in wikipedia/wikisource. The tool we wrote last year for Malayalam wikipedia offline version also present scrollable vertical content in the screen. Both are not configurable to give different presentation styles depending on the nature of the book.

What we wanted is a book reader kind of application interface.  Readers should be able to easily navigate to books, chapters. The chapter content will be very lengthy. For a long time reading of this content,  a lengthy vertically scrolled text is not a good idea. We also need to take care of the width of the lines.  If each line spans 80-90% of the screen, especially for a wide screen monitor, it is a strain for neck and eyes.

Screenshot of Offline version. Click to enlarge

The selection of books for the offline version was done by the active wikimedians at Wiksource. Some of the selected books was proof read by many volunteers within the last  2 weeks.

The tools used for extracting htmls were adhoc and adapted to meet the good presentation of each book. So there is nothing much to reuse here. Extracting the html and then taking the content part alone using pyquery and removing some unwanted sections from html- basically this is what our scripts did. The content is added to predefined HTML templates with proper CSS for the UI. CSS3 multicolumn feature was used for book like interface. Since IE did not implement this standard even in IE9, for that browser the book like interface was not provided. Chrome browser with version less than 12 could not support, because of these bugs: http://code.google.com/p/chromium/issues/detail?id=45840 and http://code.google.com/p/chromium/issues/detail?id=78155. For easy navigation, mouse wheel support and page navigation buttons provided. For solving non-availability of required fonts, webfonts were integrated with a selection box  to select favorite font. Reader can also select the font size to make the reading comfortable.

Why static html? The variety of platforms and other versions we need to support, necessity to have webfonts, complex script rendering, effort to develop and customize UI, relatively small size of the data, avoiding any installation of software in users system etc made us to choose static html+ jquery + css as the technology choice. The downside is we could not provide full text search.

Apart from the wikisource, we also included a collection of copyleft of images from wikimedia commons. Thanks to Nishan Naseer, for preparing a gallery application using jquery. We selected 4 categories from Commons which are related to Kerala. We hope everybody will like the pictures and it will give  a small introduction to Wikimedia Commons.

Even though the python scripts are not ready to reuse in any projects, if anybody want to have a look at it, please mail me. I am not putting it in public since the script does not make sense outside the context of each book and its existing presentation in Malayalam wikisource.

The CD image is available for download here and one can also browse the CD content here.

Thanks to Shiju Alex for coordinating this project. And thanks to all Malayalam wikisource volunteers for making this happen.  We have included poems, folk songs, devotional songs, novel, grammar book, tales, books on Hinduism, Islam-ism, Christianity, Communism, Philosophy. With this release, it becomes the biggest offline digital archive of Malayalam books.

Apart from the existing characters in Indic languages,  Zero width Joiner and Zero width non joiners are widely used in Indic languages to control how the ligatures are formed. For some samples on how they are used, refer the wikipedia links. Being control characters and invisible characters, they are often removed while doing normalization , particularly before doing a string comparison, or collation (sort).

Identifiers, the strings that uniquely represent some data often has a policy on what kind of characters it can contain. For example, email address is an identifier, which unambiguously defines somebody’s email address, does not allow ‘space’ characters in between. Some examples for this kind of identifiers are: email ids, web domain address, variables in programming languages etc.

Gone are the days where identifiers can be represented only using English characters. Python 3.0+ allows  you to define a variable in program using any words that can be represented in Unicode. For more details on this Python feature read PEP 3131 – Supporting Non Ascii Identifiers . Some samples : Program written in Malayalam. In tamil , and In Hindi

Same is the case of Web addresses. With the advent of Internationalized Domain Names(IDN) that allows you register web addresses in your own languages, the English only web address scene is changing.

But this change brings some issues in the definition of ‘Identifiers’ – just like English, what are the characters allowed in using a domain name or programming language identifier that can be used? Standards and specifications are being drafted on this for each language. For Internationalized domain names in Indian languages, CDAC is drafting the policy. For python, the PEP 3131 has specification.

As a general rule, Unicode standard and the standards based on Unicode does not allow you use Unicode control characters such as zwj and zwnj in identifiers. Based on that The Internet Corporation for Assigned Names and Numbers (ICANN) , in RFC 3454 , it prohibits a list of control characters. RFC 3454 is used as a specification for converting a Unicode encoded domain name to its Punicode version for doing the validation.  For example,Thottingal, in Malayalam- തോട്ടിങ്ങല്‍ (0D24 0D4B 0D1F 0D4D 0D1F 0D3F 0D19 0D4D 0D19 0D32 0D4D 200D), when converted to punicode becomes xn--fwcaqax2g2d7dtadc . This conversion excludes the zwj at the end of the word. If I do a reverse conversion from xn--fwcaqax2g2d7dtadc to unicode what I get is തോട്ടിങ്ങല് (0D24 0D4B 0D1F 0D4D 0D1F 0D3F 0D19 0D4D 0D19 0D32 0D4D). Note that codepoint 200D – ZWJ is removed. That means I cannot register my domain thottingal.in in Malayalam properly. You can verify this using ICU online converter.  Now another example, Tamilnadu – in Malayalam തമിഴ്‌നാട് (0D24 0D2E 0D3F 0D34 0D4D 200C 0D28 0D3E 0D1F 0D4D) becomes xn--lwcjmx4a2de7id. When I do a reverse conversion, I getതമിഴ്നാട് (0D24 0D2E 0D3F 0D34 0D4D 0D28 0D3E 0D1F 0D4D) . Now ZWNJ(200C) is missed. Try yourself using the converter . This means one cannot register a website with Tamilnadu written in Malayalam properly. The IDN policies for Indic languages are based on this exclusion rules for zwj, zwnj.

For python 3.0+ ,  you cannot have an identifier in programming language with zwj, zwnj  or any control character in it. See this bug report for more details: Issue 5358

All of the above issues are because of the assumption that zwj,zwnj is prohibited from Identifiers for all cases. But that is not true. Look at the Unicode Standard Annex 31 – “Unicode Identifier and Pattern Syntax”(TR31). TR31 is based on Public Review 96 – “Allowing Special Characters in Identifiers”

This annex describes specifications for recommended defaults for the use of Unicode in the definitions of identifiers and in pattern-based syntax. It also supplies guidelines for use of normalization with identifiers. [...]

default-ignorable characters are normally excluded from Unicode identifiers. However, visible distinctions created by certain format characters (particularly the Join_Control characters) are necessary in certain languages. A blanket exclusion of these characters makes it impossible to create identifiers with the correct visual appearance for common words or phrases in those languages. Identifier systems that attempt to provide more natural representations of terms in modern, customary use should allow these characters in input and display, but limit them to contexts in which they are necessary. [...]

But since the characters are invisible, to meet the security considerations,  It should be clearly defined where and all we can use them. What if a domain is registered with 5 zwnj  continuously in it? It will look same to a string with 4 zwnjs. So TR31 defines 3 valid cases where zwnj and zwj can be used in an Identifier.

• Allow ZWNJ in breaking a cursive connection
• Allow ZWNJ in a conjunct context (example:  തമിഴ്‌നാട് , ദൃക്‌സാക്ഷി)
• Allow ZWJ in a conjunct context (examples:  ന + ് + zwj -> ന്‍ ,  क+  ् +  zwj -> क्‍ )

These 3 cases covers all zwj,zwnj usage patterns in our languages.

So now it is clear that Unicode standard allows them in Identifiers. In that case, there should not be a conflict between Unicode Identifier policy and ICANN policy or any other identifier policy such as PEP 3131. Blanket exclusion of these characters are not allowed. So RFC 3454 should be compatible with TR31. The IDN policy of Indic languages should be based on that new specification and not based on the existing RFC 3454. Since CDAC is responsible of Indic Domain policy, they should take responsibility for bringing this change.

For making a change in PEP 3131, myself and Baiju M started a wiki page explaining what change need to be done. Read it from here.

Having said that, is it desirable to have  two domains,  one with a valid zwj/zwnj usage and another without them? Of course, they will be visually different, avoiding any possibilities for spoofing. Now the question is whether those  two words represent two words in the language?

As far as Malayalam is concerned there are three cases here:

1. Missing ZWJ is considered as a spelling mistake – തമിഴ്‌നാട് (correct), തമിഴ്നാട് (incorrect) pair is an example for that.  Should we allow both domains ? I don’t know any case where a missing ZWNJ form another valid word with different meaning.
2. Missing ZWJ means , the word is a different word with different meaning. This is very rare – വന്‍യവനിക , വന്യവനിക pair is often cited an example for this. But many people argues this is not a valid case.
3. Missing ZWJ never means a spelling mistake, but just a writing style. There are many examples for this. നന്‍മ-നന്മ is one obvious one.

So the question is whether a domain differing by a valid zwj/zwnj use  to an existing registered domain to be allowed or not? I would suggest to use existing policy for domain comparison for this. ie, If the collation weights of existing domain and to-be registered domains are same ,  don’t register the new one. ZWJ, ZWNJ are characters with zero collation weight and in collation or string comparison they are ignored.

Both of these bots were well received  by the users. We have 8000+ users for English-Malayalam Dictionary.  Online blogs/media also gave good publicity. Thanks a lot!.

SMC developers Rajeesh Nambiar, Ershad, Ragsagar, and  Sarath Lakshman had helped in improving the program. You can get the source code from here. It is a small program written using python XMPP library.

We had written this programs one year back, 2009 december itself. We could not launch them for public since we did not had a server to host them.  Usually webhosting providers wont allow to run programs like this in their servers. Recently netdotnet.com provided a VPS server for SMC and we could launch them from that server.

English-Hindi dictionary is reasonably big, but English-Malayalm is very small with only ~10k words. So we just added a Malayalam Wiktionary backend for the bot.

Here is a video on how to use English-Hindi bot prepared by  Varun Verma

• An article about English Malayalam bot in Epathram.com here.
• A blog post by Sailesh in Hindi http://emadad.hindyugm.com/2010/10/know-hindi-meanings-while-chatting.html

We can start this kind of bot for other languages too, if we have dictionaries with Free S/w compatible licenses. If interested, please contact me.

The idea was to get the selected articles in static form to the CD. But this is not easy as we imagine. It is not like saving each  page from browser to the local machine. Following were the challenges:

• Automate the process of getting the page and the images in it. Wikipedia articles changes frequently. So we need the program to fetch the latest article from wiki whenever it is executed.
• Fix all the links, css, javascript, image references so that all resolves within CD itself
• Provide an categorized index of the articles for easily locating the article.
• Provide a search in the article titles.
• ISO 9660 filesystem of CD/DVD has lots of limitations. There are restrictions on unicode names of the files, length of the file names, directory depth, special characters in filenames etc. Wikipedia has its article and image names with unicode, special characters and most of the time they exceeds the filename length. To avoid all these, we should rename most of the files and then fix the cross references in all files.
• It should work on all Operating systems. All the content should be presented with HTML, Javascript and CSS. Being the content in Malayalam, even if the user does not have required fonts in her/his machine, there should not be any problem for reading the content(font embedding required).

Manually solving all these challenges is not the way to go. So I wrote a program, which just takes the article titles and does all the above tasks and finally creates a repository ready for burning to CD ROM.

Wget disappointed me in fetching the content from wiki. There is an open bug in wget which make the download of non-latin URLs impossible.

Have a look at the CD content we created : Malayalam Wikipedia Selected 500 Articles . Hiran helped me with the artworks.

Since entire process is automated, the program can be used for any other language.  I am releasing the program for the benefit of everybody. You can get the program from here. It is written on Python. Jquery was used for the UI.  For details on the usage, customization etc read the wiki page of the project.

For those who can’t read Malayalam, here is a sample wiki created  by the wiki2cd program from English wikipedia by selecting 10 articles.

Malayalam Wikipedia Community  hope that this is a big step to reach the majority of the people who does not have internet access. If printed, this 500 articles will be at least 5000 pages. CDROM also includes information about commonly used free software based tools for Malayalam computing. Some writing tools and fonts are distributed in the same CD ROM.

Thanks to Malayalam Wikipedia for giving this great opportunity to wok on this project.

The ISO image of the CD is available here for download.

ചങ്ങാതിമാരേ,
കേരളത്തിലെ രസകരമായ പ്രാദേശിക ഭാഷാ ഭേദങ്ങളെക്കുറിച്ചു് നിങ്ങള്‍ക്കെല്ലാമറിയാമല്ലോ? തിരുവനന്തപുരം, കോട്ടയം, തൃശ്ശൂര്‍, ഷൊര്‍ണ്ണൂര്‍, പാലക്കാട്, കോഴിക്കോട് കണ്ണൂര്‍, വയനാട് തുടങ്ങി നമുക്കു് വ്യത്യസ്തങ്ങളായ മലയാളത്തിന്റെ രൂപഭേദങ്ങളുണ്ടു്. അച്ചടി മലയാളത്തില്‍ നിന്നും വളരെയേറെ വ്യത്യസ്തമാണു് അവ. അച്ചടി മലയാളം കൊടുത്തു് സ്ഥലത്തിന്റെ പേരു കൊടുത്താല്‍ ആ പ്രദേശത്തെ മലയാളത്തിന്റെ രീതിയിലേക്കു അതിനെ മാറ്റിത്തരുന്ന ഒരു സോഫ്റ്റ്‌വെയര്‍ രസകരമാവില്ലേ?

അത്തരത്തിലൊരു ശ്രമമാണു് “ക്ടാവ്” Slang converter എന്നു പേരിട്ടിരിക്കുന്ന പ്രൊജക്ട്. ഇതിന്റെ കൂടെ കൊടുത്തിരിക്കുന്ന സ്ക്രീന്‍ഷോട്ട് നോക്കൂ. ഡെവലപ്മെന്റ് പതിപ്പിന്റെ ചിത്രമാണതു്. കുറച്ചു നിയമങ്ങളുടെ അടിസ്ഥാനത്തില്‍ Natural Language Processing ന്റെ പുതിയ ശാഖയായ AMP(Ambiguous Language Processing) എന്ന വിദ്യ ഉപയോഗിച്ചാണു് ഇതു ചെയ്തിരിക്കുന്നതു്. Qt/C++ ആണു് കോഡ്. UI ചെയ്യാന്‍ Qt Creator ഉപയോഗിച്ചു.

ഒരു മലയാളം ഫയലില്‍ പല സ്ലാങ്ങില്‍ തിരയാനുള്ള സംവിധാനവും തയ്യാറാക്കാന്‍ പദ്ധതിയുണ്ടു് . അതായതു് ഗഡി എന്നു തിരഞ്ഞാല്‍ സുഹൃത്തു് , ചങ്ങാതി എന്നൊക്കെ കിട്ടണം. പിന്നെ ഗഡി എന്നു സ്പെല്ലിങ്ങ് തെറ്റിച്ചെഴുതിയാല്‍ സുഹൃത്ത്, ചങ്ങാതി എന്നൊക്കെ സ്പെല്‍ചെക്കറില്‍ സൂചന വരാനുള്ള ഫീച്ചറും നമുക്കു് ചെയ്യണം. GPL V3 ലൈസന്‍സിലുള്ള ഈ അപ്ലിക്കേഷനു് ഇതിന്റെ നിയമങ്ങള്‍ വിപുലപ്പെടുത്താനും ടെസ്റ്റ് ചെയ്യാനും വിവിധ ജില്ലകളില്‍ താമസിക്കുന്നവരില്‍ നിന്നുള്ള സഹായം ആവശ്യമുണ്ടു്.

സഹകരിക്കുമല്ലോ.

അഭിപ്രായങ്ങളറിയിക്കുക.

താഴെപ്പറയുന്ന നിയമങ്ങളുടെ അടിസ്ഥാനത്തിലാണു് മലയാളം അകാരാദിക്രമം തയ്യാറാക്കിയിരിക്കുന്നതു്.

1. അക്ഷരമാലാക്രമം പിന്തുടരുക.
2. അനുസ്വാരം മയുടെ സ്വരസാന്നിദ്ധ്യമില്ലാത്ത രൂപമായി പരിഗണിച്ചു് മയുടെ തൊട്ടുമുന്നില്‍ ക്രമീകരിയ്ക്കുക. പംപ < പമ്പ എന്ന പോലെ .
3. ഓരോ വ്യഞ്ജനവും അതിന്റെ സ്വരസാന്നിദ്ധ്യമില്ലാത്ത രൂപത്തിന്റെ കൂടെ അകാരം ഉള്ള രൂപമായി കണക്കാക്കുക. അതായതു് ത എന്നതു് ത് എന്ന സ്വരസാന്നിദ്ധ്യമില്ലാത്ത വ്യഞ്ജനത്തിന്റെ കൂടെ അകാരം ഉള്ള രൂപമാണു്. ത = ത് + അ . താ = ത് + ആ എന്നിങ്ങനെ. ഇതില്‍ നിന്നും ത് < ത എന്നു വ്യക്തമാകുന്നു. അതുകൊണ്ടു് ത എന്നതു് ത് കഴിഞ്ഞേ വരൂ. അത് < അതല്ല < അതാണു്. അതേസമയം അത്ഭുതം > അതഭ. കൂട്ടക്ഷരങ്ങള്‍ അതിലെ ആദ്യത്തെ അക്ഷരത്തില്‍ സ്വരചിഹങ്ങള്‍ ചേര്‍ന്ന രൂപങ്ങളെല്ലാം കഴിഞ്ഞേ വരൂ.
   ത്ഭ = ത + ് + ഭ + ് + അ
   തഭ = ത + ് + അ + ഭ + ് + അ
   ആദ്യത്തെ രണ്ടക്ഷരങ്ങള്‍ തുല്യമായതുകൊണ്ടു്, ഇതിനെ നമുക്കു്
   ഭ + ് + അ
   അ + ഭ + ് + അ
   എന്നെഴുതാം. ഭ > അ ആണല്ലോ. അതുകൊണ്ടു് അത്ഭുതം എന്നതു് അതഭ എന്നതിനു ശേഷമേ വരൂ.
4. ചില്ലക്ഷരങ്ങള്‍ അതാതിന്റെ വ്യഞ്ജങ്ങളുടെ സ്വരമില്ലാത്ത രൂപങ്ങളായതിനാല്‍ മേല്‍പറഞ്ഞപോലെ ക്രമീകരിക്കപ്പെടും. അതായതു് ര്‍ < ര . ഉദാഹരണം:
   അവര്
   
   അവര്‍
   
   അവര
5. സംവൃതോകാരം ഉകാരത്തിനു തൊട്ടു പിന്നില്‍ വരും. അതു് < അതു
6. മലയാളം അക്കങ്ങള്‍ അവയുടെ അറബി ലിപികളുടെ കൂടെ തന്നെ വരും.
   1
   
   १०
   
   2
   
   ൨
   
   3
   
   ३०
   എന്ന രീതിയില്‍
7. കൌ, കൗ എന്നിവ തുല്യങ്ങളായി കണക്കാക്കപ്പെടും.
   കൗ
   
   കൌ
   എന്ന രീതിയില്‍
8. ഒ, ഓ, ഔ എന്നിവയുടെ സ്വരചിഹനങ്ങള്‍ യഥാക്രമം ൊ , ോ , ൌ എന്നോ െ+ ാ , േ+ ാ , െ+ ൗ എന്നോ എഴുതിയാലും തുല്യമായി കണക്കാക്കും(Canonical Equivalence)

ഈ വിഷയത്തെപ്പറ്റി നടന്ന ചര്‍ച്ചയും കൂടുതല്‍ വിവരങ്ങളും ഇവിടെ . പ്രത്യേകിച്ചു പ്രശ്നങ്ങളൊന്നുമില്ലെങ്കില്‍ യൂണിക്കോഡ് കൊളേഷന്‍ തിരുത്തി ശരിയാക്കാന്‍ ഇതു് അടിസ്ഥാനമാക്കാം.

“Development of effective geo-visualisation based decision support system (DSS) involved primarily data compilation from collateral sources, setting up appropriate hardware configuration, design of database and design of a spatial DSS. ”

Jaisen used softwares like GRASS, UMN MapServer and ka-Map. He has written a detailed documentation(English) on how he developed this and what are all the tools used.

സ്വതന്ത്ര മലയാളം കമ്പ്യൂട്ടിങ്ങ് UTC യ്ക്ക് സമര്‍പ്പിച്ച ഈ ഡോക്യുമെന്റില്‍ വിയോജിപ്പുകള്‍ പറഞ്ഞിട്ടുണ്ടു്. ഇതിനെപ്പറ്റി നടന്ന ചര്‍ച്ചകളുടെ ലിങ്കുകള്‍ ചിലതു് ഇവിടെ നിന്നും വായിക്കാം.

മലയാളത്തെ ഡുവല്‍ എന്‍കോഡിങ്ങിലേയ്ക്കും സുരക്ഷാപ്രശ്നങ്ങളിലേയ്ക്കും തള്ളിവിടുന്ന ഒരു സ്റ്റാന്‍ഡേഡ് അനുസരിക്കേണ്ട ബാദ്ധ്യത സ്വതന്ത്ര മലയാളം കമ്പ്യൂട്ടിങ്ങിനില്ല. സ്വതന്ത്ര മലയാളം കമ്പ്യൂട്ടിങ്ങ് ഭാഷയ്ക്കു വേണ്ടിയാണു്, യൂണിക്കോഡിനു വേണ്ടിയല്ല നിലകൊള്ളുന്നതു്. അതുകൊണ്ടു തന്നെ ഉന്നയിച്ച പ്രശ്നങ്ങള്‍ക്കു് പരിഹാരമാവാതെ 5.0 പതിപ്പില്‍ നിന്നു 5.1 പതിപ്പിലേയ്ക്കു് സ്വതന്ത്ര മലയാളം കമ്പ്യൂട്ടിങ്ങ് പ്രൊജക്ടുകള്‍ മാറില്ല. പക്ഷേ ഒരു സ്റ്റാന്‍ഡേഡ് എന്ന നിലയ്ക്ക് ആര്‍ക്കും യൂണിക്കോഡ് 5.1 അപ്ലിക്കേഷനുകളില്‍ പ്രയോഗിക്കാന്‍ സ്വാതന്ത്ര്യവുമുണ്ടു്. പക്ഷേ സ്വതന്ത്ര മലയാളം കമ്പ്യുട്ടിങ്ങ് മെയിന്റെയിന്‍ ചെയ്യുന്ന/വികസിപ്പിച്ചെടുത്ത ഫോണ്ടുകളായ മീര, രചന, ദ്യുതി, തുടങ്ങിയ ഫോണ്ടുകളിലൊന്നും അറ്റോമിക് ചില്ലു് ഉണ്ടാവില്ല. അതുപോലെത്തന്നെ ഗ്നു/ലിനക്സിലെ നിവേശകരീതികളിലും മറ്റു സംരംഭങ്ങളിലും ഇവ അടുത്തൊന്നും ഉണ്ടാവില്ല. പ്രമുഖ ഗ്നു/ലിനക്സ് വിതരണങ്ങളുടെ മലയാളം ഫോണ്ടുകളുടെയും നിവേശകരീതികളുടെയും Upstream സ്വതന്ത്ര മലയാളം കമ്പ്യൂട്ടിങ്ങ് ആയതുകൊണ്ടു് അവയിലും അറ്റോമിക് ചില്ലുണ്ടാവില്ല.

ഇപ്പോള്‍ അറ്റോമിക് ചില്ലു് നിലവിലുള്ളതു് അഞ്ജലി ഫോണ്ടിലും, വരമൊഴി/മൊഴി എന്നിവയുടെ പുതിയ പതിപ്പിലും മാത്രമാണു്. അവയുടെ പുതിയ പതിപ്പുകള്‍ ഉപയോഗിച്ചെഴുതിയ ചില ബ്ലോഗുകള്‍ അഞ്ജലിയൊഴികെയുള്ള ഫോണ്ടുകള്‍ കൊണ്ടു് വായിക്കാന്‍ ബുദ്ധിമുട്ടാകുന്നപ്രശ്നം നിലവിലുണ്ടു്. ചില്ലക്ഷരങ്ങള്‍ക്കു പകരം വട്ടത്തിനകത്ത് R എന്ന അക്ഷരമാവും കാണുക. ഏവൂരാന്‍ജി അതിനുവേണ്ടി രഘുമലയാളം എന്ന ഫോണ്ടിനെ മാറ്റിയെടുക്കാന്‍ ശ്രമം നടത്തുകയുണ്ടായി .

പക്ഷേ തെറ്റായ സ്റ്റാന്‍ഡേഡിനുവേണ്ടി ഫോണ്ടുകളെ മാറ്റാതെത്തന്നെ പുതിയ ചില്ലുകളുള്ള ബ്ലോഗുകള്‍ പ്രശ്നമൊന്നുമില്ലാതെ കാണാന്‍ വേണ്ടി, സ്വതന്ത്ര മലയാളം കമ്പ്യൂട്ടിങ്ങ് ഫയര്‍ഫോക്സ് ഉപയോഗിക്കുന്നവര്‍ക്കു വേണ്ടി ഒരു extension ഉണ്ടാക്കിയിട്ടുണ്ടു്. നിഷാന്‍ നസീര്‍ നിര്‍മ്മിച്ച fix-ml എന്ന extension ഡൗണ്‍ലോഡ് ചെയ്ത് ഇന്‍സ്റ്റാള്‍ ചെയ്താല്‍ ആണവചില്ലും ഏതു ഫോണ്ടും ഉപയോഗിച്ചു് വായിക്കാന്‍ കഴിയും. ഗ്രീസ് മങ്കി ഉപയോഗിക്കുന്നവരാണെങ്കില്‍ ഈ extension തന്നെ ഗ്രീസ് മങ്കി സ്ക്രിപ്റ്റായി ഇവിടെ നിന്നു ഡൌണ്‍ലോഡ് ചെയ്തു് ഉപയോഗിയ്ക്കാം.

സംശയങ്ങള്‍ ഇവിടെ കമന്റായോ, സ്വതന്ത്ര മലയാളം കമ്പ്യൂട്ടിങ്ങിന്റെ മെയിലിങ്ങ് ലിസ്റ്റിലോ, irc.freenode.net ല്‍ ഉള്ള #smc-project എന്ന IRC ചാനലിലോ ചോദിയ്ക്കാം
മെയിലിങ്ങ് ലിസ്റ്റിലെ ഈ ത്രെഡും കാണുക.

It is available here: An open letter to Mammootty. I request all to endorse Open letter to Mammooty by adding your name there.

A nice post on ILUG-TVM on the issue: Another of M$’s dirty tactics