കമ്പ്യൂട്ടറിനു മനസ്സിലാവുന്ന ഭാഷ 0, 1 എന്നീ സംഖ്യകൾ മാത്രമാണ്. ഇവയെ ബിറ്റ് എന്നു പറയുന്നു. ഈ ബിറ്റുകളുടെ വിവിധ കോമ്പിനേഷനുകള് ഉപയോഗിച്ചാണ് കമ്പ്യൂട്ടറുകള് വിവരങ്ങള് സൂക്ഷിക്കുന്നതും സംസ്കരിക്കുന്നതും. സംഖ്യകളായാലും ചിത്രങ്ങളായാലും അങ്ങനെ തന്നെ. എന്നാല്, സംഖ്യയും ചിത്രവും എടുത്തുവയ്ക്കാനാവശ്യമായ ബിറ്റുകളുടെ എണ്ണത്തില് കാര്യമായ വ്യത്യാസമുണ്ട്. ഒരു സംഖ്യക്ക് മുപ്പത് ബിറ്റുകളാണ് വേണ്ടതെങ്കില്, ഒരു ചിത്രത്തിന് മുപ്പതിനായിരവും മുപ്പത് ലക്ഷവും ഒക്കെ ബിറ്റുകള് വേണ്ടി വരും.
a,b,c എന്നിങ്ങനെ അക്ഷരങ്ങളുടെ ഒരു കൂട്ടമാണല്ലോ ഒരു ഡോക്യുമെന്റ്. ഓരോ അക്ഷരത്തേയും ചിത്രമായി എടുത്തുവച്ചാല് ഡോക്യുമെന്റിന്റെ വലുപ്പം വല്ലാതെ കൂടും. അതിനൊരു പോംവഴിയായി കണ്ടുപിടിച്ച മാര്ഗമാണ് ഓരോ അക്ഷരത്തിനും ഒരു കോഡ്നമ്പര് കൊടുക്കുക എന്നത്. ഈ രീതിയെ എന്കോഡിങ് എന്നുപറയും. പല എന്കോഡിങ് രീതികളുണ്ടായതില് ഏറ്റവും പോപ്പുലറായ എന്കോഡിങ് രീതിയാണ് ആസ്കി. അതില് 65 എന്നാല് A ആണ്; 66 എന്നാല് B; എന്നിങ്ങനെ പോകുന്നു.
എന്നാല് ആസ്കി എന്ന ഈ അക്ഷരസംഖ്യ മാത്രം പോരല്ലോ അക്ഷരം കമ്പ്യൂട്ടര് മോണിറ്ററില് തെളിയാന്. അക്ഷരരൂപവും വേണം. അക്ഷരരൂപങ്ങളുടെ പട്ടികയാണ് ഫോണ്ട് എന്നറിയപ്പെടുന്നത്. അതില് ഒരു കോളത്തില് 65, 66, എന്നിങ്ങനെ എന്കോഡിങ് സംഖ്യകള് (അക്ഷരസംഖ്യ) കൊടുത്തിരിക്കും. അപ്പുറത്തെ കോളത്തില് ആ അക്ഷരത്തിന്റെ രൂപം ചിത്രങ്ങളായോ ഗണിത ഫോര്മുലകളായോ എഴുതി വച്ചിരിക്കുന്നു. ഈ ചിത്രങ്ങളും ഗണിത ഫോര്മുലകളും കമ്പ്യൂട്ടറുകള്, മോണിറ്ററിലോ പ്രിന്ററിലോ വളരെ ചെറിയ ഡോട്ടുകളായി (pixels) വരയ്ക്കുന്നതാണു അക്ഷരങ്ങളായി കമ്പ്യൂട്ടര് ഉപഭോക്താക്കള് കാണുന്നതു്.
ഫോണ്ട് ടേബിളില് ആസ്കി നിശ്ചയിച്ചിരിക്കുന്ന അക്ഷരങ്ങള് മാറ്റി, പകരം അവിടെ മലയാളം അക്ഷരരൂപങ്ങള് (glyphs) വരച്ചാണ് മാതൃഭൂമി, മനോരമ, ദീപിക, വെബ്ലോകം തുടങ്ങിയ സൈറ്റുകള് മലയാളം പ്രദര്ശിപ്പിക്കുന്നത്. ഇത്തരം ഫോണ്ടുകള് അതാത് പത്രങ്ങളുടെ മാത്രമാണ്. അതാത് പത്രങ്ങളുടെ ഫോണ്ടോടുകൂടി മാത്രമേ ആ പത്രത്തിന്റെ ഡോക്യുമെന്റുകള് കാണാനാവൂ. ആസ്കീ വിലകളെ ഒരു പ്രത്യേക രീതിയില് ഫോര്മാറ്റ് ചെയ്താല് കമ്പ്യൂട്ടറുകള് ആ വിലകളെ ഫോര്മാറ്റില് നിര്ദ്ദേശിച്ചിരിക്കുന്ന ഫോണ്ടു് ഉപയോഗിച്ചു കൃത്യമായി പ്രദര്ശിപ്പിക്കും (ഫോണ്ട് കമ്പ്യൂട്ടറില് ലഭ്യമായിരിക്കണം) എന്നതാണു ഈ രീതിയുടെ സാങ്കേതികവശം. ഈ ഒരു സങ്കേതം കൂടുതല് പ്രശ്നങ്ങളിലേയ്ക്കാണു കമ്പ്യൂട്ടറുകളെ കൊണ്ടുപോകുന്നതു്. ടെക്സ്റ്റിനോടുകൂടെ ഫോണ്ട്/ഫോര്മാറ്റ് എപ്പോഴും എടുത്തുവയ്ക്കാന് കഴിയാത്ത ചില സന്ദര്ഭങ്ങളുണ്ടു്, ഉദാഹാരണം ഡാറ്റാബേസില് ഒരു പദം സൂക്ഷിച്ചുവയ്ക്കുന്നതു്, വെബ്പേജുകള് തിരയുന്ന വേളയില്, ചില ഇ-മെയില് പ്രോഗ്രാമുകള് എന്നിങ്ങനെ. ആസ്കി ഫോണ്ട് ഉപയോഗിച്ചു ഡാറ്റാബേസില് സ്റ്റോര് ചെയ്തിരിക്കുന്ന ഒരു പദം ഉപയോഗത്തിനായി തിരിച്ചെടുക്കുമ്പോള് നേരത്തെ ഉപയോഗിച്ച ഫോര്മാറ്റ് പ്രകാരം തന്നെ വായിക്കപ്പെടേണ്ടി വരും. ഇത്തരം ഫോണ്ട് ഫോര്മാറ്റുകള് നഷ്ടപ്പെടുന്നതോടെ ഡാറ്റ ഉപയോഗശൂന്യമാവുമയും ചെയ്യുന്നു.
യൂണികോഡ് ഈ പ്രശ്നത്തിനുള്ള പ്രതിവിധിയാണു്. യൂണികോഡ് ഒരു ഫോണ്ടല്ല. ആസ്കി എന്ന എന്കോഡിങ് രീതിയെ വിപുലപ്പെടുത്തിയതാണ് യുണിക്കോഡ്. ആസ്കിയില് ഇംഗ്ലീഷ് അക്ഷരമാല മാത്രമേ എന്കോഡ് ചെയ്യപ്പെട്ടിട്ടുള്ളൂ. യുണീക്കോഡിലാവട്ടേ, ലോകത്തിലെ എല്ലാ ഭാഷകളും എന്കോഡ് ചെയ്തിട്ടുണ്ട്. അതില് മലയാളം 'അ'കാരത്തിന് 3333 ആണ് അക്ഷരസംഖ്യ. 'ആ'കാരത്തിന് 3334 എന്നിങ്ങനെ. അതുകൊണ്ട് മാതൃഭൂമി, മനോരമ തുടങ്ങി പ്രത്യേക ഫോണ്ടുകള് ഉപയോഗിക്കാതെ തന്നെ മലയാളം വാക്കുകളെ തിരിച്ചറിയുവാന് കമ്പ്യൂട്ടറുകള്ക്കു കഴിയുകയും ചെയ്യും.
ഇപ്പോള് ഫോണ്ടുകള്ക്കുള്ള പ്രസക്തി യൂണികോഡ് സ്റ്റാന്ഡേര്ഡിലെ വിലകളെ ഏതു് ആകൃതിയില് പ്രദര്ശിപ്പിക്കണം എന്നു നിശ്ചയിക്കുന്നതിലാണു്. അതിനായി യൂണികോഡില് ഫോണ്ട് ഫോര്മാറ്റുകള് പ്രയോഗിക്കാവുന്നതാണു്, പല ആകൃതിയിലും ലിപികള് പ്രദര്ശിപ്പിക്കാവുന്നതുമാണു്. ഏതെങ്കിലും ഒരു അവസരത്തില് ഈ ഫോണ്ട് ഫോര്മാറ്റുകള് നഷ്ടമാവുകയാണെങ്കില് തന്നെയും ഡാറ്റ നഷ്ടപ്പെടുകയില്ല. നെറ്റില് ഒരു പദം സേര്ച്ച് ചെയ്യുന്നതിന്റെ അതു പ്രത്യേക ആകൃതിയില് പ്രദര്ശിപ്പിക്കപ്പെടണം എന്നു നിര്ബന്ധമില്ലല്ലോ, യാതൊരുവിധ ഫോണ്ട് ആശ്രയത്വവും ഇല്ലാതെ തന്നെ ആ പദത്തെ സേര്ച്ച് സെര്വറുകള്ക്ക് തിരിച്ചറിയാനാവുകയും കൃത്യമായ ഉത്തരങ്ങള് നല്കുവാന് കഴിയും ചെയ്യുന്നു.
യൂണികോഡ് പഴയലിപിയോ പുതിയ ലിപിയോ ആയല്ല മലയാളം എഴുത്തിനെ കാണുന്നത്. പകരം ഓരോ വാക്കിലേയും അടിസ്ഥാന അക്ഷരങ്ങളാണ് ഒരു യൂണികോഡ് ഡോക്യുമെന്റില് എഴുതിവയ്ക്കുന്നത്. 'പുഞ്ച' എന്ന വാക്ക് യുണീക്കോഡ് കാണുന്നത്, 'പ + ഉ-ചിഹ്നം + ഞ + ചന്ദ്രക്കല + ച' എന്നിങ്ങനെ പിരിച്ചാണ്. ഈ നിയമത്തിന്റെ അടിസ്ഥാനത്തിലാണ് ഇ-മെയിലിലോ, വെബ് താളിലോ യൂണികോഡില് നമ്മള് എഴുതുന്നതെല്ലാം യൂണികോഡ് വായിച്ചെടുക്കുക. ഫോണ്ടാണ് ഈ ടെക്സ്റ്റിനെ പുതിയ ലിപിയിലാണോ പഴയലിപിയിലാണോ കാണിക്കേണ്ടതെന്ന് തീരുമാനിക്കുന്നത്.
എല്ലാ കൂട്ടക്ഷരങ്ങളുമുള്ള ഫോണ്ട് പഴയലിപിയില് ഒരു വാക്കിനെ കാണിക്കും. അതുപോലെ അധികം കൂട്ടക്ഷരങ്ങളില്ലാത്ത ഫോണ്ട് അതേ വാക്കിനെ തന്നെ പുതിയ ലിപിയിലായിരിക്കും ഉപയോക്താവിനെ കാണിക്കുക. പുതിയ ലിപിയോ പഴയ ലിപിയോ പിന്തുണയ്ക്കുന്ന യൂണികോഡ് ഫോണ്ടുകള് കമ്പ്യൂട്ടറില് സംസ്ഥാപിക്കാന് ഉപയോക്താവിന് കഴിയും. അതായത്, പ്രസാധകരല്ല, പകരം ഉപയോക്താവാണ് ഉള്ളടക്കം ഏത് ലിപിയിലാണ് കാണേണ്ടത് എന്നു തീരുമാനിക്കുന്നത്. ആസ്കി ഫോണ്ട് ഉപയോഗിച്ച് കടലാസില് അച്ചടിക്കുന്ന ടെക്സ്റ്റില് നിന്നും യൂണികോഡ് ടെക്സ്റ്റിനുള്ള പ്രധാന വ്യത്യാസമാണത്.
രചന, അഞ്ജലി തുടങ്ങിയ യൂണികോഡ് ഫോണ്ടുകള് പഴയലിപി ഫോണ്ടുകളാണ്. മൈക്രോസോഫ്റ്റിന്റെ കാര്ത്തിക പുതിയലിപി ഫോണ്ടാണ്. പുതിയ ലിപിയോ പഴയ ലിപിയോ നിര്ബന്ധമില്ലാത്തവര്ക്ക് അവരുടെ കമ്പ്യൂട്ടറില് ഏതായാലും മതി.
ചില്ലക്ഷരമുണ്ടാക്കാന് ഇന്ന് ഉപയോഗിക്കുന്ന രീതിയും ഭാവിയിലെ രീതിയും തമ്മില് വ്യത്യാസമുണ്ട്. പുതിയ രീതി ഏതാണ് ഒരു വര്ഷത്തിനുശേഷമേ ഒഫീഷ്യലായി സ്റ്റാന്റേഡില് എത്തുകയുള്ളൂ. അതുവരെ ഇന്നത്തെ രീതിതന്നെയാണ് ഉപയോഗിക്കുക.
ഇന്നത്തെ രീതിയില് ഒരോ ചില്ലക്ഷരവും ഒരു അടിസ്ഥാനവ്യഞ്ജനത്തിന്റെ വകഭേദമായാണ് പരിഗണിക്കുന്നത്:
ന് = ന + ് + zwj
പുതിയ സ്റ്റാന്റേഡില്, ചില്ലക്ഷരങ്ങള് ഓരോന്നിനും ഓരോ കോഡ് പ്രത്യേകം ഏര്പ്പെടുത്തിയിരിക്കുന്നു.
കൂടുതല് കാര്യങ്ങളിവിടെ.
Click to enlarge
മുകളില് വിവരിച്ചതില് നിന്നും അതിലെ മലയാളലിപിയെ വെട്ടിമുറിക്കാന് പോകുന്നു എന്ന ആക്ഷേപത്തിന് അടിസ്ഥാനമില്ല എന്ന് മനസ്സിലാവും. യുണിക്കോഡ് എന്താണെന്ന് കൃത്യമായി അറിയാത്തവരെ ആകുലരാക്കാന് ഉണ്ടാക്കിയ വാര്ത്തയാണത്.
വരികള്ക്കിടയിലൂടെ വായിച്ചാല് ആ വാര്ത്ത, ചില്ല് എന്കോഡ് ചെയ്യുന്നതിനുപിന്നിലെ സംവാദത്തേയും രാഷ്ട്രീയത്തെയും ആണ് വിവക്ഷിക്കുന്നത്.
ഒരു ഗവണ്മെന്റോ വ്യക്തിയോ സംഘടനയോ നിര്ദ്ദേശിക്കുന്നത് അന്ധമായി അനുസരിക്കുകയല്ല യുണീക്കോഡ് കണ്സോര്ഷ്യം ചെയ്യുന്നത്. അതിലെ വാദമുഖങ്ങളും പ്രതിവാദങ്ങളും പൊതുസദസ്സില് മാസങ്ങളും വര്ഷങ്ങളും ചര്ച്ചചെയ്താണ് ഒരു തീരുമാനത്തിലെത്തുന്നത്.
2004-ല് മലയാളം ചില്ലുകളെ പ്രത്യേകം എന്കോഡ് ചെയ്യണം എന്ന് കാണിച്ച് കേരള ഗവണ്മന്റ് ഒരു നിര്ദ്ദേശം മുന്നോട്ട് വച്ചിരുന്നു. അന്ന് സദസ്സ് അവതരിപ്പിച്ച വാദങ്ങള് വച്ച് ആ നിര്ദ്ദേശം യുണീക്കോഡ് അംഗീകരിക്കുകയും ചെയ്തു.
ആ നിര്ദ്ദേശത്തില് പാകപ്പിഴകളുണ്ടെന്ന് തോന്നിയ രചന അക്ഷരവേദി 2005-ല് പ്രതിവാദങ്ങള് യുണീക്കോഡ് ടെക്നിക്കല് കമ്മറ്റിക്ക് അയച്ചുകൊടുത്തു. അതനുസരിച്ച് മലയാളം ചില്ലുകളെ പ്രത്യേകം എന്കോഡ് ചെയ്യുന്നതില് നിന്നും യുണീക്കോഡ് കണ്സോര്ഷ്യം പിന്മാറി.
തുടര്ന്നുള്ള ചര്ച്ചകളില് കൂടുതല് വാദമുഖങ്ങള് ചില്ല് എന്കോഡ് ചെയ്യുന്നതിനനുകൂലമായി വന്നു. ഒരു കൊല്ലത്തിലേറെക്കാലം നീണ്ട ചൂടുപിടിച്ച ചര്ച്ചയായിരുന്നു ഇത്. ഒടുവില് പൊതുജനങ്ങളില് നിന്നും വിവിധവാദങ്ങള് സ്വീകരിച്ച ശേഷം, ഈ കാര്യത്തില് തീരുമാനമെടുക്കാന് ഒരു പ്രത്യേകസംഘത്തെ നിയോഗിച്ചു. ആ സംഘത്തിന്റെ തെളിവുകളുടെ അടിസ്ഥാനത്തില് ചില്ലുകളെ എന്കോഡ് ചെയ്യാന് തന്നെ യുണീക്കോഡ് കണ്സോര്ഷ്യം തീരുമാനിച്ചു.
ഈ ചര്ച്ചകളില് പങ്കെടുക്കാന് ആര്ക്കും സാധിക്കും. എല്ലാ മലയാളികളും അതിന് മുന്നോട്ട് വരണം എന്നാണ് എന്റെ അഭിപ്രായം. അതിനുവേണ്ടി ഈ പറഞ്ഞിരിക്കുന്ന പ്രകാരം indic@unicode.org മെയിലിംഗ് ലിസ്റ്റില് അംഗമാവുക; നിങ്ങളുടെ സുചിന്തിതമായ അഭിപ്രായമെഴുതുക.
മലയാളികളുടെ ഇടയില് നടന്ന കൂടുതല് ചര്ച്ചകള്:
മുഖ്യകാരണം: അവന്/അവന്, വന്യവനിയ/വന്യവനിക തുടങ്ങീ അര്ഥവ്യത്യാസമുള്ള അസംഖ്യം പെയറുകള് zwj എന്ന 0 കോലേഷന് വെയ്റ്റുള്ള ഇഗ്നോറബിള് ക്യാരക്റ്റര് കൊണ്ടുമാത്രം വ്യത്യാസപ്പെട്ടിരിക്കുന്നതാണ്.
അതിന് zwj ഇഗ്നോറബിള് അല്ലാതാക്കിക്കൂടേ എന്ന് വാദിക്കാം. എന്നാല് മലയാളം ഉള്പ്പെടെയുള്ള പല സ്ക്രിപ്റ്റുകളിലും ഉപയോഗിക്കുന്ന അക്ഷരമായതുകൊണ്ട് അതിന്റെ ഇമ്പാക്റ്റ് വളരെ കൂടുതലാണ്. കൊലേഷനും(അകാരാദിക്രമം) ശരിയാക്കാനുണ്ട്.
ഇതിനുപകരമൊരു സൊല്യൂഷനായി അവതരിപ്പിക്കപ്പെട്ടത് മലയാള അക്ഷരങ്ങളോട് ചേരുമ്പോള് ചില്ലുണ്ടാക്കുന്ന പുതിയൊരു അക്ഷരമാണ്. ഇതിന്റെ ഒരു പ്രശ്നം കോമ്പിനേഷന് നിയമങ്ങള് പ്രത്യേകം എടുത്തുപറയണമെന്നുള്ളതായിരുന്നു. എന്നാല് അതിനേക്കാള് ഇമ്പ്ലിമെന്റേഷനുകള്ക്ക് വളരെ എളുപ്പമുള്ളതായിരുന്നു ഒരു കോമ്പ്ലിക്കേഷനുമില്ലാത്ത ഒറ്റയൊറ്റ ചില്ലുകള്.
ഈ പറഞ്ഞ മുഖ്യകാരണം കൂടാതെ, ചില ചില്ലുകള് ഏത് അക്ഷരത്തെ ബേസ് ചെയ്താണ് ഉണ്ടാക്കേണ്ടത് എന്ന സംശയവും ഉണ്ടായിരുന്നു. ഉദാ: മലര്/ഞായര്, സല്ക്കര്മ്മം/വാല്മീകി/തല്ഭവം
കൂടുതല് വിവരങ്ങള്ക്ക് എറിക് എഴുതിയ ഈ ഡോക്യുമെന്റ് കാണുക.
അല്ല. ഈ സ്പെഷല് ക്യാരക്റ്റേഴ്സിന്റെ സ്വഭാവത്തില് ഒരു മാറ്റവും യുണിക്കോഡ് വരുത്തുന്നില്ല. ഇന്നലേയും അവ ഇഗ്നോറബിള് ക്യാരക്റ്ററുകളായിരുന്നു. അവയുടെ കൊലേഷന് വെയ്റ്റ് (വാക്കുകളെ അകാരാദിക്രമത്തിലാക്കുന്നതിനു് ഉപയോഗിക്കുന്ന വില) 0 ആയിരുന്നു. സമീപഭാവിയിലും അവയങ്ങനെ ആയിരിക്കും എന്നുറപ്പാണ്.
ഇഗ്നോറബിള് ക്യാരക്റ്ററുകള് വാക്കുകളില് അര്ഥവ്യത്യാസമുണ്ടാക്കുന്നില്ല. അത് ഒരേ കൂട്ടക്ഷരത്തിന്റെ വെവ്വേറേ ആകൃതികള് കാണിക്കാനായി ഉപയോഗിക്കുന്നു. അര്ഥവ്യത്യാസമുണ്ടാക്കാത്ത, എന്നാല് വ്യത്യസ്ത ആകൃതിയുള്ള കൂട്ടക്ഷരങ്ങള്ക്കുദാഹരണമാണ് ‘നു’ എന്നതിന്റെ പഴയലിപിയിലേയും പുതിയലിപിയിലേയും എഴുത്തുരീതി.
ZWJ രണ്ട് അക്ഷരങ്ങള് തമ്മില് കൂടിച്ചേരണം എന്ന് നിര്ബന്ധിക്കുമ്പോള് ZWNJ അവതമ്മില് ഒരിക്കലും ചേരരുത് എന്ന് വിവക്ഷിക്കുന്നു.
കൂട്ടക്ഷരങ്ങളുണ്ടാക്കാനല്ല ZWJ ഉപയോഗിക്കുന്നത്. ഇത് ചില പ്രത്യേക സന്ദര്ഭങ്ങളില് മാത്രമാണ് അക്ഷരങ്ങളെ കൂടിച്ചേരാന് സഹായിക്കുന്നത്. മലയാളത്തില് അവ (വ്യഞ്ജനം + ചന്ദ്രക്കല + zwj) എന്നതും (zwj + ചന്ദ്രക്കല + വ്യഞ്ജനം) എന്നതും മാത്രമാണ്. ആദ്യത്തെ കേസില് അത് ചില്ലക്ഷരമുണ്ടാക്കുന്നു. രണ്ടാമത്തെ പാറ്റേണില് അത് യ, ര, ല തുടങ്ങിയ വ്യഞ്ജനചിഹ്നങ്ങള് ഉണ്ടാക്കുന്നു.
ചില്ലുകളേപോലെ എളുപ്പം തീര്ക്കാവുന്നവയല്ല സദ്വാരം/സദ്വാരം തുടങ്ങീ പെയറുകള് ഇഗ്നോറബിളായ ZWNJ-കൊണ്ടുമാത്രം വ്യത്യാസപ്പെട്ടിരിക്കുന്ന പ്രശ്നം. ഈ പ്രശ്നം ഒരിക്കലും യുണീക്കോഡില് നിന്നും ഒഴിഞ്ഞുപോയെന്നുതന്നെ വരില്ല.
മലയാളം യുണീക്കോഡിന്റെ എല്ലാപ്രശ്നങ്ങളും തീര്ക്കുന്ന ഒറ്റമൂലിയായി ചില്ല് എന്കോഡിംഗിനെ കാണരുത്. ചില്ല് എന്കോഡിംഗ് ZWJ കൊണ്ടുണ്ടായ പ്രശ്നങ്ങള് തീര്ക്കുന്നു. ZWNJ കൊണ്ടുണ്ടാവുന്ന പ്രശ്നങ്ങള് ഇപ്പോഴും ബാക്കി നില്ക്കുന്നു.
zwnj ന്റെ പ്രശ്നം തീര്ത്തിട്ടുമതി ചില്ല് എന്കോഡ് ചെയ്യുന്നത് എന്ന വാദം, റോട്ടിലെ കുണ്ടുംകുഴിയും നികത്താന് വരുമ്പോള് റേയില്വേ ഓവര്ബ്രിഡ്ജ് പണിതിട്ടുമതി എന്ന് പറയുമ്പോലെ പിന്തിരിപ്പനാണ്.
പൊതുവെ ഉള്ള ഒരു തെറ്റിദ്ധാരണയാണ് ഇത് 70-ലെ ലിപിപരിഷ്ക്കരണം പോലുള്ള എന്തോ ഒന്നാണ് യുണീക്കോഡില് സംഭവിക്കുന്നത് എന്ന്. അല്ലേ അല്ല. ഇതില് മലയാളത്തിന്റെ ലിപി ഇന്നതായിരിക്കണം എന്ന് ഇവിടെ തീരുമാനിക്കപ്പെടുന്നേ ഇല്ല.
എഴുത്തിലും പ്രിന്റിലുമായി അനേകം എഴുത്തുരീതികളുണ്ടാകും. അതില് ഒന്ന് പഴയതും മറ്റൊന്ന് പുതിയതാവും, ഒന്ന് നോവലിലും കഥകളിലും സംഭാഷണം രേഖപ്പെടുത്തുന്നതാവും, മറ്റൊന്ന് ശ്ലോകങ്ങളെഴുതാനുള്ളതാവും. ഒന്ന് പണ്ടത്തെ താളിയോലകളിലുള്ളതാവും ഒന്ന് ഇന്ന് ചാറ്റ് ചെയ്യുമ്പോള് പിള്ളേരെഴുതുന്നതാവും. യുണീക്കോഡിന്റെ ഉദ്ദേശം ഇതിലൊന്നാണ് ശരി എന്ന് തീരുമാനിച്ച് അതിനനുസൃതമായി അക്ഷരങ്ങളുടെ എന്കോഡിംഗ് നടത്തുക എന്നതല്ല; മറിച്ച്, മലയാളത്തിന്റെ എല്ലാ ലേഖനസമ്പ്രദായങ്ങളും യുണീക്കോഡില് സാധ്യമാക്കുക എന്നതാണ് - പുതിയതും, പരമ്പരാഗതവും, പ്രാചീനവും. ഈ എഴുതിയിരിക്കുന്നത് നിങ്ങളുടെ ഇഷ്ടപ്രകാരം പുതിയലിപിയിലോ പഴയലിപിയിലോ കാണാനാവുന്നത് അതുകൊണ്ടാണ്.
അതുകൊണ്ട് തന്നെ, ഭാഷാപരമായ കൃത്യതകള്ക്ക് ഇവിടെ വലിയ സ്ഥാനമില്ല. ഭാഷ ഏതുരീതിയിലിരിക്കണം എന്ന പൊളിറ്റിക്സ് യുണീക്കോഡിന് പുറത്ത് സംഭവിക്കേണ്ടതാണ്.
യുണീക്കോഡ് പലരും കരുതും പോലെ കുറേ ഭാഷാസ്നേഹികള് ചേര്ന്ന് രൂപീകരിച്ചിട്ടുള്ള സംരംഭമല്ല. അവിടെ മൈക്രോസോഫ്റ്റും ഗൂഗിളും കൂടി ആളുകളിക്കുകയും അല്ല. മറിച്ച്, സോഫ്റ്റ്വെയര് വെണ്ടര്മാര് അവരുടെ ബിസിനസ് ഇന്ററസ്റ്റ് പുലരുന്നതിനുവേണ്ടി ലോകഭാഷകളെ പരസ്പരം മനസ്സിലാവുന്നരീതിയില് റെപ്രസെന്റ് ചെയ്യുന്നതിനുവേണ്ടി രൂപീകരിച്ചിട്ടുള്ള സംഘമാണ് - ബാക്കി ഏതു സ്റ്റാന്റേഡൈസേഷന് ബോഡിയും പോലെ. അതിലുള്ളവര്ക്ക് ഭാഷാസ്നേഹം കുറവാണെന്ന് ഇപ്പറഞ്ഞതിനര്ഥമില്ല. എന്നാല് ബിസിനസുകള് അവരുടെ ഇഷ്ടം പുലരുന്നതിന് മുതല്മുടക്കുന്ന സംഘമാണിതെന്ന് മറക്കരുത് എന്ന് മാത്രം.
ഗൂഗിളടക്കം പലരും zwj ഇഗ്നോര് ചെയ്യുന്നു എന്നുള്ളതല്ല ചില്ലുകള് എന്കോഡ് ചെയ്യുന്നതിനുള്ള കാരണം. മറിച്ച്, ചില്ലുണ്ടാക്കാന് കൊലേഷന് വെയ്റ്റ് 0 ഉള്ള ഇഗ്നോറബിള് ക്യാരക്റ്റര് (zwj) ഉപയോഗിക്കുന്നു എന്നതാണ്. ചില്ലുണ്ടാക്കാന് zwj ഉപയോഗിക്കുമ്പോള്, ഇഗ്നോറബിള് ക്യാരക്റ്റര് ചേര്ക്കുന്നതും ഒഴിവാക്കുന്നതും അര്ഥവ്യത്യാസം ഉണ്ടാക്കില്ല എന്ന യുണീക്കോഡിലെ ധാരണ ലംഘിക്കപ്പെടുന്നു.
ഇതിനെ പറ്റി കൃത്യമായി ഒരുത്തരം യുണീക്കോഡ് കണ്സോര്ഷ്യം ഇതുവരെ തന്നിട്ടില്ല. എന്നാല് ഏതാണ്ട് താഴെ പറയുന്ന രീതിയിലായിരിക്കണം കാര്യങ്ങള്:
ഫോണ്ടുകള് രണ്ട് രീതികളും സമീപഭാവിയില് സപ്പോര്ട്ട് ചെയ്യണം. അതുകൊണ്ട് ഇപ്പോഴുള്ള ടെക്സ്റ്റുകളെല്ലാം തെറ്റില്ലാതെ തന്നെ കാണാനാവും.
കൊലേഷനും സെര്ച്ചിംഗും ചെയ്യേണ്ടുന്ന ടെക്സ്റ്റുകള് പുതിയ ചില്ല് രീതിയിലേയ്ക്ക് മാറുന്നതാണ് ശരി.
വിക്കിപ്പീഡിയയിലെ ചില്ലക്ഷരങ്ങള് പുതിയ രീതിയിലേയ്ക്ക് ഒരു ബോട്ടുപയോഗിച്ച് മാറ്റേണ്ടിവരും.
അതുപോലെ ഇന്പുട്ട് മെത്തേഡുകളും മറ്റും പുതിയ ചില്ല് എന്കോഡിംഗിനെ ഉപയോഗിക്കണം.
ഗൂഗിളും യാഹൂവും മറ്റും ZWJ-നെ എന്തു ചെയ്യുന്നു എന്നത് ഒന്നിന്റേയും വാദമുഖമല്ല. യുണീക്കോഡ് തന്നെ ഇല്ലാതെ, എല്ലാം ഫോണ്ട് എന്കോഡിംഗ് ആയിരുന്നാല് പോലും, കമ്പനികള് എന്തെങ്കിലും സെന്സിബിള് ആയിട്ടുള്ളത് ചെയ്തേനേ.
ഡാറ്റയെ A എന്ന ഒരു റെപ്രസെന്റേഷനില് നിന്നും B എന്നൊരു റിപ്രസന്റേഷനിലേയ്ക്ക് മാറ്റുമ്പോള് B യുടെ ആവശ്യത്തിനുപകരിക്കാത്തതൊക്കെ B എടുത്തുകളയും എന്നത് സ്വാഭാവികമാണ്. ഒരു 3ഡി ചിത്രത്തിനെ പേപ്പറില് വരയ്ക്കുമ്പോള് അതിലെ ഡെപ്ത് പോയ്പ്പോകുന്ന പോലെ.
ഇപ്പറഞ്ഞതിനുസമാനമായ പ്രോഗ്രാമുകളിലെ ഒരു ഉദാഹരണം നോക്കുക. ഒരു വെബ് പേജില് ഒരു വാക്ക് ബോള്ഡാക്കി കാണിക്കാന് ഉപയോഗിക്കുന്ന ബോള്ഡ് ഫോര്മാറ്റിംഗ് കോഡ് 333 ആണെന്നുവയ്ക്കുക. അങ്ങനെ ബോള്ഡ് ഫോര്മാറ്റിംഗ് കോഡ് ഇട്ട് ബോള്ഡാക്കിയ ഒരു വാക്കിനെ ഒരു നോട്ട് പാഡിലേയ്ക്ക് കോപ്പിചെയ്യുന്നു എന്നും വയ്ക്കുക. നോട്ട് പാഡ് എന്ന പ്രോഗ്രാമില് വാക്കുകളെ ബോള്ഡാക്കിക്കാണിക്കാനുള്ള ഉപാധി ഇല്ലാത്തതിനാല് അത് 333 എന്നുകണ്ടാല് അതിനെയൊക്കെ പെറുക്കിക്കളയും. തിരിച്ച് നോട്ട്പാഡില് നിന്നും ബ്രൌസറിലേയ്ക്ക് കോപ്പിചെയ്താല് ആ വാക്കുകളൊന്നും ബോള്ഡായിരിക്കുകയില്ല. നോട്ട് പാഡിന് ബോള്ഡ് എന്താണെന്നറിയില്ല; ഒരു യൂസര് പ്രതീക്ഷിക്കുന്ന രീതിയും ഇതുതന്നെയാണ്. ഇതില് ഒരു പൊരുത്തക്കേടുമില്ല.
ഇനി മലയാളം യുണീക്കോഡ് സ്റ്റാന്റേഡ് ഇങ്ങനെ ഒരു ക്ലോസ് കൊണ്ടുവരുന്നു എന്ന് വയ്ക്കുക: ഒരു മലയാളം അക്ഷരത്തെ കൂട്ടക്ഷരമാക്കാന് അക്ഷരങ്ങള്ക്കിടയില് 333 ഇട്ടാല് മതി എന്ന്. ഇപ്പോള് എന്തുസംഭവിക്കും? മലയാളം വാചകങ്ങള് നോട്ട്പാഡിലേയ്ക്ക് കോപ്പിചെയ്താല് കൂട്ടക്ഷരങ്ങള് മുഴുവന് തെറ്റായിപ്പോകും. എന്തുകൊണ്ടാണ് മലയാളത്തില് മാത്രം ഇങ്ങനെ സംഭവിച്ചത്? 333 എന്ന കോഡിന്റെ സ്വാഭാവികമായ അര്ത്ഥത്തില് നിന്നും വ്യതിചലിച്ച് പ്രതേകമായൊരു അര്ഥം അതിന് മലയാളത്തിന്റെ കാര്യത്തില് മാത്രം കൊടുത്തതുകൊണ്ടാണ്. അപ്പോള് നോട്ട്പാഡ് എഴുതിയിരിക്കുന്ന പ്രോഗ്രാമില്, കോപ്പിചെയ്തത് മലയാളമാണെങ്കില് മാത്രം, 333 എടുത്തുകളയരുത് എന്ന് പ്രത്യേകം എഴുതിച്ചേര്ക്കേണ്ടിവരും. ഇത് എളുപ്പമോ ബുദ്ധിമുട്ടോ ആവുന്നത് ആ പ്രോഗ്രാം എങ്ങനെ ഡിസൈന് ചെയ്തിരിക്കുന്നു എന്നതിനെ ആശ്രയിച്ചിരിക്കും. ലോകത്തിലെ പല ലിപികളുടേയും കമ്പ്യൂട്ടറിലെ ഉപയോഗം വച്ചു നോക്കുമ്പോള് മലയാളം സപ്പോര്ട്ടിനുള്ള പ്രയോരിറ്റി ഇന്നും വളരെ കുറവാണ്. അതുകൊണ്ട് അധികം റിസോര്സസില്ലാത്ത ഡെവലപ്പര്മാരും കമ്പനികളും വിചാരിക്കും ‘ഓ.. ഈ മലയാളം ഭാഷയിലൊക്കെ ആരെഴുതാനാ? അതില്ലാത്ത സപ്പോര്ട്ട് ഒക്കെ മതി’. ഒരു ഉദാഹരണം ഇതാ. തീര്ച്ചയായും ആ അപ്ലിക്കേഷന് കുറെ യൂസര്മാരെ നഷ്ടപ്പെടും. എന്നാല് എന്നെ സംബന്ധിച്ചിടത്തോളം പ്രശ്നം, പല പ്രോഗ്രാമുകളിലും മലയാളം സപ്പോര്ട്ട് ശരിയല്ലാതാവുന്നതാണ്. മലയാളത്തിനുവേണ്ടി പ്രത്യേകം കോഡെഴുതാതെ തന്നെ യുണീക്കോഡില് എഴുതിയ മലയാളം കാണിക്കുകയോ വിനിമയം ചെയ്യുകയോ വേണം എന്നതാണ് എന്റെ ആഗ്രഹം.
മുകളില് പറഞ്ഞ ഉദാഹരണത്തിന്ന് വളരെ സമാനമാണ് ഇന്നത്തെ ചില്ലുകളുടെ സ്ഥിതി. അറ്റോമിക് ചില്ലുവരുമ്പോള് ഇങ്ങനെ ഒരു ഫോര്മാറ്റിം കോഡ് ഉപയോഗിച്ച് ചില്ലുകളെ അവതരിപ്പിക്കേണ്ട അവസ്ഥയില്ല; മലയാളത്തിന് വേണ്ടി പ്രത്യേകം അപ്ലിക്കേഷനുകള് മാറ്റേണ്ടതില്ല. അതുകൊണ്ടാണ് അറ്റോമിക് ചില്ലുകള് മലയാളത്തിന് ഗുണകരമാവുന്നത്.
ചില്ലുകളെ പറ്റിയുള്ള ചര്ച്ച യുണിക്കോഡിന്റെ ചരിത്രത്തിലെ ഏറ്റവും നീണ്ട ഒന്നായിരുന്നു എന്നു പറയാം - ഏതാണ്ട് 3 വര്ഷങ്ങള്. രചന അക്ഷരവേദിയിലെ പ്രവര്ത്തകര്, സിഡാക്ക് ഭാഷാ കമ്പ്യൂട്ടിംഗ് വിഭാഗത്തിലെ പ്രതിനിധികള്, കെ.പി. മോഹനനെ പോലുള്ള ഭാഷാവിദഗ്ദര്, വരമൊഴിയിലേയും സ്വതന്ത്രമലയാളംകമ്പ്യൂട്ടിംഗിലേയും സോഫ്റ്റ്വെയര് എഞ്ചിനിയര്മാരും അവര്ക്കു പുറമേ ധാരാളം മലയാളഭാഷാസ്നേഹികളും ഈ ചൂടുപിടിച്ച ചര്ച്ചകളില് ഇക്കാലമത്രയും സജീവം പങ്കെടുത്തു. രണ്ടുഭാഗങ്ങളുടേയും ഗുണങ്ങളും ദോഷങ്ങളും ശേഖരിച്ചു. 20-ല് അധികം ടെക്നിക്കല് പ്രപ്പോസലുകളും വിദഗ്ദ്ധാഭിപ്രായങ്ങളും സമര്പ്പിക്കപ്പെട്ടു. ഇവയെല്ലാം പഠിച്ച് യുണീക്കോഡിന്റെ ടെക്നിക്കല് കമ്മിറ്റി ചില്ല് എന്കോഡ് ചെയ്യാന് തീരുമാനിക്കുകയാണ് ഉണ്ടായത്. ഈ കാലയളവില് കേരള മുഖ്യമന്ത്രി ആയിരുന്ന ശ്രീ. അച്ചുതാനന്ദന് രണ്ടുതവണ ഗവണ്മെന്റിന്റെ അഭിപ്രായം കണ്സോര്ഷ്യത്തെ അറിയിക്കുകയുണ്ടായി - ആദ്യം ഇതിനെ പറ്റി കേരളാഗവണ്മെന്റിന് ഒരു തീരുമാനത്തിലെത്താനുള്ള സമയം ചോദിച്ചും; പിന്നീട് ചില്ല് എന്കോഡ് ചെയ്യാനുള്ള തീരുമാനവുമായി മുന്നോട്ട് പോയ്ക്കോള്ളാന് അനുവദിച്ചും.
'nta' encoding is explicitly defined in Unicode 5.1 as:
chillu-na + virama + rra
Since the Unicode standard was not clear, applications written pre-5.1 followed varying conventions:
Microsoft's Karthika font: na + virama + zwj + rra
Varamozhi, Rachana, SMC etc.: na + virama + rra
In windows XP and Vista, chillu-na + virama + rra would produce an error from the rendering engine Uniscribe and user would see a dotted circle, instead of the conjunct. This prevents rest of the applications from adopting the Unicode 5.1 scheme in Windows.
ലോകത്തിലെ മിക്ക ഭാഷകള്ക്കുമായി യൂണികോഡ് അവരുടെ സ്റ്റാന്ഡേര്ഡില് സ്ഥാനങ്ങള് നിശ്ചയിച്ചിട്ടുണ്ടു്. ഒട്ടുമിക്ക ഭാഷകളും ഈ സ്ഥാനങ്ങള് ഉപയോഗപ്പെടുത്തി ഇവയുടെ വിലകളെ സൂചിപ്പിക്കുവാനുള്ള ഫോണ്ടുകളും നിര്മ്മിച്ചിട്ടുണ്ടു്. പ്രധാന സോഫ്റ്റ്വെയര് കമ്പനികളെല്ലാം തന്നെ യൂണികോഡിലാണു അവരുടെ പ്രൊഡക്റ്റുകളുടെ പ്രാദേശിക വേര്ഷനുകള് നിര്മ്മിക്കുന്നതു്. ഇന്ത്യന് ഭാഷകളില് ഹിന്ദി, മലയാളം, തമിഴ്, കന്നട എന്നിവയ്ക്കുള്ള വിന്ഡോസ് എക്സ്.പി വേര്ഷനുകള് യൂണികോഡ് സ്റ്റാന്ഡേര്ഡ് അനുവര്ത്തിക്കുന്നവയാണു്. അവയില് ഫയല് നാമങ്ങളും മറ്റും യൂണികോഡ് സ്റ്റാന്ഡേര്ഡ് ഉപയോഗിച്ചാണു് എഴുതപ്പെടുന്നതും. കണക്കുപുസ്തകം.xls എന്ന എക്സല് ഫയല് യാഥാര്ഥ്യമാണെന്നര്ഥം. ഫയല് നാമങ്ങള്ക്കു ഫോണ്ട് ഫോര്മാറ്റുകള് ഉപയോഗിക്കുവാന് സാധിക്കുകയില്ല, പക്ഷെ യൂണികോഡില് ഫോണ്ട് ഫോര്മാറ്റുകള് ആവശ്യമില്ലല്ലോ. ആസ്കിയില് കഴിയാതിരുന്നതു യൂണികോഡില് കഴിയുന്നു.
അച്ചടിയുടേയും ടൈപ്റൈറ്ററുകളുടേയും ആഗമനത്തോടെ നഷ്ടപ്പെട്ടുപോയ പല ലിപിരൂപങ്ങളും പുനര്സൃഷ്ടിക്കുവാനുള്ള യൂണികോഡിന്റെ കഴിവില്, ഭാഷയെ തന്നെ പുനരുജ്ജീവിപ്പിക്കുന്ന തരത്തിലുള്ള സംസ്കരണം ഐ.ടി. യില് സാധ്യമാകുന്നു. ഭാഷാപ്രേമികള്ക്കു എന്തുകൊണ്ടും ഇതു ആശ്വാസകരമായ വസ്തുതയാണു്.
പത്രങ്ങളും വെബ് മാഗസിനുകളും ആസ്കി ഫോണ്ടുകള് ഉപയോഗിക്കുക എന്ന പാരമ്പര്യം തുടര്ന്ന് പോന്നവരാണു്. ഈ ഫോണ്ടുകളില് ഡോക്യുമെന്റുകള് തയ്യാറാക്കുന്നതിനായി പ്രത്യേക സോഫ്റ്റ്വെയറുകളും കീബോര്ഡുകളും വാങ്ങുന്നതിനു് അവര് കാശുമുടക്കിയിട്ടുമുണ്ടു്. പെട്ടെന്നുള്ള ഒരു മാറ്റം അവര്ക്ക് സാമ്പത്തികമായും പ്രായോഗികമായും ബുദ്ധിമുട്ടുകള് വരുത്തിവച്ചേയ്ക്കും.
ഓരോ പ്രസാധകരും ബ്രാന്ഡ് ഉണ്ടാക്കിയെടുക്കാനായി, വളരെ ശ്രദ്ധിച്ചാണ് ഫോണ്ട് തിരഞ്ഞെടുക്കാറ്. മനോരമയും മാതൃഭൂമിയുമൊക്കെ വളരെ പഠനങ്ങള്ക്ക് ശേഷമാണ് അവരുടെ ഫോണ്ടുകള് തെരഞ്ഞെടുത്തിരിക്കുന്നത്. അച്ചടി മേഖലയിലുള്ള സ്ഥാപനങ്ങള് ഉപയോഗിക്കുന്ന ഫോണ്ട്, അവരുടെ ബ്രാന്ഡിംഗിന്റെ തന്നെ ഭാഗമാണ്. പ്രസാധകര്ക്കെല്ലാം അവരവരുടെ ഫോണ്ടുകള് തെരഞ്ഞെടുക്കാന് തക്കവണ്ണം, നിരവധി ഫോണ്ടുകള് ആസ്കി വിഭാഗത്തിലുണ്ട്. യൂണികോഡിലാവട്ടെ, ഫോണ്ടുകളുടെ എണ്ണം വിരലില് എണ്ണാവുന്നതാണ്. തിരഞ്ഞെടുക്കാന് അനവധിയുണ്ട് എന്നതിനാലാവണം പ്രസാധകര് ഇപ്പോഴും ആസ്കി ഫോണ്ടുകളില് കടിച്ചുതൂങ്ങുന്നതിന് മറ്റൊരു കാരണം.
പത്രങ്ങളും മറ്റും യൂണികോഡ് ഉപയോഗിക്കുകയാണെങ്കില് ഉപഭോക്താക്കള്ക്കും അച്ചടി മാധ്യമങ്ങള്ക്കും ഒരുപാടു ഗുണങ്ങളുണ്ടു്. ഭാഷയിലെ അക്ഷരതെറ്റുകള്, വ്യാകരണപ്പിശകുകള് എന്നിവ കണ്ടുപിടിക്കുന്നതിനു്, അക്ഷരമാലാ ക്രമത്തില് പദങ്ങള് ക്രമീകരിക്കുന്നതിനു്, ഫയലുകളിലെ ഉള്ളടക്കങ്ങള് തിരയുന്നതിനു് എല്ലാം യൂണികോഡ് സഹായകമാകും. ഇതിനെല്ലാം പുറമെ, നെറ്റിലെ വായനക്കാര്ക്ക് ഓരോ പത്രത്തിനനുസരിച്ചും പുതിയ ഫോണ്ടുകള് ഡൌണ്ലോഡ് ചെയ്യേണ്ടി വരില്ല.
ഒട്ടുമിക്ക പുതിയ ഓപ്പറേറ്റിംഗ് സിസ്റ്റങ്ങളിലും (പ്രവര്ത്തന വ്യവസ്ഥകളിലും) യൂണികോഡ് ഫോണ്ടുകള് ഉണ്ടു്. ഒപ്പം തന്നെ വെബില് പത്രമാധ്യമങ്ങളുടെ ഉള്ളടക്കം, സേര്ച്ച് എഞ്ചിനുകള് ശേഖരിക്കുകയും എളുപ്പം തിരയുന്നതിനായി ക്രമീകരിക്കുകയും ചെയ്യുന്നതോടെ ഭാഷയിലുള്ള വിജ്ഞാനം, എവിടെ നിന്നും എളുപ്പം തിരഞ്ഞെടുക്കാവുന്ന രീതിയിലുമാകും. ഭാഷയുടെ വളര്ച്ചയ്ക്ക് ആ ഭാഷയില് ലഭ്യമായിട്ടുള്ള അറിവുകളുടെ സ്രോതസ്സുകള് എന്തുമാത്രം ഉപയോഗപ്രദമാണെന്നുള്ളതു പ്രത്യേകം പറയേണ്ടതില്ലല്ലോ. സ്വന്തമായി വിജ്ഞാനം ഉല്പ്പാദിപ്പിക്കാത്ത ഭാഷകള് നശിച്ചുപോയിട്ടേയുള്ളൂ.
ഭാഷാപത്രങ്ങളും, മറ്റു മാധ്യമങ്ങളും യൂണികോഡിലേയ്ക്കു നീങ്ങേണ്ടതു്, ഭാഷയുടെ പ്രാധാന്യം തിരിച്ചറിഞ്ഞു രൂപമെടുത്തിട്ടുള്ള മാധ്യമങ്ങള് എന്ന നിലയ്ക്കു അവരുടെ ധാര്മ്മികപരമായ കടമയുമാണു്. ഈ ധാര്മികത പുലര്ത്തുന്നതില് എത്ര പേര്ക്ക് താല്പര്യമുണ്ട് എന്ന കണക്ക് എന്റെ അറിവുകളുടെ പരിധിക്കു പുറത്താണു്.
ലോകത്തിലെ മിക്ക ഗവണ്മെന്റുകളും e-governance നടപ്പാക്കുന്നതു് യൂണികോഡില് അധിഷ്ഠിതമായ ഭാഷാഉപകരണങ്ങള് ഉപയോഗിച്ചാണു്. കേരളത്തിലെ സ്ഥിതിയും മറിച്ചാവില്ലെന്നു കരുതുവാനാണു്, എനിക്കിഷ്ടം. സര്ക്കാര് ഓഫീസുകളിലും മറ്റും ഉപയോഗിക്കുന്ന പ്രോഗ്രാമുകളും ഡാറ്റയും യൂണികോഡിലാവണം എന്നതാണു പ്രധാനകാര്യം. അത്തരം ഏജന്സികളില് എന്തു നടക്കുന്നു എന്നറിയുവാനുള്ള സൌകര്യം എനിക്കു ലഭിച്ചിട്ടില്ല, എങ്കിലും സര്ക്കാര് സൈറ്റുകളിലും മറ്റും ഇപ്പോഴും ആസ്കി ഫോര്മാറ്റിലാണ് മലയാളം ഭാഷ കൈകാര്യം ചെയ്തുപോരുന്നതു്. യൂണികോഡിന്റെ ടെക്നിക്കല് ഗുണങ്ങള് തിരിച്ചറിഞ്ഞു, പ്രധാന സോഫ്റ്റ്വെയര് ദാതാക്കളെല്ലാം യൂണികോഡിലേയ്ക്കു മാറുകയും ചെയ്ത സ്ഥിതിക്കു സര്ക്കാര് സ്ഥാപനങ്ങള് ഇപ്പോഴും ആസ്കിയില് തുടരുന്നതു ഗുരുതരമായ കൃത്യവിലോപമാണു്. മലയാളം ഭാഷയിലുള്ള ഔദ്യോഗിക ഇലക്ട്രോണിക് സന്ദേശങ്ങളും (അഥവാ അങ്ങിനെ ഒന്നുണ്ടെങ്കില്) പൊതുജനത്തിനു ലഭ്യമാക്കുന്ന ഇലക്ട്രോണിക് ഡാറ്റയും യൂണികോഡിലാവേണ്ടതു്, വളരെ ഗൌരവ സ്വഭാവമുള്ള ഒരു ആവശ്യമാണു്. കാരണം information ലഭ്യമാക്കേണ്ടതു്, എളുപ്പം ഉപയോഗിക്കാവുന്ന തരത്തിലായിരിക്കണം, അല്ലെങ്കില് വിവരസാങ്കേതികവിദ്യ എന്ന പദം തന്നെ സൃഷ്ടിച്ചെടുക്കേണ്ടായിരുന്നല്ലോ. കേരള സര്ക്കാറിന്റെ മലയാളം വെബ്സൈറ്റ് പ്രശസ്തമായ സേര്ച്ച് എഞ്ചിനുകളില് സേര്ച്ചബിള് അല്ലാതിരിക്കുന്ന ഇപ്പോഴത്തെ അവസ്ഥ ദോഷം ചെയ്യുകയേയുള്ളൂ.
ഗവണ്മെന്റ് സ്ഥാപനങ്ങള് യൂണികോഡിലേയ്ക്കു മാറുന്നതോടെ നമ്മുടെ പ്രശ്നങ്ങള് അവസാനിക്കുന്നില്ല. മലയാളം ഭാഷ ഏവര്ക്കും ഉപയോഗിക്കാനാവുന്ന സവിശേഷ അവസ്ഥ കൈവരുമ്പോള് അപ്ലിക്കേഷനുകളും മറ്റും പ്രാദേശികവല്ക്കരിക്കപ്പെടുകയും ചെയ്യും. അപ്ലിക്കേഷനുകളുടെ മെനു, ഉപഭോക്താവുമായി സംവദിക്കുന്ന മെസേജുകള് എന്നിവ മലയാളത്തിലാക്കപ്പെടും എന്നര്ഥം. ഓരോ സോഫ്റ്റ്വെയര് വെന്ഡറും അവരുടേതായ രീതികളിലാണു് ഇംഗ്ലീഷിലുള്ള ടെക്നിക്കല് വാക്കുകളെ മലയാളത്തില് തര്ജ്ജമ ചെയ്യുന്നതു്. പൊതുവാ ഒരു ടെക്നിക്കല് ഗ്ലോസറി ഇല്ലാത്തിടത്തോളം കാലം മലയാളത്തില് സോഫ്റ്റ്വെയറുകളും ഐ.ടി. സേവനങ്ങളും ലഭ്യമാക്കുന്നവര് അവര്ക്കു ബോധിക്കുന്ന രീതിയില് വാക്കുകള് തര്ജ്ജമ ചെയ്യും. സര്ക്കാരിന് സോഫ്റ്റ്വെയര് നല്കുന്ന രണ്ടു വ്യത്യസ്ഥ സ്ഥാപനങ്ങള് File എന്ന computer term -നെ 'പുസ്തകം' എന്നും 'ഫയല്' എന്നും തര്ജ്ജമ ചെയ്താല് സംഭവിച്ചേയ്ക്കാവുന്ന ദോഷങ്ങളെ കുറിച്ചോര്ത്തു നോക്കുക. ഇവ രണ്ടും ഒരുമിച്ചു ഉപയോഗിക്കേണ്ടി വരുന്ന ഒരാള്ക്കു അതുമൂലം ഉണ്ടായേക്കാവുന്ന ആശയക്കുഴപ്പത്തെ പറ്റിയും സമയനഷ്ടത്തെ പറ്റിയും നമ്മളും സര്ക്കാരും ചിന്തിക്കേണ്ടതുണ്ട്. യൂണികോഡ് ഉപയോഗത്തിനൊപ്പം തന്നെ സര്ക്കാര് തലത്തില് നിര്ണ്ണയിക്കപ്പെടേണ്ട ചില കാര്യങ്ങളില് സുപ്രധാനമായ ഒന്നാണു് മലയാളത്തിനു ഏകതാനമായ ഒരു സാങ്കേതിക പദാവലി (technical glossary). സോഫ്റ്റ്വെയര് ദാതാക്കള് ഇത്തരം ഐക്യരൂപങ്ങളെ സ്വീകരിക്കുവാനാണു് എല്ലായ്പ്പോഴും താല്പര്യപ്പെടുന്നതും.
ഗവണ്മെന്റ് യൂണികോഡ് ഉപയോഗിക്കുവാന് തുടങ്ങിയാല് മറ്റു സ്ഥാപനങ്ങളും മാധ്യമങ്ങളും യൂണികോഡ് സ്വീകരിക്കുവാന് മുന്നോട്ടു വരുമെന്നു നമുക്കു പ്രത്യാശിക്കാം. വിക്കിപീഡിയ, എം.എസ്.എന് മലയാളം, മലയാളം ബ്ലോഗുകള് എന്നിങ്ങനെ വെബ്ബില് സുപ്രധാന സ്ഥാനം നേടിയിട്ടുള്ള പല മാധ്യമങ്ങളും ഇതിനകം തന്നെ യൂണികോഡ് ഉപയോഗിച്ചു തുടങ്ങി എന്നുള്ളതു കുറച്ചെങ്കിലും ആശ്വാസ്യകരമായ വാര്ത്തയാണു്. ഏറ്റവും വലിയ സേര്ച്ച് എഞ്ചിനായ ഗൂഗിളും ഇപ്പോള് മലയാളം യൂണിക്കോഡിനെ പിന്തുണയ്ക്കുന്നുണ്ട്.
യുണീകോഡിലുപരി മൊത്തം ഡിജിറ്റൽ ലോകത്തുള്ള മലയാളത്തിൻ്റെ പ്രാതിനിധ്യം ഉറപ്പാക്കാനായി പലതും ചെയ്യാനാവും:
കേരളത്തിലെ തന്നെ, കമ്പ്യൂട്ടിംഗ് ഗവേഷകരേയും ഭാഷാ ഗവേഷകരേയും ഒരു interdisciplinary പ്രോഗ്രാമിലൂടെ ഒരു പ്ലാറ്റ്ഫോമിൽ എത്തിക്കണം.
അതുപോലെ മറ്റു ഇന്ത്യൻ NLP ഗവേഷകരും ആയി ഇവർ ഒരുമിച്ച് പ്രവർത്തിക്കണം.
ഗവണ്മെൻ്റ് പണം മുടക്കി ചെയ്യുന്ന ഭാഷാഗവേഷണങ്ങൾ സംരംഭങ്ങൾ, ഏവർക്കും സ്വതന്ത്രമായി ഉപയോഗിക്കാവുന്ന ലൈസൻസിൽ എപ്പോഴും ലഭ്യമാവുന്ന രീതിയിലും വിതരണം ചെയ്യണം. ഉദാ: github ലൂടെ.
ഇന്ന് ഏറ്റവും കൂടുതൽ NLP അപ്ലിക്കേഷനുകൾ ചെയ്യുന്നത് പ്രൈവറ്റ് കമ്പനികളാണ്. അവരോടും സംവദിക്കണം.
അതിനായി പ്രമുഖ കോൺഫറൻസുകളിൽ പങ്കെടുക്കുകയും നമ്മുടെ ടെക്നോളജികൾ പരസ്യം ചെയ്യുകയും മറ്റുള്ളവർക്ക് മലയാളം സപ്പോർട്ട് ചെയ്യാൻ ആവശ്യമുള്ള കാര്യങ്ങൾ എന്തൊക്കെ എന്ന് ആരാഞ്ഞുകൊണ്ടിരിക്കുകയും വേണം.
എഴുത്ത് എന്ന മേഖലമാത്രമല്ല, ശബ്ദം - ASR, TTS എന്നിവയും ഇന്ന് വളരെ പ്രധാനമാണ്. അതിലും നമ്മൾ ശ്രദ്ധിക്കാനുണ്ട്.
പല കമ്പനികൾക്കും മലയാളത്തെ പറ്റിയുള്ള അടിസ്ഥാന വിവരങ്ങൾ ആണ് ലഭ്യമല്ലാത്തത്. അതുകൊണ്ട് സ്വന്തമായി അപ്ലിക്കേഷനുകൾ ഉണ്ടാക്കുക എന്നതിനേക്കാൾ അത്തരം ഡാറ്റാസെറ്റ് ഉണ്ടാക്കുന്നതിൽ ആയിരിക്കണം ശ്രദ്ധ. ഉദാഹരണങ്ങൾ: പുരാതന പുസ്തകങ്ങളുടെ സ്കാനുകൾ, എഴുത്തും അത് വായിച്ചത് ഓഡിയോ ഫയലുകളായി, മലയാളത്തിൽ പ്രചാരത്തിലുള്ള വാക്കുകളുടെ ശേഖരം, മലയാളത്തിൻ്റെ സ്വനവിജ്ഞാനശേഖരം.
കൂടെ മറ്റു ഗവണ്മെൻ്റുകളുടെ പോളിസികൾ ഇക്കാര്യത്തിൽ എങ്ങനെ എന്ന് സസൂക്ഷ്മം വീക്ഷിക്കണം. ഉദാഹരണത്തിന് Iceland ഈ NLP രംഗത്ത് കാര്യമായി മുന്നേറിയിട്ടുള്ള ഒരു രാജ്യമാണ്.
മലയാളം വിക്കിപീഡിയ പോലുള്ള കമ്യൂണിറ്റി സംരംഭകര് യൂണികോഡില് മാത്രമേ contributions സ്വീകരിക്കുകയുള്ളൂ. വിക്കിപീഡിയ കമ്യൂണിറ്റിയിലെ വ്യക്തികള് സ്വന്തം നിലയ്ക്കും കമ്യൂണിറ്റിയില് ഉള്പ്പെട്ടുകൊണ്ടും യൂണികോഡിനെ കുറിച്ചുള്ള ബോധവല്ക്കരണം നടത്തുന്നുണ്ടു്. അതുപോലെ തന്നെ മലയാളം ബ്ലോഗെഴുത്തുകാരുടെ കൂട്ടായ്മകളിലും കമ്യൂണിറ്റികളും യൂണികോഡ് ബോധവല്ക്കരണ പ്രവര്ത്തനങ്ങളും വളരെ നല്ല രീതിയില് നടന്നുപോകുന്നുണ്ടു്. യൂണികോഡ് സ്റ്റാന്ഡേര്ഡ് നിര്വചിക്കുന്ന യൂണികോഡ് കണ്സോര്ഷ്യം എന്ന സ്ഥാപനം നടത്തുന്ന ചര്ച്ചകളിലും മറ്റും പല മലയാളികളും ഗവണ്മെന്റ് തലത്തില് നിന്നുള്ള ചില വ്യക്തികളും പങ്കെടുത്തു കാണാറുണ്ടു്.
പൊതുജനങ്ങളിലേയ്ക്കു യൂണികോഡിനെയും അതിന്റെ ഗുണങ്ങളേയും എത്തിക്കുവാന് ഏറ്റവും നല്ല മാര്ഗം യൂണികോഡ് ഉപയോഗിക്കുകഎന്നതാണു്. വിക്കിപീഡിയ, മലയാളം ബ്ലോഗുകള്, സ്വകാര്യ ഇ-മെയില് സന്ദേശങ്ങള് എന്നിവയില് വ്യക്തികള് തന്നെ യൂണികോഡ് ഉപയോഗിക്കുവാന് തുടങ്ങിയാല് പതിയെ മാധ്യമങ്ങള്ക്കും ഗവണ്മെന്റിനും തന്നെ ഈ നവസാങ്കേതികത്വത്തെ അവഗണിക്കുവാന് കഴിയാതെ വരും. മാധ്യമങ്ങളെയും ഗവണ്മെന്റിനെ തന്നെയും ഇക്കാര്യത്തില് ബോധവല്ക്കരിക്കുവാന് കൂട്ടായ ശ്രമങ്ങളും കാമ്പയിനുകളും സഹായകരമായേക്കും. ഈയടുത്ത കാലത്തു വിക്കിപീഡിയ കമ്യൂണിറ്റി നടത്തുവാന് ഉദ്ദേശിച്ചിരുന്ന വിക്കിമീഡിയ പങ്കാളിത്ത യജ്ഞം ഒരു പക്ഷെ നടന്നിരുന്നുവെങ്കില് കേരളത്തിലെ വിദ്യാര്ത്ഥി സമൂഹത്തിലും കലാലയങ്ങളിലും യൂണികോഡിനെ കുറിച്ചു ബോധവാന്മാരായ ഒരു സമൂഹം രൂപപ്പെടുന്നതു കാണുവാനായേനെ. ഇപ്പോള് യൂണികോഡ് ഉപയോഗിക്കുന്ന നെറ്റ് യൂസേഴ്സിന്റെ കമ്യൂണിറ്റികള്ക്കു പൊതുപരിപാടികള് ആസൂത്രണം ചെയ്യുവാനും നടപ്പാക്കുവാനും കഴിഞ്ഞാല് യൂണികോഡിനും മലയാളത്തിനും കേരളത്തിലെ കമ്പ്യൂട്ടര് ഉപയോക്താക്കള്ക്കിടയില് സ്വാധീനം നേടിക്കൊടുക്കുവാനാകും. ഭാഷയെ അതിന്റേതായ സര്വ്വഗുണങ്ങളോടും കൂടി ഉപയോഗിക്കുവാല് സജ്ജമാക്കുന്നതിലൂടെ മലയാളം മരിക്കുന്നില്ലെന്നു് ഓരോ ഭാഷാപ്രേമിക്കും ഉറപ്പുവരുത്താം.
Join Indic discussion list in unicode
നിഷാദ് കൈപ്പള്ളിയുടെ ബോധവത്കരണവിക്കി