indic-computing-devel — Discussing the development of tools for Indian language information processing

[Indic-computing-devel] Conflicting Encoding schemes

[<ar...@bg...>]

Conflicting Encoding schemes

Indian language usage on computers are primarily focused on document management, which includes office correspondance, DTP and Web pages. In that context even sophisticated technologies providing solutions for localization at OS level or for Database management often fails. Keeping in view the developer community often provide a solution by hacking the available font technology. Every language software available today is based on the age old glyph encoding techniques.

Inspite of the need and passion NO technology has been developed in India to cater to the needs of the Indian Languages. It is the failure of various Govt and Govt bodies to develop any technology. It is strange that our system of bureaucracy even bend upon to support outdated techniques in the name language technology which does not serve the cause for the language.

When the Govts failed to recognize the need for technology development for Indian Languages, the passionated developers continue to develop solutions based on Font techniques. Due to lack of vision some of the state governments are satisfied and have announced certain glyph encoding schemes.

In this context Government of Tamilnadu have announced two glyph encoding schemes as standards during 1999(TAM stands for Tamil Monolingual and TAB stands for Tamil Bi-lingual). Along side TSCII (yet to be recognized encoding scheme by Govt of Tamilnadu) is being used widely in the web.

Govt of Karnataka have also announced a monolingual glyph encoding standards during end of 2000. No other encoding such as character encoding or glyph encoding for bi-lingual requirement have been announced as standard by the Govt of Karnataka.

Now, Govt of India is actively involved in evolving a National glyph encoding standard for all Indian Languages.

For the effective Language content processing, Language identification is a crucial requirement. Some of the standards recognized such needs and prefixed with appropriate Language IDs. For example, TAM and TAB for Tamil fonts. Similarly, Govt of India is also following some schemes. However, the monolingual standard announced by Govt of Karanataka doesn't prefix font names with any IDs for the glyph standards. This also throws open the Pandora box.

Strangely, KGP has evolved an alternate encoding scheme called KSCLP, which is not part of Govt of Karnataka standard. As the Govt of Karnataka insists on using the glyph encoding schemes and due to lack technological support for KSCLAP there is no user to use KSCLAP for web requirement.

While supporting ISCII, the support need to be extended to PC-ISCII, which is also part of ISCII.

While developing Indic support in Mozilla, every glyph encoding can to be supported by providing internal conversion as pointed out for ISCII. It means that Mozilla would always process the Unicode data. This would strengthen the technology being developed for Indian Languages in terms of lnguistic components.

N. ANBARASAN
APPLESOFT
BANGALORE - 10

[Indic-computing-devel] Mozilla Localization

[Venky H. <ve...@vs...>]

Dear Indic Computing Group,

We are looking for people to help us localize Mozilla to Indian languages.
Rediff has agreed to hire people for this and their objective is to
encourage the
penetration of the Internet in India. The programmers will work closely with
the IndLinux.org team to localize Mozilla and the software thus developed
will
be released in the public domain. This would be a good opportunity for those
passionate about Indian language computing to work full-time in this area.
The individuals selected will work out of Rediff's Mumbai office.

More details are below. Those interested are requested to write to us at:
ve...@in... and kar...@in...

Regards,

Venky


Mozilla Indianization
==============

1) Goal: Enable Mozilla browser to display & handle indian languages
properly, with proper font technology available. Localize Mozilla interface
also to indian languages.

2) Project Requirements: All work done should be contributed back to Mozilla
codebase, so that it becomes part of it. Solutions arrived at should make
into main tree, rather than be done as adhoc hacks / addons / patches.

 i) i18n part (involving changing mozilla codebase) :
 a - Should be able to render Indian languages encoded in Unicode/UTF-8
b - Use a standardized font technology - eg OpenType.
 c - Support any encodings standardized for a language eg ISCII, TSCII,
KSCLP (KGP)

 ii) l10n part (no code change - UI customization, translations of UI and
Help text):
 a - Incorporate locale support (chrome level)
 b - Translate Mozilla UI into indian languages
 c - Making indianized mozilla theme - custom graphics, logos

3) Skill sets req
 a - Knowlegde of at least two Indian languages - reading & writing, script
& language processing level  2.i & 2.ii.b
 b - C, C++, XML, Java for 2.i
 c - Graphics expertise for 2.ii.c
 d - For translator - good vocabulary in English & at least one Indian
language, previous exp in translation also helpful.
 e - Proj. mgmt skills, ability to work with volunteers remotely, coordinate
work through email/IM/group meetings.
 f - Interest in localization and passion for having indian languages on
mozilla.
 g - Work experience of 2-3 years in the IT industry

Current status:
 Mozilla supports Unicode, so all indian languages represented in Unicode
work at unicode level - no proper rendering, if  a suitable unicode font is
available. ie proper vowel sign positioning, conjuncts etc are not
avialable. Some work is on by Prabhat Hegde from Sun Microsystems on adding
devanagari support, basically by using Pango (www.pango.org) rendering
engine. He is exploring doing it using Opentype fonts. (Any one working for
this should work with Prabhat for
guidance & review, as he already has experience in Mozilla codebase )

Some hindi translation work has been done by a group based in Mumbai,
available at http://www.bttlindia.com/mozilla/ . Some translation work for
Tamil is also on. (These translations should be reused, instead of starting
from scratch)

Notes:

2.i has to be done in active participation with Mozilla developers & done at
those forums ( mozilla-i18n , mozilla-l10n  )
2.ii.b is pure translation work, can be done in centralized or distributed
fashion.
 2.i.c - Since ISCII, TSCII etc are not registered character sets, it may
not be possible to use them with Mozilla autodetection feature. Some
workaround could be suggested. ISCII text will basically be converted to
Unicode internally for display, enabled through use of 'iso8829-12'
 reserved for Indic - ISO is waiting for us to settle to something :). (The
rationale to support ISCII is since ISCII chars will take 1byte, UTF-8 indic
characters take 3bytes, or  7 bytes when used as named
character references - The debate will pick up heat when indian languages
are fully supported )

-0-

Download Milan -- the Hindi interface to GNU/Linux from www.indlinux.org.

[Indic-computing-devel] Action points First National Indic-Font Workshop, March, 2003

[Vijay P. S. A. <vi...@ek...>]

  Hi All,

First National Indic-Font workshop, organized by Indic-Computing 
Consortium was held from 28th to 30th March 2003 at PES Institute of 
Technology, Bangalore. The workshop went on well although with some 
initial hiccups. The workshop was to accommodate 30 participants, but 
last minutes entries took the no.s to 36, in the interest of 
participation they were included as participants. There were some 
initial problems as one of the expected sponsorship did not come by, but 
finally we were able to go ahead with the workshop without any major 
problem.

We are thankful to all the sponsors especially PES Institute of 
Technologies, Bangalore provided excellent space for smooth conduct of 
workshop and computers for Lab for font development, Sarai, New Delhi to 
help us move ahead by accommodating our last minutes requests and 
DeepRoot Linux for all the ground work put by there team. Dr. Pavanaja 
who shared his time even though having a small accident just few days 
before workshop and Karunakar, Arun & Nagarjuna for providing their time 
and support. A special thank is due to participants from Nepal & 
Bangladesh Mr. Amar Gurung & Mr. Mustafa Jabbar for sharing their 
experiences and promise of continued support to Indic-Computing 
Consortium in future also.

The three days of deliberations and action points are as under.

best

vijay

-- 

Vijay Pratap Singh Aditya
ekgaon technologies
email: vi...@ek...
website: http://www.ekgaon.com

Action points First National Indic-Font Workshop March 2003
-----------------------------------------------------------

Vijay Pratap Singh Aditya <vi...@ek...>


First National Indic-Font workshop, organized by Indic-Computing 
Consortium was held from 28th to 30th March 2003 at PES Institute of 
Technology, Bangalore. The Indic-Computing Consortium is an initiative 
of software developers, businesses and academic institutions to evolve 
appropriate standards, resources and technologies for the 
Indic-Computing community. The Indic-Computing Consortium is designed as 
a national-level participatory organisation that serves as a common 
forum for discussion, information exchange and advocacy on behalf of all 
parties interested in the development of Indic Language Computing.

The workshop second in series was attended by 36 participants from 
various languages & technology groups across India, Nepal & Bangladesh. 
This workshop was an outcome of deliberation held in the first 
Indic-Computing workshop held in September 2002 at Bangalore. One of the 
working groups formed at the first Indic-Computing workshop was for 
development of OTF (OpenType Fonts) & other font related issues, 
encoding, language standardization and representation in international 
consortium. One of the action point and agenda for the group was to 
Hold OTF training workshop for developing major Indic language OTF fonts.

The idea was to get the community together for:

i. Developing good look fonts
ii. Development of open source tools for rendering and hinting of OTF 
fonts (currently OTF development uses proprietary tools)
iii. Finding font developers for all Indian languages and coordinating 
group for each language
iv. Making available fonts to be converted to OTF

The workshop addressed above issues and others as enclosed in the 
workshop program (please see the website), through presentations, 
discussions & Lab/training sessions over three days. This was the first 
workshop on the subject, while it focused on OTF, it equally shared 
concerns of open standards community and talks, demos and training 
sessions of open source tools, as well as various alternative 
technologies for Indic fonts were done by some of the participants. The 
copyright/patent issue on OTF was also discussed, and concerns of 
community were answered by Mr. Lawrence Liang, (Expert on Cyber Laws) 
with a caution that the topic is debatable and much would be clear after 
the pending case of Adobe in USA courts is decided.

Summary of Three days:

The three days of deliberations included:

1) Introduction to Indic scripts, Character set, tools & Glyph Design, 
Testing glyphs, was given Ravi Pande, Font Designer, who dealt in depth 
on design of glyphs and generating of fonts & on font formats.
2) Encoding & PfaEdit sessions were taken by Karunakar G, Project Leader 
IndLinux.org, Pramod R of Mahiti & Asmita S. Khobragade of HBCSE. 
Karunakar further elaborated on why OTF hold the answer to some of the 
problems of developers as of now.
3) Dr. U B Pavanaja of Vishva Kannada Softech, discussed the OTF issues 
and described the standards, Open Type Tables and VOLT. The use of VOLT 
to develop OTF was demonstrated; during Lab participants used VOLT to 
get a hands on experience of the tool.
4) Arun M of FSF, demonstrated localized Knoppix in Malayalam and also 
discussed on the issues in Malayalam fonts and display of some special 
characters.
5) Amar Gurung, Director, Nepali Font Standardization Project of Madan 
Puraskar Pustakalaya [MPP], Kathmandu, Nepal, shared the problems in 
standardizing Nepali Font the developments done this far. He shared a CD 
on the project status and the work done (The CD content is now part of 
workshop CD distributed to the participants)
6) Mustafa Jabbar, of Ananda Computers, Dhaka, Bangladesh shared his 
work of 15 years in Bangla (Bengali) fonts. He claimed that a low cost 
software application Bijoy which his company has developed has covered 
95% of market in Bangladesh and is much famous in West Bengal, India 
also. He has also designed the Bangla keyboard that is now a default 
keyboard standard for Bangla.
7) Karunakar took sessions on TTX & talked about issues in fonts on 
Linux while Dr. Pavanaja showed digital signing of fonts. Aditya Gokhale 
of CDAC, took session on hinting of fonts.
8) Nagarjuna G of HBCSE, shared his experience of converting TTF fonts 
offered by Akruti to OTF and shared his experiments in using available 
open source tools to achieve good results.
9) IPR (cyber laws) lawyer Lawrence Liang of Alternate Law Forum, 
discussed the crucial and much debated issue of OTF openness 
(copyright/Patent) after understanding the Adobe & Microsoft agreement 
on release of the fonts. While answering concerns of community Lawrence 
cautioned that the topic is debatable and much would be clear after the 
pending case of Adobe in USA courts is decided.

Conclusion:

At the end of the workshop its was proposed to take up the issues that 
have emerged at more depth through regional consultations on each 
language so that focused attention is their and local & regional groups 
also get chance to participate and discuss there issues. We propose to 
take up these Regional Language Workshops in future across different 
parts of India, Nepal & Bangladesh and other regions with languages of 
Indic origin. These workshops would be coordinated by regional language 
groups (see proposed group) and would include training programs and 
technology demonstration sessions besides getting the language community 
together.

Regional Language Working Groups:

It was proposed to take up the initiative for having these regional 
workshops through voluntary and community efforts. An individual 
commitment on part of participants was requested to involve there energy 
in development of these regional groups and also to discuss with these 
respective organization to release atleast two fonts in each language in 
open domain. Many participants gave the commitment to take the 
initiative and also to get their organization involved in the 
initiative. The following Regional Working Groups are proposed (to be 
confirmed), these groups would take initiative and involve other 
regional partners and build common understanding of major issues to be 
discussed in the Regional Workshops. A framework for proposed Regional 
Workshop would be circulated soon for feedback and action by these 
groups. We invite volunteers who would take upon to hold these workshops 
and provide coordination & logistics support and sponsors to contribute 
to development of regional languages. The Indic-Computing Consortium 
would provide necessary technical support and capacity building to these 
regional groups.

Hindi

Ravi Kant, Sarai, New Delhi, <rav...@sa...>
Maryivan, Sarai, New Delhi <ma...@sa...>
Niyam Bhusan, New Delhi <lin...@bh...>

Kannada

Dr. U B Pavanaja, Vishva Kannada Softech, Bangalore 
<pav...@vi...>
PES Institute of Technology, Bangalore, Karnataka
Central Institute of Indian Languages, Mysore
C.V. Srinatha Sastry, KGP, Bangalore, <sa...@ea...>
Arun Sharma <ar...@sh...>
Alok Kumar, Infosys, Bangalore, Karnataka <al...@ya...>
Bhupesh Koli, BharateeyaOO.o Team, NCST (National Centre for Software 
Technology), Bangalore, <bh...@nc...>
Shikha G Pillai, BharateeyaOO.o Team, NCST (National Centre for Software 
Technology), Bangalore, <sh...@nc...>
Abhas Abhinav, DeepRoot Linux, Bangalore, <ab...@de...>
Sunil Abraham, Mahiti, Bangalore, <su...@ma...>
Pramod R, Mahiti, Bangalore, <pr...@ma...>

Punjabi

Niyam Bhusan, New Delhi <lin...@bh...>
Janmeja Johl, Ludhiana, Punjab <ja...@em...>

Urdu, Sindhi, Kashmiri & Persian

Pritam Nahar, Reality Information Systems, Pune, Maharastra 
<pr...@re...>
Dr. Tarique Sani <from Nagpur>??
Pakistan  LUG, GLUG ??
Mahesh Kulkarni, CDAC, Pune, Maharastra <md...@cd...>
Aditya Gokhale, CDAC, Pune, Maharastra <ad...@cd...>

Bengali/Bangala, Assamese & Manipuri

Mustafa Jabbar, Ananda Computers, Dhaka, Bangladesh <an...@bd...>
Sayamindu Dasgupta, LUG, Kolkatta, <unm...@So...>
Zaheed Hossain, Ananda Computers, Kolkatta,
Ravi Kant, Sarai, New Delhi, <rav...@sa...>
Bangladesh group of Tani Ahmed, ??

Marathi & Konkani

Nagarjuna G, Homi Bhaba Center for Science & Education, Mumbai 
<nag...@hb...>
Sunil J. Shetty, Modular Infotech, Pune, <shr...@mo...>
Mohan Jadav, Modular Infotech, Pune, <mo...@mo...>
Prakash Advani, Netcore, Mumbai, <pr...@ne...>
G. Karunakar, Netcore, Mumbai, <kar...@ne...>
Ravi Pande, Pune, <pa...@ya...>
Asmita S. Khobragade, Homi Bhaba Center for Science & Education, Mumbai 
<asm...@ya...>
Frederick Noronha, Bytesforall, Goa <fr...@by...>

Tamil

K. Viveka Nathan, TeNet, IIT Madras, Chennai <vi...@la...>
R. Murugapandian, Sudharsanam Centre for Arts & Culture, Pudukkottai, 
Tamil Nadu <bar...@sa...>
Manoj R Annadurai, Chennai Kavigal, <ma...@ch...>
Dr. V. Venkataramanan, <http://www.tamillinux.org> ??
International Forum for Information Technology in Tamil, 
http://www.infitt.org/

Telugu

Kiran Chandra, Jana Vignana Vedika, (Prajashakti Daily), Hyderabad, 
<kir...@pr...>
Atul Negi, University of Hyderabad, Hyderabad <at...@uo...>
Rajasekharan, NISC India, Hyderabad, <ra...@ni...>

Gujarati

R. K. Dave, G.A.D, Government of Gujarat, Gandhi Nagar, 
<rkd...@ho...>
Bhavin Choksi, CRAnTI Technologies, Ahmedabad <bh...@ya...>
Ramesh Patel, SRISTI, Ahmedabad <ra...@sr...>

Malayalam

Rajkumar S, FSF, Trivendram, <s_...@my...> <ra...@li...>
Arun M, FSF, Trivendram, <ar...@fr...>

Nepali

Amar Gurung, Nepali Font Standardization Project, Madan Puraskar 
Pustakalaya [MPP], Kathmandu, Nepal, <ama...@in...>
Pawan Chitrakar, Kathmandu, Nepal, <pc...@in...>

Oriya

Sashikant, NIIT, Sambhalpur, Orissa, <sas...@ya...>

Sanskrit
??

[Indic-computing-devel] Non-Roman Script Initiative of SIL International

[Dr. U.B. P. <pav...@vi...>]

http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&cat_id=
Home-----------------------------------------------------
Dr. U.B. Pavanaja
Editor, Vishva Kannada
World's first Internet magazine in Kannada
http://www.vishvakannada.com/

Note: I don't worry about pselling mixtakes

[Indic-computing-devel] libxindic

[<al...@ya...>]

http://web.mit.edu/afs/sipb.mit.edu/user/aatharuv/projects/xindic/
Just want to know if any of you have tried this.


=====
Alok Kumar
F1, Wireless Monitoring Station Compound,
9th Main, 47th Cross, Jayanagar V Block
Bangalore 560076 India
+91-80-653-8200
http://groups.yahoo.com/group/linux-bangalore-hindi/
Can't see Hindi? http://geocities.com/alkuma/seehindi.html

________________________________________________________________________
Missed your favourite TV serial last night? Try the new, Yahoo! TV.
       visit http://in.tv.yahoo.com

[Indic-computing-devel] XFree86 org issues and its impact on indic computing

[Arun S. <ar...@sh...>]

http://xfree86.org/pipermail/forum/2003-March/thread.html

Going through the discussion, it seems to me that Xft/fontconfig vs STSF
seems to be at the heart of the disagreement.

Hopefully, all the heat generated in the discussion will end up in
positive energies and more indic support. 

	-Arun

[Indic-computing-devel] Translation review request - Indic font howto + GFDL to Hindi

[<al...@ya...>]

Hi list,
This is a request to review the translation of
http://www.tldp.org/HOWTO/Indic-Fonts-HOWTO/ available at
http://geocities.com/alkuma/linux
to hi_IN.UTF-8 , the howto by Maninder Bali on indix installation.
There are a few things to be added, viz,
* meta tags for language, encoding, description
* matching of link text with section titles
* acknowledgement and thanks.

Since some tags are missing, you may have to manually set the encoding to utf-8
in your browsers.

Content wise however, the translation is complete.
It also contains a translation of the GFDL.

Your suggestions are welcome.

http://geocities.com/alkuma/linux
Alok


=====
Alok Kumar
F1, Wireless Monitoring Station Compound,
9th Main, 47th Cross, Jayanagar V Block
Bangalore 560076 India
+91-80-653-8200
http://groups.yahoo.com/group/linux-bangalore-hindi/
Can't see Hindi? http://geocities.com/alkuma/seehindi.html

________________________________________________________________________
Missed your favourite TV serial last night? Try the new, Yahoo! TV.
       visit http://in.tv.yahoo.com

[Indic-computing-devel] Re: [Indic-computing-standards] [Indic-Computing] Indic Font Workshop

[Vijay P. S. A. <vi...@ek...>]

K Nagarajan wrote:

>Well, discussions are onething and sustained development is another. As
>you know, I did develop a small generic transliteration framework and
>presented it briefly at the Sep 2002 Indic w/s. After that, I made it as a
>proper library and submitted it to sourceforge (I think all those on the
>devel list would have got a cvs log message on it). I am currently working
>on a generic rendering library on top of freetype-2 (with X as backend) to
>render the glyph sequence for a 'word' in any Indian script that the
>transliteration library will give as output. This may take some time
>(since I am not getting much free time). With this framework we do hope to
>have a generic input and rendering and editing framework on top of X,
>without any changes to X. Also, I am planning to enhance the translib to 
>take any input - UTF8, UCS-4 etc - instead of just Roman phonetic input.
>Well, this is just a small work from my side and only after this framework
>is completed I will have anything to show or discuss.
>
>I am a bit disappointed that there hasn't been any major debate on OTF on
>the indic list either based on issues raised by me/Koshy. If there had
>been some discussion, then it would be more fruitful to make a live
>discussion/debate on it in the w/s.
>
>I will get in touch with Karunakar. Thanks.
>
Nagarajan,

Though I agree with what you say and we had been discussing with Koshy 
on these issues for long. I but sincerely suggest that all of us should 
try to get some more interested/ dedicated guys in the loop and try to 
get more result on board. Just my thoughts, If you would be able to give 
sometime for the workshop and try to find interested participants may be 
you would be able to get some elusive feedback.

best wishes

vijay


__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

[Indic-computing-devel] [Fwd: [LM] Thamizha! tested..!]

[Vijay P. S. A. <vi...@ek...>]

-------- Original Message --------
Subject: [LM] Thamizha! tested..!
Date: Sat, 08 Mar 2003 13:48:57 +0530 (India Standard Time)
From: Murugapandian <pa...@pu...>
Reply-To: Lin...@ya...
To: Lin...@ya...
References: 
<252...@ic...>



Dear Enthoo's
This mail is to tell you my experience with Beta version of Thamizha!
Browser.
Its a 13MB installation file, which can be downloaded from www.thamizha.com.
And installation goes without any problem. Please note that this version is
designed for Windows 2000 and XP only. the edition for 9x platforms is under
construction.

Please look at the following the following things, for installation of
Thamizha!
* check Tamil is configured in your machine. if yes, go ahead. or please
install Tamil from your windows installation CD. Regional settings in
Control panel will help you!
* If you are not satisfying the above stated point, tamil letters will be
looked jumbled. ie, ku will be misinterpreted as ka+kombu! :(
* Our friends who have tested this browser, saying that, the combined
letters like kO, ko are misplaced. if first point has been satisfied, you
can browse/mail with Tamil interface happily.

Please spend some time in Thamizha and send your queries, suggestions,
modifications to the team (via their website www.thamizha.com).

Wish you a Happy Tamil Browsing!!

nanRikaL!
Anbudan
Pandian


[Non-text portions of this message have been removed]


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get 128 Bit SSL Encryption!
http://us.click.yahoo.com/xaxhjB/hdqFAA/xGHJAA/0XFolB/TM
---------------------------------------------------------------------~->

----------------------------------------------------------------
      The Madurai Linux User Group ---> Linux - Madurai
               http://linuxmadurai.tripod.com
---------------------------------------------------------------- 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 





-- 

Vijay Pratap Singh Aditya
ekgaon technologies
email: vi...@ek...
website: http://www.ekgaon.com



__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

[Indic-computing-devel] Re: [smc-devel] FW: Malayalam Cillaksharams (was Ya-phalaa)

[Baiju M <bai...@ly...>]

If none of ZWJ and ZWNJ is specified after a virama it should be rendered as an explicit virama.
ie., NA + VIRAMA (should render as NA+VIRAMA)

If we are adopting the new Malayalam Inscript layout propsed by Kerala govt. (which has got single keys for 5 chillus ), Inputing chillus will be very easy (It can impliment very easily by using Compose keys in GNU/Linux)

Regards,
Baiju M

On Wed, 5 Mar 2003 22:09:51   
 Andy White wrote:
>"This is part of the improvements to [the] Unicode [Standard] that have
>been made for [Version] 4.0"
>
>[...]
>> To reiterate our consistency in using this model, I will give you a 
>> Malayalam example.
>> 
>> NA + VIRAMA + MA --> NMA (a single conjunct)
>> NA + VIRAMA + ZWNJ + MA --> NMA (with a visible virama breve 
>> above and between) NA + VIRAMA + ZWJ + MA --> NMA (with the 
>> cillaks.aram virama curl)
>[...]
>> Michael Everson
>
>I have always advocated the use of the above mentioned rendering rules
>for Malayalam. However, people trying to Implement Malayalam in Unicode
>have periodically asked on this list the question of how to encode
>chillu forms.
>Due to the lack of any official response, those implementations that I
>have seen unfortunately do not follow the above rules.
>***If you have such an implementation, Especially anyone responsible for
>a rendering subsystem, please take note***.
>
>Andy
>
>
>
>
>_______________________________________________
>smc-devel mailing list
>smc...@no...
>http://mail.nongnu.org/mailman/listinfo/smc-devel
>


_____________________________________________________________
Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year.
http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus

[Indic-computing-devel] FW: Malayalam Cillaksharams (was Ya-phalaa)

[Andy W. <And...@bt...>]

"This is part of the improvements to [the] Unicode [Standard] that have
been made for [Version] 4.0"

[...]
> To reiterate our consistency in using this model, I will give you a 
> Malayalam example.
> 
> NA + VIRAMA + MA --> NMA (a single conjunct)
> NA + VIRAMA + ZWNJ + MA --> NMA (with a visible virama breve 
> above and between) NA + VIRAMA + ZWJ + MA --> NMA (with the 
> cillaks.aram virama curl)
[...]
> Michael Everson

I have always advocated the use of the above mentioned rendering rules
for Malayalam. However, people trying to Implement Malayalam in Unicode
have periodically asked on this list the question of how to encode
chillu forms.
Due to the lack of any official response, those implementations that I
have seen unfortunately do not follow the above rules.
***If you have such an implementation, Especially anyone responsible for
a rendering subsystem, please take note***.

Andy

[Indic-computing-devel] FW: Displaying the languages of the Indian subcontinent. (derives from Re: Please see my latest proposal)

[Andy W. <And...@bt...>]

I am Forwarding this from the 'Unicode list':

[from William Overington]

Firstly, I mention that I am not a linguist and do not write to make a
linguistic comment at all.

As some readers of this mailing list may know, I am very interested in
interactive television, in particular the DVB-MHP (Digital Video
Broadcasting - Multimedia Home Platform) system, which uses Unicode.

Now, from the specification for the DVB-MHP system, which can be
downloaded from the http://www.mhp.org website, it appears that fonts
for the DVB-MHP system, which can be broadcast, are to be in the PFR0
system, Portable Font Resource version 0.  I have some time ago obtained
some details of that system and looked through them, but did not follow
all of the details, yet, as the system seemed to date from the early
1990s it seems entirely possible that the PFR0 system does not support
the mechanism which allows a font to substitute a particular glyph for a
sequence such as the  U+0985 U+09CD
U+09AF which Michael mentioned in his reply to Andy, quoted above. [A
Bengali unicode sequence]

It would therefore seem that the DVB-MHP interactive television system,
which is a system for worldwide use, may come up against considerable
rendering problems when it comes to making broadcasts using the
languages of the Indian subcontinent.  I am seeking to resolve that
problem by devising an infrastructural tool to program round the problem
by preprocessing received Unicode text in the television receiver before
it is passed to the font, so that facilities for quality typography for
the languages of the Indian subcontinent exist with the DVB-MHP
platform.

Is this a problem particular just to interactive television or is it a
wider problem?

I made a suggestion for a eutocode typography file in the following web
page.

http://www.users.globalnet.co.uk/~ngo/ast03300.htm

Now whether that use of some of the code points of the Private Use Area
by a user community were used in some scenarios (for example with PFR0
fonts in interactive broadcasting) or whether the glyphs would be
numbered in some other sequence of numbering within a font, I am putting
forward for discussion the question as to whether it might be useful for
there to be produced a list of ligatures for the languages of the Indian
subcontinent such that each ligature has an index number in an ordered
sequence from 1 upwards, so that those code numbers can be a standard
way of accessing glyphs within fonts or within systems such as a
eutocode typography file. It may be that any particular application of
such a list would add an offset constant to the list number during
processing, for example hexadecimal EC00 for a eutocode typography file,
or maybe 500 for an advanced format font, yet the idea would be that
some particular glyph for a particular ligature glyph, for, say, Tamil,
would always be at position XYZ relative to the start of the list.  This
would mean that substitution tables for rendering from a Unicode
sequence to a displayable glyph could become portable rather than font
specific, so there might, in time, be a great saving of duplicated
effort in having such a numbered list of ligature glyphs.

I emphasise that I am not in any way suggesting using Private Use Area
codes for (italics) interchange (/italics) of text in these languages, I
am simply suggesting that there seems to be the possibility that the
process of producing fonts and other software systems for the carrying
out of the task of glyph substitution for particular Unicode sequences
could be made a more portable process if such a list were to exist.

Is there interest in such a list of ligature characters in a numbered
list being produced?  As I say, I am not a linguist so I could not carry
out the task, yet perhaps the task might be fairly straightforward,
though necessarily taking a substantial amount of effort, for some of
the readers of this mailing list, if there is interest in such a list
being produced. Once done, the list would have long term usefulness.
Spaces for the numbering could perhaps be allocated in the same order as
the various languages of the Indian subcontinent are encoded within the
Unicode Standard.  Clearly expert guidance is needed as to how many
ligatures exist for any particular language.

The list would also be a useful index for glyphs in a "glyph library" of
designs.

I was interested to read in a recent thread in this forum of the
founding of the International Font Technology Association (IFTA) and
wonder whether that organization would be an appropriate body to produce
such a list, if there should be interest in the production of such a
list.

I would be pleased to know the views of people within this group as to
whether such a list would be of advantage to typographers and others
involved in computerized typography. . William Overington

3 March 2003

RE: [Indic-computing-devel] Testing OpenType support

[Arun M <ar...@fr...>]

Hi,

   We have seen two ways to represent chillu. How can we decide upon and
publicise one as standard. I will try to put this infront of IT
department of the Kerala Govt. 


Arun.

RE: [Indic-computing-devel] Testing OpenType support

[Arun M <ar...@fr...>]

Thanks, Keyur and Andy for valuable comments

> > A1. <C1><virama> will produce Chillu form (if any).
> > A2. <C1><virama><ZWNJ> will produce halant form of C1.
> > A3. <C1><virama><C2> will produce a ligature if <C1> doesn't
> > have chillu form. 
> > A4. <C1><virama><ZWJ><C2> will produce a 
> > ligature if <C1> has chillu form. 
> 
> The problem with A4 here is that the current specification of 'half'
> does not allow a ligatures of C1C2. IMHO a new feature would need to be
> specified. (feature 'cillu' ?).

A4 is not required, based on my understanding of malayalam. 


> Why not just always put a ZWJ whenever a chillu is desired?
> So C1chillu = C1+ZWJ  (always) 

This is what we did with Malayalam pango module with x backend we made
some time back. (following malayalam support in  TeX.)

http://members.tripod.com/~jhellingman/IndianScriptsUnicode.html

> > Approach-2:
> > ----------
> > 
> > B1. <C1><virama><ZWJ> will produce Chillu form (if any).
> > B2. <C1><virama> will produce halant form if <C1> is not part
> > of a ligature. 
> > B3. <C1><virama><ZWNJ> will also produce 
> > halant form of <C1>. 
> > B4. <C1><virama><C2> will produce a 
> > ligature (or consonant conjunct).
> > 
> > The issue here is that people generally believe that ZWJ is
> > used to join the consonant preceding it with the consonant 
> > immediately following ZWJ. Thus, ZWJ virtually becomes part 
> > of the syllable. Here we are using it to terminate the syllable.
> 
> Keyur, I agree with you. Both of the approaches above make sense.
> However, Approach-2 is more compatible with the current state of the
> situation. It would need less work to get it to work and is less likely
> to break any existing implementations (IMHO).
> Approach- 2 does not explain how to create a chillu+consonant conjunct.
> Assuming your answer is <C1><virama><ZWJ><C2>, then again, either a new
> feature definition is required, or the existing feature 'half' will need
> respecifying.


Approach 1 works better in current situation(note that step A4 is not
needed). We will just need to add chillu feature. Also it goes with the
unicode suggestion that <consonant><virama><ZWNJ> will give halant form.
Also what i understand from some language experts is that when we write
NNA(or other consonants having chillu form) with visible halant now
days, it actually represents <NNA><vowel sign U><halant>   
(Vowel A is removed from consonant and U is added)

Approach 2 will be easier to make as we may not need any change in
renderer.

regards
arun

RE: [Indic-computing-devel] Testing OpenType support

[Andy W. <And...@bt...>]

 Keyur Shroff wrote:


> 
> Approach-1:
> ----------
> 
> A1. <C1><virama> will produce Chillu form (if any).
> A2. <C1><virama><ZWNJ> will produce halant form of C1.
> A3. <C1><virama><C2> will produce a ligature if <C1> doesn't
> have chillu form. 
> A4. <C1><virama><ZWJ><C2> will produce a 
> ligature if <C1> has chillu form. 

The problem with A4 here is that the current specification of 'half'
does not allow a ligatures of C1C2. IMHO a new feature would need to be
specified. (feature 'cillu' ?).

> A4 has been given to answer the question:
> "How to produce <C1-chillu><C2> sequence if <C1><virama><C2>
> produce a ligature". As a result the rule A3 should be used 
> when there is no chillu form of <C1> and A4 should be used 
> when there is a chillu form of the consonant <C1>.
> 
> The issue with this approach is that we have to use ZWJ in
> conjunct formation when <C1> has chillu form.

Why not just always put a ZWJ whenever a chillu is desired?
So C1chillu = C1+ZWJ  (always) 
> 
> Approach-2:
> ----------
> 
> B1. <C1><virama><ZWJ> will produce Chillu form (if any).
> B2. <C1><virama> will produce halant form if <C1> is not part
> of a ligature. 
> B3. <C1><virama><ZWNJ> will also produce 
> halant form of <C1>. 
> B4. <C1><virama><C2> will produce a 
> ligature (or consonant conjunct).
> 
> The issue here is that people generally believe that ZWJ is
> used to join the consonant preceding it with the consonant 
> immediately following ZWJ. Thus, ZWJ virtually becomes part 
> of the syllable. Here we are using it to terminate the syllable.

Keyur, I agree with you. Both of the approaches above make sense.
However, Approach-2 is more compatible with the current state of the
situation. It would need less work to get it to work and is less likely
to break any existing implementations (IMHO).
Approach- 2 does not explain how to create a chillu+consonant conjunct.
Assuming your answer is <C1><virama><ZWJ><C2>, then again, either a new
feature definition is required, or the existing feature 'half' will need
respecifying.

Andy

RE: [Indic-computing-devel] Testing OpenType support

[Andy W. <And...@bt...>]

Arun M wrote:

> My knowledge of OpenType is very limited. Here is the issue. 
> http://www.microsoft.com/typography/otfntdev/indicot/features.htm

This document was written at a long time ago, when OpenType for Indic
scripts was still in the early planning stage, it has only been
partially updated. Most of it has been rewritten as separate script
specific documents. Unfortunately, the Malayalam specification has been
left behind.  

> It says for some consonants (eg NNA) halant form will be
> represented by chillaksharam. My understanding is
>  <NNA><virama>  will form chillu NNA.

The form that any given isolated 'Consonant + Virama' will be
subsequently rendered as, is not prescribed in the Unicode standard; so
implementers are free to call any feature they like.  However, all
current implementations call feature 'haln' for the sequence, 'Consonant
+ Virama'.

The sequence Consonant+ Virama+ZWNJ has been prescribed to render as a
consonant with a visible virama (chandrakkala)
All current implementations call feature 'haln' for this sequence also.
Hence it seems that feature 'haln' should render a visible chandrakkala

The Unicode sequence 'Consonant + Virama + ZWJ' is equivalent to the
ISCII sequence 'Consonant + Virama + Nukta'. In ISCII, 'Consonant +
Virama + Nukta' is prescribed to form the chillu forms of consonants. As
Unicode is modelled on ISCII, it follows that Unicode sequence,
'Consonant + Virama + ZWJ' should also be used to render the Chillu
letters.
Current implementations call feature 'half' for this sequence, hence it
seems that feature 'half' should deal with the formation of the chillu.

 
<NNA><virama><ZWNJ> will make virama visible as it is and consonant will
be in base form. 

>How does NNA+virama and NNA+virama+ZWNJ should differ ?
The Unicode standard allows the freedom for 'Consonant + Virama' &
'Consonant + Virama+ ZWNJ' to differ in appearance, if it is deemed
appropriate by an implementation (usually they would not differ).


Andy

RE: [Indic-computing-devel] Testing OpenType support

[Keyur S. <key...@ya...>]

--- Arun M <ar...@fr...> wrote:

> 
> My knowledge of OpenType is very limited. Here is the issue.
> http://www.microsoft.com/typography/otfntdev/indicot/features.htm
> 
> It says for some consonants (eg NNA) halant form will be represented by
> chillaksharam. My understanding is <NNA><virama>  will form chillu NNA. 
> <NNA><virama><ZWNJ> will make virama visible as it is and consonant will
> be in base form. 
> 
> How does NNA+virama and NNA+virama+ZWNJ should differ ?
> 

This has been the issue pending since long ago. Unfortunately, Unicode
remains almost silent about this confusion :-(. I think some clarification
is required in Unicode Indic-FAQ when some consensus has been reached.

We want use virama sign in three different cases. 

(A) chillu form, 
(B) virama (halant) form, and  
(C) ligature (or consonant conjuct).

A scheme should be able to support all 3 possible kind of rendering when
using halant in Malayalam.

It seems that there are two approaches to select alternate forms at
present; using ZWJ and/or using ZWNJ. It is general belief (I may be wrong
;-)) that ZWJ becomes part of the syllable and ZWNJ forces termination of a
syllable.


Approach-1:
----------

A1. <C1><virama> will produce Chillu form (if any).
A2. <C1><virama><ZWNJ> will produce halant form of C1.
A3. <C1><virama><C2> will produce a ligature if <C1> doesn't have chillu
form.
A4. <C1><virama><ZWJ><C2> will produce a ligature if <C1> has chillu form. 

A4 has been given to answer the question:
"How to produce <C1-chillu><C2> sequence if <C1><virama><C2> produce a
ligature". As a result the rule A3 should be used when there is no chillu
form of <C1> and A4 should be used when there is a chillu form of the
consonant <C1>.

The issue with this approach is that we have to use ZWJ in conjunct
formation when <C1> has chillu form.


Approach-2:
----------

B1. <C1><virama><ZWJ> will produce Chillu form (if any).
B2. <C1><virama> will produce halant form if <C1> is not part of a
ligature.
B3. <C1><virama><ZWNJ> will also produce halant form of <C1>.
B4. <C1><virama><C2> will produce a ligature (or consonant conjunct).

The issue here is that people generally believe that ZWJ is used to join
the consonant preceding it with the consonant immediately following ZWJ.
Thus, ZWJ virtually becomes part of the syllable. Here we are using it to
terminate the syllable.


However, I am not a Malayalam expert :-) My observations are based on my
discussion with a Malayalam font designer. It is better if you once again
raise this issue on Unicode list.

- Keyur


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

RE: [Indic-computing-devel] Testing OpenType support

[Arun M <ar...@fr...>]

> I am confused. Why do you think that this is not the right thing for
> Malayalam?
> According to the Unicode encoding model, consonant + virama + ZWNJ
> should render a visible Halant. In Uniscribe, ICU and Pango, this causes
> lookups in feature 'haln' to be applied. Therefore the feature 'haln'
> should only be used to create visible Halant forms of consonants. Do you
> think that is wrong for Malayalam?


My knowledge of OpenType is very limited. Here is the issue.
http://www.microsoft.com/typography/otfntdev/indicot/features.htm

It says for some consonants (eg NNA) halant form will be represented by
chillaksharam. My understanding is <NNA><virama>  will form chillu NNA. 
<NNA><virama><ZWNJ> will make virama visible as it is and consonant will
be in base form. 

How does NNA+virama and NNA+virama+ZWNJ should differ ?


thanks for the response,

regards,
arun.

RE: [Indic-computing-devel] Testing OpenType support

[Andy W. <And...@bt...>]

Arun M wrote:

> >   In Devanagari what should be the output of a sequence like
> > 
> > <consonant><virama><ZWNJ>
> > 
> > Should we apply 'haln' feature of OpenType here ?
> 
> 
>   No response :( 
> 
> Is it because i was not clear or on one know how devanagari works ?

I did not answer - I was sure that someone else would!
(The answer is yes)

> ICU and Pango renderer allows 'haln'  form of the consonant 
> when a sequence like one above comes. For Malayalam its not 
> the right thing. 
> So just wanted to know if its special case for Malayalam.

I am confused. Why do you think that this is not the right thing for
Malayalam?
According to the Unicode encoding model, consonant + virama + ZWNJ
should render a visible Halant. In Uniscribe, ICU and Pango, this causes
lookups in feature 'haln' to be applied. Therefore the feature 'haln'
should only be used to create visible Halant forms of consonants. Do you
think that is wrong for Malayalam?

Andy
 

Re: [Indic-computing-devel] Testing OpenType support

[Arun M <ar...@fr...>]

>   In Devanagari what should be the output of a sequence like 
> 
> <consonant><virama><ZWNJ>
> 
> Should we apply 'haln' feature of OpenType here ?


  No response :( 

Is it because i was not clear or on one know how devanagari works ?

ICU and Pango renderer allows 'haln'  form of the consonant when a
sequence like one above comes. For Malayalam its not the right thing. 
So just wanted to know if its special case for Malayalam.

To Koshy/Tapan/Other organisers

As i wrote earlier we need a dedicated team which can work together
providing information on every Indian language. For each language there
should be one responsible. Our group is too loose with out people taking
clear responsibilities. 

(Just my feeling looking back, may be i am wrong).

Regards,
Arun.

[Indic-computing-devel] [Fwd: Application for participation to the First national OTF Workshop]

[Vijay P. S. A. <vi...@ek...>]

  Hi,

An interesting application for the workshop, worth sharing to explore 
common ideas...

vijay

-- 

Vijay Pratap Singh Aditya
ekgaon technologies
email: vi...@ek...
website: http://www.ekgaon.com



-------- Original Message --------
Subject: Application for participation to the First national OTF Workshop
Date: Fri, 21 Feb 2003 16:31:32 +0545
From: "Amar Gurung" <ama...@in...>
To: <vi...@ek...>



Name: Amar Gurung (Director), Nepali Font Standardization Project
Organization: Madan Puraskar Pustakalaya [MPP]
Email: ama...@in... 
<mailto:ama...@in...>   (www.mpp.org.np <http://www.mpp.org.np>)
Participation: Representing the organization
 
What we expect from the workshop
 

The Madan Puraskar Pustakalaya is a non-profit institution of 45 years 
standing, a respected repository of Nepali language and literature. It 
manages the largest archive in the Nepali language, and supports the use 
of Nepali for the social, economic and cultural advancement of all Nepalis.

 

The Pustakalaya, in accordance with this goal, has been involved in a 
project for Nepali Font Standardization, which means making the many 
Nepali fonts compatible by deciding on one coding standard. In its first 
(and current) phase, the Pustakalaya project has achieved the following:

 

1.       A Unicode-compatible Nepali font and corresponding keyboard driver.

2.       A customizable sorting utility for the Nepali language.

3.       A typing tutor software to be distributed freely.

4.       A Nepali font converter utility

 

 

For full details of the project please refer to our website. The 
completion of the first phase of work by the Madan Puraskar Pustakalaya 
lays the groundwork for the extensive usage of computing in the Nepali 
language. The standardization exercise will generate social dividends 
when software developers are spurred to develop applications in the vast 
area that opens up, from governance to administration, social and 
development work, in accounting, communications, education and so on.
 
However, we need to keep ahead with time and learn from other similar 
experiences. We believe the workshop you are organizing is the right 
platform for us to learn new things as well as share our experience with 
others.
 
Therefore I request you to accept our application to participate in the 
workshop. Myself and a collegue (Pawan chitrakar) from the technical 
team would like to attend your workshop.
 
Hope to hear from you soon regarding the above.
 
Thank you,
 
Amar Gurung

Re: [Indic-computing-devel] Testing OpenType support

[Arun M <ar...@fr...>]

Hi all,

  In Devanagari what should be the output of a sequence like 

<consonant><virama><ZWNJ>

Should we apply 'haln' feature of OpenType here ?

regards,
arun. 

Re: [Indic-computing-devel] Testing OpenType support

[Arun M <ar...@fr...>]

> >> I am doing some testing for Telugu, using Pothana2000 font, on Gnome
> > 
> > 
> > Is it a Free Font ? Can i get it ?
> > 
>   Free as in 'free beer' , available from 
> http://www.kavya-nandanam.com/Pothana2k-95.exe

Any idea about Free as in 'freedom' Telugu OpenType font ? It would be
nice if some one start working on converting Akruti Telugu font to
OpenType. We should try to make one indian language OTF font. (Tamil,
Malayalam and Bengla seems to be ready)

Re: [Indic-computing-devel] Testing OpenType support

[Arun M <ar...@fr...>]

> Wrt Bangla, we at bengalinux.org are willing to help
> How do we go about it??


We can do the testing regularly and post the issues in this list. Then
try to fix the stuff ourselves and submit to ICU. If we are not able to
fix we can file the bug report. 


arun.

Re: [Indic-computing-devel] Testing OpenType support

[Sayamindu D. <unm...@So...>]

On Wed, 2003-02-19 at 21:41, Arun M wrote:
> Hi All,
> 
>    I've been working with Eric Manders of ICU project to get Malayalam
> work better. Except for Devnagari, Tamil and Malayalam not much work
> seems to be happening to test the code. 
> 
> In ICU same function is being used to handle 9 scripts. A fix in one
> language can break others. We can address this if a team form this list
> to do the testing for each indian languages. A bug free version of ICU
> will help FreeSoftware localisation as most of the many projects goes to
> ICU for OpenType support (OpenOffice, Mozilla, GTK).

Wrt Bangla, we at bengalinux.org are willing to help
How do we go about it??

-sayamindu-

-- 
Sayamindu Dasgupta [ http://www.peacefulaction.org/sayamindu/ ]

=========================================
Speak out on social and cultural issues
		at
	PeacefulAction.Org
    http://www.peacefulaction.org
*****************************************


Due to circumstances beyond your control, you are master of your fate
and captain of your soul.