indic-computing-standards Mailing List for The Indic-Computing Project (Page 3)
Status: Alpha
Brought to you by:
jkoshy
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(10) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(7) |
Feb
(16) |
Mar
(20) |
Apr
(52) |
May
(8) |
Jun
|
Jul
(35) |
Aug
(20) |
Sep
(2) |
Oct
(4) |
Nov
(16) |
Dec
(1) |
2003 |
Jan
(9) |
Feb
(1) |
Mar
(1) |
Apr
|
May
(9) |
Jun
(6) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2004 |
Jan
(4) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
(1) |
Nov
(5) |
Dec
(1) |
2008 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Dr. U.B. P. <pav...@vi...> - 2002-11-25 04:50:39
|
Hi all, There is a new font technology for the web. It is called Photofont. The url is www.photofont.com. This is by the people who make FontLab. This was in the pipeline for quite some time and now the specs are there. I had met Mr. Ted Harrison, President of FontLab Inc. lats Aug. He had mentioned to me about this new initiative at that time. When I checked the site and went through the specs I realised that they don't support all the features of Opentype fonts, expecially the GSUB and GPOS tables. Without this support we can not use it for Indic scripts. The technology of Photofont is somewhat similar to dynamic fonts. Each glyph is converted from bitmap to plain text and then stored in the web server. The web browser need to get a free plug-in from Photofont to display the font. There is no need to have the font installed in the local system. The process of installing the plug-in has to be done only once (this was the case with the ActiveX plug- in for IE browser for PFR fonts, which is defunct now). I had sent mails to Ted Harrison about OTF support in Photofont and the answer was in the negative. They are not planning to support OTF. But he says that the specifications are open and we are welcome to add the support ourselves. I have attached my mails to Ted and his replies at the end of this mail. Please take a look at photofont.com, study the specs and think about extedning the support to OTF. Any volunteers? Thanks and regards, Pavanaja ----------- Begin mail 1 fro Ted -------- Dear Dr. Pavanaja, > I am bit surprised to > know that it does not support the Opentype tables like GSub, > GPos, etc. Without these support we can not use this technology > for Indic scripts. What are your plans about supporting Opentype > tables? Well, I'm sure you noticed that photofonts are not OpenType fonts. They are a new bitmap font format. Therefore it is highly likely that they will never support OT tables. Regards, Ted Harrison FontLab Ltd. --------------- End mail 1 ---------------------- ---------------- Begin mail 2 from Ted -------------- Dear Dr. Pavanaja,, > In that case, how are you planning to support complex scripts > (Indic scripts, Arabic, etc)? > We are not. However, it is an open specification so anyone who wants to add that capability is welcome to come up with a mechanism. Regards, Ted Harrison FontLab Ltd. ------------------ End mail 2 from Ted ------------------------------- ----------------------------------------------------- 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 |
From: Nagarjuna G. <nag...@hb...> - 2002-11-20 04:00:34
|
MAIT consortium includes several players who betrayed this country for not working for localization standards so far. They have also betrayed the industry. They have used up tax payers money for more than a decade and gave us what? [BTW: If you read the charter of Nasscom, easy to access since they are sitting next door to your office, you will find nothing objectionable. What are they doing and what they have achieved is important. (Why Nasscomm doesn't take up the free software in their agenda? Is their anything in their charter that says against free software? We will find nothing?)] I do agree with you that we need to include everyone when we talk of standards. My point is if they have achieved what was written in their objectives, then what is the need for indic-computing initiative, largely coming from volunteers like us. The need was presicely because they failed in doing what they intended to do. Their commercial interests override the public good. Even govt which figures in the list could not play the buffer role is clear. That is the reason I feel, that we can continue to include them in our efforts, but they being here should not dilute or compromise our principles, such as working for a common and open standards and making the basic tools, such as fonts and ecoding methods, available as free software. If all that is written below is true, then we dont need to do anything. Nagarjuna On Tue, Nov 19, 2002 at 07:34:34PM +0530, ve...@vs... wrote: > http://www.dqindia.com/content/top_stories/102110901.asp > > I was going through the Dataquest article and came across the box item on the MAIT Consortium on Innovation and Language Technology (COIL Tech). The charter seems similar (or at least has significant overlaps) with what we are doing. > > This brings me to the next point: we are currently formalizing Indic Computing as a non-profit organization and it would be good to hear this group's opinions on what the charter of Indic Computing should be. Any thoughts on this and on how we can collaborate with MAIT? > > Venky > > > The MAIT Consortium on Innovation and Language Technology (COIL Tech) > Founded in: 2001 (September) > Active members: Wipro Infotech, Wipro e-peripherals, TVS Electronics, Lipi Data Systems, Modular Infotech, NIC, C-DAC, NC, Apple Soft, ER&DCI Cyberscope Multimedia, Summit IT, Web Dunia, Blue Cell Technologies, Kannada Ganaka parishat, Anu Graphic Systems, Seacom Solutions ETH research Labs, Softview Computers, Microsoft, IBM, HP Labs. > > Core Function: Co-ordinating various activities with IT Industry players and the TDIL (Technology development in Indian Languages)Department of the Ministry of Communications and IT. > > The consortium is working with various state governments to make standards compulsory for software development companies in each state. "The Ministry of IT will eventually announce Unicode as the standard to be used in India and this decision will percolate to the state governments," explains MAIT executive director Vinnie Mehta. > > CoilTech eventually hopes to graduate to an organization that will incubate young companies and provide IT tools to the developer community free of charge and encourage them to build Indian language software. > > "The consortium also expects to be able to export multi-lingual software technologies to other third world countries within the next three to five years," says Mehta. CoilTech has developed standards for font layouts in Devnagari, Gujarati, Malayalam and Punjabi. > > > > > > This sf.net email is sponsored by: To learn the basics of securing > your web site with SSL, click here to get a FREE TRIAL of a Thawte > Server Certificate: http://www.gothawte.com/rd524.html > _______________________________________________ > Indic-computing-users mailing list http://indic-computing.sourceforge.net/ > Ind...@li... > https://lists.sourceforge.net/lists/listinfo/indic-computing-users > [Other Indic-Computing mailing lists: -devel, -standards, -announce] -- ------------------------------------------------------------------------ nag...@hb... www.hbcse.tifr.res.in/gn/ Key fingerprint = C1E2 1B8C 8E98 A697 68B7 ADAC E956 6D4B DE90 BF01 |
From: <ar...@bg...> - 2002-11-18 14:36:28
|
Dear Colleagues, I am much elevated to see a few mails in response to my mails. I have been maintaining an attitude of compromise, compassion and flexibility for the noble cause of standard for Kannada on computers. However, since three years or so, a set of people have started demolishing, outwitting or out bursting against the "Developers" through mass media. Finally, it has reached the stage where-in they have conveniently brought out "NUDI" but with the attitude of ''cry/curse others and cave-in thyself". After all, if I don't address or respond to this set of intentionally out bursts made by the set of people which have already affected the morale and the ability of the developers, it will only amount to mean as if we deserve them and agree to their willful wittings. I have ample of material/circumstantial evidence to prove their wittings against the Developers and the same will be exposed at appropriate time. The attitude of the set of people, have driven me into making my submission fully understanding the background of evaluating the standard for Kannada on computers. I have immense appreciation, affection and creed for the best possible technology for Kannada. Definitely, I have no aspersions to use anything to hurt anyone willfully, but it is only a reflection of my over creed for the language technology. I sincerely solicit you all to set aside some time to go with the details on the standards and respond to the appropriate people with your valuable views also with your feedback to me. After all "Language software development is driven by passion". Thanking you. Yours, MR.N. ANBARASAN email : ar...@bg... , phone : +91-080-3386167. |
From: Keyur S. <key...@ya...> - 2002-11-18 06:32:53
|
--- Mahesh T Pai <pai...@vs...> wrote: > > But, I would like point out that I have come accross more severe > critisms of others' views, but they are extremely dignified. > > The standards in Indian scripts are still fragmented, and very much > concerted effort is necessary to arrive at some form of uniformity. > Conversations like these, will not nelp - not because they lack > merits, but because the language is too offensive. > Mahesh, I fully agree with you. Constructive feedback and criticism on standards may lead to better approach, but the language used should not be offensive. Can we have some useful and constructive debate on "full consonant v/s pure consonant" approach? This will help many people on this list who are not aware fully with both the approaches. I also like to share my views with others :) - Keyur __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com |
From: Mahesh T P. <pai...@vs...> - 2002-11-17 15:46:46
|
ar...@bg... wrote: (censored) It is not my intention to comment the contents of the letter; I do not quite understand what he is writing about. The letter is apparently a consolidation of some conversation between two people, where, when and why it took place it is not clear; nor do I understand what the unnamed attachment is about. Trust it is not a virus. But, I would like point out that I have come accross more severe critisms of others' views, but they are extremely dignified. I do not wish to take sides in a dispute I do not understand about, but I do wish that we can avoid words like following:- (in no particular order) > accusation is that you people are getting funds > victim of jealousy > how immoral you people are > playing a dirty game > How dare you people > just to attract DTP operators and make money The standards in Indian scripts are still fragmented, and very much concerted effort is necessary to arrive at some form of uniformity. Conversations like these, will not nelp - not because they lack merits, but because the language is too offensive. One needs to realise that the "my standard, or none" approach adopted by everybody will be counter productive in the long run. Mahesh T pai. |
From: <ar...@bg...> - 2002-11-17 13:57:27
|
Dear Colleagues, I presume that Mr. Harsha is replying to mails on behalf of the people (I have got it confirmed over phone from one of my friend in that group) whom I have quoted my mail. Hence my reply to this mail is not addressed to Mr.Harsha personally but I am addressing it to the same group whom I quoted in my earlier mail. Anbarasan : It is this annoying trick which is being followed by the 'Specific Group' for Kannada in standardising and developing NUDI for Kannada while blaming the developers. Why this 'Specific Group' never attempted to invent a technology to handle Kannada efficiently using ISCII on computers for the off-the-shelf applications. I leave it to your guess and further pacifying. KGP : Why you people never attempted to invent a technology to handle Tamil efficiently using ISCII ? and why are you people using TSCII ? Anbarasan : "You people" - who is this? It is me or Tamil community. By trying to link my identity with Tamil you are proving how immoral you people are. Instead of asking me this question that why Tamils have not attempted to invent technology to handle Tamil efficiently using ISCII? you should have bothered about Kannada since I have served Kannada Language from 1989. You are trying to hide this thirteen years of my service to Kannada Language and trying to isolate me in Kannada development on the digital media. I am dedicating myself in developing technology for all Indian Languages. I am not particular about any one language. Coming to my technology development in handling ISCII on computers. It is the SURABHI, the first "software only" technological solution (there were only two efforts on this direction one is at APPLESOFT the other was at CIIL Mysore, later on CDAC has announced their GIST Shell) developed to support ISCII on all text based application software on MS DOS. Thereby SURABHI supported MS DOS, Norton Editor, WordStar, Dbase, Lotus 1-2-3. This product was demonstrated at the exhibition organised at Vidhana soudha, Bangalore for the inauguration of Kannada Jagruthi varsha celebrations. The demonstration of SURABHI software was broadcast on the Bangalore Doordharshan on the computerisation efforts of Karnataka Government. Every indic computing developer pretty well aware that the problem involved in implementing ISCII in MS Windows platforms to make use of ISCII in all the off the shelf application software like MS Office or StarOffice. I humbly submit that APPLESOFT is the only organization to demonstrate the possibility of using ISCII for internal storage with standard application software like Notepad, Wordpad, MS Word etc. I am quoting these two of my technological contributions to Indian Languages which enabled the most popular OS of the day. I would like to draw the attention of member of this forum to note that, it is this group continuously blamed the developers since the inception of KGP through mass media propaganda, fooled the media persons by claiming ISCII superiority on one hand and developing software using glyphs on the other hand. That is the reason I am trying to expose these people. So, you are accepting that you have followed Tamil standardisation effort. You are referring to Tamil standardisation effort now to cover up your mischievous standards. While giving interviews or instigating others to write your standardisation efforts you people were conveniently hiding the fact that your standardisation efforts were based on Tamil, while so far claiming your standardisation efforts are first of its kind in India. * Why only referring Tamil - with my own expenses incurring financial losses contributed to develop language standardisation efforts of all languages which I came to know. * Why bother about whether anybody invented any new technology for Tamil or not. * If Tamil got developed it would have been a model for people like you to copy and claim. * Can you justify that if Tamil was not developed, you people also would not develop Kannada. Since you people (Refer Dr. Pavanaja's interview with Frederick Noronha, "Kannada Connects" available on-line at http://www.blonnet.com/ew/2002/03/06/stories/2002030600090200.htm and "Kannada on the keyboard, finally" available at http://www.zdnetindia.com/print.html, he says "We feel the best solution is to have the storage in ISCII. Other solutions have attempted to tie up the user in their own software solutions") are claiming the ISCII is the most suitable for Kannada, it is your interest to develop/invent a technology to handle ISCII and not Tamils to invent technology of ISCII who are not accepting ISCII as a suitable standard for TAMIL. Same is the case with Unicode. That is the reason, why Tamilnadu Government attempted to make a scientific study on the alternate encoding mechanism which NO other Indian language has ever attempted. If you people have made any attempt to prove efficiency of KSCLP over ISCII/Unicode, why it is not published, you make it public. TSCII is not a standard announced or endorsed by any government and hence TSCII is not a approved standard. TSCII is being promoted by people who don't accept the standards. TSCII may become a standard if the user community accepts it because of the failure of the standards. For your information, Tamilnadu Government has announced three prototype encoding standards based on character encoding, a bi-lingual glyph encoding, a monolingual glyph encoding. However, Character encoding standard is still pending. As of now only TAB and TAM are the only standards for Tamil. If you need any further details why three encoding is needed for a language, you may refer to my paper presented in the Tamil Internet 1999 International seminar held at Chennai. If you don't get any information, you may come to my office and have a look into it. If you still not clear on the standardisation issues, you refer to my book on Evolving Tamil Standards which deals with aspects of existing and evolving standards. Further, you are free to contact me for any clarifications. If you don't wish to do so, we still continue on this forum. In my opinion none of the font (the so called) standards can be accepted as standards as they are yet to be recognised by the standards body. As you people always blame the developer, I have not seen any instance of such thing in Tamil computing. Moreover, there is no instances of unethical copying of technology like you people have done and blaming the developer. ----------------------------------------------------------------------------------------------------------- Anbarasan : Later on, when the Specific Group reached the peak of confusion, came out with another altogether different set of character set as Kannada Standard Code for Language Processing. Strangely, the arguable special symbol for 'r' is left out in this character set. If KSCLP code set is meant for Language processing, then what else the other encodings ISCII/UNICODE etc., do. Does it mean that the Group is not aware of the sorting problems when they submitted the recommendation. Why the Government is insisting on SORTING order as per ISCII when KGP is allowed to do sorting based on KSCLP. Is it not a malpractice recommending two different standards based on altogether different principle and use it for self advantage. Are they not misleading the Kannada people, people of Karnataka and the Government of Karnataka. If Character encoding (KSCLP) is the most suitable for Kannada Language processing, why the same was not recommended for Unicode. Is it not a wonder? KGP : We have never came out with confusion, instead we are still using ISCII for storage in Nudi to maintain the National standards, where as design of ISCII never solves the sorting problems of Kannada so for sorting, searching and other language processing we are using KSCLP as the INTERMEDIET CODE. and also as the govt. standard says "WE CAN NOT CHANGE OUR LANGUAGE RULES TO SUITE THE TECHNOLOGY, INSTEAD TECHNOLOGY HAS TO BE CHANGED TO SUIT THE LANGUAGE" and KSCLP is the best example for this. its true that KSCLP is most suitable for Kannada language processing, but since "wrong standards which were in ISCII, is also copied to Unicode" ( Its Realy a wonder ) and now consortium cannot modify the previous standard, the KSCLP recommended by KGP is not accepted by Unicode consortium. Anbarasan : You people are playing a dirty game by combining a dirty wordprocessor and dirty input interface and confuse the concerned Govt officials and journalist by false claims. Wherein, ISCII storage facility is provided only in the NUDI wordprocessor, while input interface of NUDI facilitates storing glyphs. Simillary, when you people claim Nudi is having sorting facility, can NUDI facilitate sorting in all application software where sorting facility for English is available. Definitely NO. Then why you people are misleading everyone by saying NUDI is having sorting facility. When NUDI is used as a keyboard interface with any off-the-shelf application for example say MS Word, the storage is still glyphs not ISCII as you are claiming. By making this kind of blind statements, you are also exposing your malpractice. It is known for every one, who is involved with standards that the purpose of standard encoding is not solving the sorting problems but to achieve linguistic analysis (refer Unicode). To achieve sorting, a separate table needs to be maintained. So, a table designed to handle sorting issue can't be called as a standard for a language. Then why you people claim KSCLP(which is designed for sorting) as a standard for Kannada and recommend to Unicode consortium. Have you ever submited your KSCLP standard to MCIT or BIS for their consideration as a standard for Kannada. Let KSCLP be a most suitable standard for Kannada, when KGP has submitted the KSCLP proposed to Unicode consortium? through whom? what is the reference? who has represented KGP?, who has attended the Unicode consortium Meeting? why the same was not sent to Karnataka Government to forward the same? is that KGP has submitted the proposal directly to Unicode Consortium to project itself. Which is the Govt order you are referring. Don't quote anything off the air, substantiate all your claims with appropriate reference/results. If ISCII is a wrong standard, as you pointed out, the same wrong standard is also copied into Unicode. How dare you people are hiding the very fact that you people have prepared documentation for the same wrong Unicode and sent to Unicode consortium for its inclusion. It is to be noted that KSCLP is based on pure consonant approach where the Consonant and vowel combines (it also contains vowel signs or mathras, which is the secondary symbol of the vowels. For NLP the text is expected to be based on the Vowels and Consonants. For sorting, it is expected to be based on Vowel signs. Can the same text be available in two different encodings.) whereas ISCII/Unicode is based on vowelised consonant where the vowelised consonant joins with the mathras to form vowelconsonants (the vowels don't join with the consonants). Afterall KSCLP can be used only for sorting not NLP, which is based on the vowels and consonants. In KSCLP mathras are used to form vowelconsonants. Why you people claim both (KSCLP and Unicode) as standard. ----------------------------------------------------------------------------------------------------------- Anbarasan : Let me focus on, how ambiguously they interpret the Language, which resulted in today's anarchy. Leave alone the complexities of script composition, Kannada has one special interpretation of consonant 'r' as in Karnataka when written in Kannada. Which is a most commonly used form of 'r'. The so called experts, instead of handling the complexity of 'r' in the software have introduced it as one of the symbol in the standards announced for Kannada Keyboard (reference Karnataka G.O sa am ka e 70 kaa 99 dated 4-2-1999). In this standard, 47 necessary Kannada characters and 4 symbols are listed for modern Kannada language issued by the secretariat of Kannada and Culture. KGP : The keyboard layout is designed by our experts is to suit all sorts of end users such as the users who are familier with using the Kanglish keyboard in Baraha, Typewriter users, KP Rao layout users, and the DOE layout users. After a discussion it is found that DOE layout is most horrible which is very difficult to learn and the number of keystrokes are more. Kanglish layout in Baraha is offcource easy for Kanglish users but it will be difficult for the users who dont know english, ( A user has to learn english to work with Kannada software Baraha ) and offcource it is not a Kannada keyboard layout its a standard English Keyboard. KP Rao layout is most suitable to all ( Even for those who are using Baraha ) and is very easy to lean ( Its proved ). So KGP finaly came out with KP Rao Keyboard layout with some some small changes which were recomonded by expers. Anbarasan : You have not answered the basic question of why the dual interpretation of 'r' is included in the keyboard standard as separate key. I am interested in evolving the best of the features for a standard as such, can you publish your findings on Inscript keyboard, let people know how horrible is DOE keyboard!. Without any substantiable study or findings and without disclosing any such study if at all you have carried out, no one will buy your statements. "Discuss and discard" is the way you people have evolved all the standards without any scientific study or implementation. How your keyboard is proved over others, any sensible debate/discussions needs scientific findings. As you cry for the heavenliness of the development you made, can you point out the discussion forums/e-groups/details on the committees who have discussed/studied/proved the greatness of your standards. Can you at least point out any RFC for these developments. Or at least can you list out the design principles of the standards, in my argument, you people didn't have any design principles either for keyboard layout design or Font design or prescribed minimum feature for Kannada software. When Baraha input method can be used only by those who know English as you point out, How come KP Rao keyboard can be used without learning English. Afterall, the Kannada letters in the KP Rao keyboard layout were mapped based on the English letters. The fact is, you people wanted to take advantage of default English keyboard to learn / remember the Kannada keys by foregoing the advantage of designing a keyboard based on scientific study like frequency analysis and linguistic analysis. ----------------------------------------------------------------------------------------------------------- Anbarasan : Can any one list out the ten features that KGP has provided with NUDI as claimed by the Specific Group. NUDI, purported to be the benchmark software has been developed with non-standard fonts like English numerals, bi-lingual fonts, No conversion utilities. KGP : Font with English numerals can not be a non standard font since portabality will be there. It is just provided for the convience of user. When talking about Nudi its not a full fledged word Processor. It is a Keyboard driver which works for layout specified by Govt. Of Karnataka, and some fonts with Govt standards. Nudi ( Latest is 3.0 Release 2 ) comes with many features as fallows. - Sorting is provided as per the "Kannada Sahitya" which is there in none of other Kannada Softwares which were only developed for DTP operators. - SDK is provided with conversion functions from and to all types of codes like KSCLP, ISCII, Bi-Lingual Glyph, Monolinugual glyph, in-built keyboard engine which can be used by any developers to develop Kannada applications "which are not only meant for DTP operators". -Template files given for MS-Word and MS-Excel ( available in Release 2 ) which allows to sort search and to use many other features which are available in MS-Word, MS-Excel. Anbarasan : Nobody accept NUDI as a software, it crudely provides input interface that's all. It is not even a driver as claimed by you. What is the Govt standard? Govt standard only contains Glyphs for Kannada script, Kannada Numerals, and Punctuation marks Govt never announced any standard with Bi-lingual nature, if anything is there, you would have given reference to that. In the absence of any standard for Bi-lingual fonts, don't claim that NUDI comes with Government standard fonts and a software based on a standard has to follow the standards. You people could have added additional features but not the fonts based on the proprietory encoding. You people have implemented bi-lingual fonts to establish monopoly by taking undue advantage by implementing this non-standard font in the e-governance projects. It is sure that this is going to messup the data while migrating to another encoding say Unicode. As you have copied the methodology of our software which were given for testing, evaluation and certification. You have copied the methodology of providing sorting facility in MS Word in NUDI, your claim of no software were developed with sorting is false and intentional to defame and gain undue advantage and fame for yourself. The proof of our software SURABHI having sorting facility is the test report given by the KGP. "Standardisation is somethig that has to be imposed" says Dr. Pavanaja in the interview quoted elsewhere in this mail. You people must understand that standards can't be imposed. You people can play the dirty game only to gain monopoly in the Kannada software field by introducing the non-standard fonts like Bi-lingual fonts as you have introduced with NUDI and in the e-governance projects of Government of Karnataka. It is sure that your monopoly act would only result in bottleneck for Kannada in further development. You are still accusing the developer (you are trying to be out of the developer community) while still following the same age old methodology. It is a unfair game you people have just started. Atlast, you are accepting you are not a developer but you are a tinkerer. That is why you have taken a sample code and tinkered around to put UI in Kannada and claimed you have developed the controversial NUDI. Do you people have developed the NUDI software without funding from Government. Even after receiving fund from the Government you people are conveniently hiding the fact that NUDI is funded by the Government. It is also true that you people are distributing NUDI for Rs.100.00 per copy (while spending only 20% of it, it means that you are making 80% profit) without any training or support. My accusation is that you people are getting funds from the Government and try to build your foundations for future business prospects by monopolising Kannada software industry with the help of the officials of Directorate of Information Technology. Dr. Pavanaja's Visvakannada Softech is the example of this type. ----------------------------------------------------------------------------------------------------------- Anbarasan : Kannada has become a victim of jealousy KGP. I wish Kannada with its outstanding 2300 years of survival and very rich literary contribution has to face this challenge and expose the erratic management of Kannada standards by KGP to maintain its sustained growth and enthronement on digital media. With my everlasting love and creed towards Kannada Kasthuri I have taken your precious time. I welcome your views on this subject. KGP : Kannada was a victim of jealousy Kannada Software developers who developed keyboard drivers with some ( Beautiful fontS ) just to attract DTP operators and make money they were never thought of developing some standards for glyph and storage ( if they do this they will loose customers ). Now there game is end!. THANK GOD FINALLY SOME STANDARDS HAS COME. I wish Kannada with its outstanding 2300 years of survival and very rich literary contribution has to face this challenge and support standards provided by Govt. Of. Karnataka. With my everlasting love and creed towards Kannada I welcome your comments on this subject. Anbarasan : Your accusation on the Kannada software developers that the developers never contributed in developing standards is like a daylight robbery. It tentamounts to show the most vulnerable ungrateful re-course on those who have spent their everything for the noble cause of beloved languages on digital media. After the committee on standardising glyphs and codes have submitted the draft version, the same was sent to the developers for their comments. Developers of SURABHI, BARAHA, SHREE LIPI have contributed details on the usability of codes, organising the glyphs etc. The present standard is the witness for how much of the developers comments have helped in evolving the standard. By hiding their contributions, you are exposing your integrity (which is being questioned). It is unfortunate that the Government is sponsoring your activities and colluded with you people. I thought you people only copy the methodology and technolgy invented by others but your reply proves you are copying even the writings (feelings). N. ANBARASAN email : ar...@bg... , phone : +91-080-3386167. |
From: Tapan S. P. <ta...@ya...> - 2002-11-17 02:19:52
|
This is 100% my fault not to have done this. I will do it within the week. Sorry! -- Tapan On Thu, 14 Nov 2002 14:58:50 +0530 Mahesh T Pai <pai...@vs...> wrote: > Dr. U.B. Pavanaja wrote: > > > I should have expalined what I meant. I had explained this in the > > Sep.15-16 workshop at Blore. Let me explain again. > > Somebody should take the pains of putting up the papers presented at > workshop on the net. I had suggested this earlier to the people who > were sending out the invitations. That will help the guys who could > not attend the w'shp get a feel of the issues. > > > I was asking for such a provsision in OTF specifications. Probably, > > if such a provision is made in OTF specs, then the problem faced by > > Malayalam in case of chillus might be solved. > > The sensible way out is to include the chillus in the unicode > standard. This is already recommended, but not yet accepted, as I > understand it. > > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: To learn the basics of securing > your web site with SSL, click here to get a FREE TRIAL of a Thawte > Server Certificate: http://www.gothawte.com/rd524.html > _______________________________________________ > Indic-computing-standards mailing list > http://indic-computing.sourceforge.net/ > Ind...@li... > https://lists.sourceforge.net/lists/listinfo/indic-computing-standards > [Other Indic-Computing mailing lists: -users, -devel, -announce] |
From: Mahesh T P. <pai...@vs...> - 2002-11-14 10:04:02
|
Dr. U.B. Pavanaja wrote: > I should have expalined what I meant. I had explained this in the > Sep.15-16 workshop at Blore. Let me explain again. Somebody should take the pains of putting up the papers presented at workshop on the net. I had suggested this earlier to the people who were sending out the invitations. That will help the guys who could not attend the w'shp get a feel of the issues. > I was asking for such a provsision in OTF specifications. Probably, > if such a provision is made in OTF specs, then the problem faced by > Malayalam in case of chillus might be solved. The sensible way out is to include the chillus in the unicode standard. This is already recommended, but not yet accepted, as I understand it. |
From: Dr. U.B. P. <pav...@vi...> - 2002-11-14 04:25:18
|
------- Forwarded message follows ------- From: "Dr. U.B. Pavanaja" <pav...@vi...> To: Keyur Shroff <key...@ya...> Date sent: Thu, 14 Nov 2002 09:51:22 +0530 Subject: Re: [Indic-computing-standards] Re: Malayalam Half-U: how Priority: normal > > --- "Dr. U.B. Pavanaja" <pav...@vi...> wrote: > > From these discussions I can infer one thing: We need a > > mechanism of choosing one of the many possible display forms for a > > particular combination. > > > > We are having a similar requirement for Kannada for the case of > > "arkavattu" (reph) and "half ra". Both forms of display are > > possible and both are correct. I had mentioned this to the people > > responsible for OpenType specifications of Indic scripts. > > Currently they don't have any plans to do this changes. > > Can't it be done using Zero Width Joiner (U+200D)? ZWJ is used to > produce half forms of consonant/ligature in Indic scripts. > > (Ra Halant ZWJ) sequence will produce desired half form of Ra. I should have expalined what I meant. I had explained this in the Sep.15-16 workshop at Blore. Let me explain again. In Kannada, the combination of "ra + halant + <any consonant other than ra>" can be displayed in two forms - 1) With the second consonant in full form followed by the arkavattu (reph) character. This method has come from Samskrit and not original to Kannada. Nowadays majority people use this form. 2) With the full form of "ra" followed by the half form (vattu form, below base form) of the second consonant. This is original to Kannada. All combinations of consonant + halant + consonat use this method. In our Nudi keyboard there is a provision to select any one of the form at our wish. In case of OTF, the display form is decided by the logic put into the font (GPOS, GSUB, etc). We can not decide on the display form based on the keyboard input. I was asking for such a provsision in OTF specifications. Probably, if such a provision is made in OTF specs, then the problem faced by Malayalam in case of chillus might be solved. I am not very sure of this. May be some Malayalee can throw light. > > > > Another point I would like mention here: The sorting rule in > > Unicode has got nothing to do with the character code pages. They > > are different. Unicode has two charts -character chart and the > > collation table. Details of collation are available at > > www.unicode.org/tr10 > > Yes, separate algorithm is required. Otherwise it will lead to wrong > sorting sequence. I'll try to explain this by giving simple example. I fully agree. The collation table has a section for every language and not for the script. This helps for Hindi, Samskrit, Marathi etc who have the same script, but have different sorting rules. We have done similar in case of Kannada. We use ISCII for storing the text. There is a provision in Nudi to save as ISCII. For sorting we follow the pure consonant approach by knocking off the implicit "a" in every consonant. That means we consider the consonants as "k, kh, g, gh" rathar than "ka, kha, ga, gha". We have arrived at an encoding table for sorting purpose called KSCLP (Kannada Script Code for Language Processing). The problem of half- consonants (as in rajkumar and rajakumar) is solved by this approach. Rgds, Pavanaja-------------------------------------------- --------- 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 ------- End of forwarded message ------------------- ----------------------------------------- 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 |
From: Baiju M <ba...@fr...> - 2002-11-13 10:26:37
|
Dr. U.B Pavanaja wrote : >>From these discussions I can infer one thing: We need a > mechanism of choosing one of the many possible display forms for > a particular combination. > > We are having a similar requirement for Kannada for the case of > "arkavattu" (reph) and "half ra". Both forms of display are > possible and both are correct. I had mentioned this to the > people responsible for OpenType specifications of Indic scripts. > Currently they don't have any plans to do this changes. Who? Microsoft? Dont depend upon such propriatery software companies. Come to free softwares, and do it yourself in Pango,Yudit,Qt etc. A similar problem may arise for Malayalam also, but I didnt decided what to do with that yet (We have to consider inter operatibility also). the problem is with RA/RRA and LA/LLA symbols , these pairs are using same symbols but for specific consonats. I think Microsofts approach here is against standards. Anyway we have to dicuss what to do with this. Regards, Baiju M |
From: Keyur S. <key...@ya...> - 2002-11-12 15:10:39
|
--- "Dr. U.B. Pavanaja" <pav...@vi...> wrote: > From these discussions I can infer one thing: We need a > mechanism of choosing one of the many possible display forms for > a particular combination. > > We are having a similar requirement for Kannada for the case of > "arkavattu" (reph) and "half ra". Both forms of display are > possible and both are correct. I had mentioned this to the > people responsible for OpenType specifications of Indic scripts. > Currently they don't have any plans to do this changes. Can't it be done using Zero Width Joiner (U+200D)? ZWJ is used to produce half forms of consonant/ligature in Indic scripts. (Ra Halant ZWJ) sequence will produce desired half form of Ra. > > Another point I would like mention here: The sorting rule in > Unicode has got nothing to do with the character code pages. > They are different. Unicode has two charts -character chart and > the collation table. Details of collation are available at > www.unicode.org/tr10 Yes, separate algorithm is required. Otherwise it will lead to wrong sorting sequence. I'll try to explain this by giving simple example. Consider the following sequences: 1. Ka Nukta 2. Qa 3. Ka Halant 4. Kha 5. Ka If you simply sort these sequences acording to their relative position in Unicode chart (i.e., simple string matching operation), you get the following sequence. 1) Ka 2) Ka Nukta 3) Ka Halant 4) Kha 5) Qa Clearly, this is wrong because "Ka Nukta" is equivallent to "Qa" in rendering. Correct order is as below: (1) Ka (2) Ka Nukta (or Qa) (3) Qa (or Ka Nukta) (4) Ka Halant (5) Kha In short, normalization is needed before we sort the sequences. I am still not happy about the position of "Ka Halant" in the sorting order. Conceptually it should precede Ka because Ka is formed after adding vowel A to pure form of Ka. So in sorting also pure Ka should precede full Ka. - Keyur __________________________________________________ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2 |
From: Dr. U.B. P. <pav...@vi...> - 2002-11-12 12:39:32
|
From these discussions I can infer one thing: We need a mechanism of choosing one of the many possible display forms for a particular combination. We are having a similar requirement for Kannada for the case of "arkavattu" (reph) and "half ra". Both forms of display are possible and both are correct. I had mentioned this to the people responsible for OpenType specifications of Indic scripts. Currently they don't have any plans to do this changes. Another point I would like mention here: The sorting rule in Unicode has got nothing to do with the character code pages. They are different. Unicode has two charts -character chart and the collation table. Details of collation are available at www.unicode.org/tr10 Rgds, -Pavanaja > > In Malayalam (iso639-2 language code : mal) there are 37 > 'vyanchanangal' (consonants). All these consonants are usually > pronounced with a support of 'swaram' (vowel) sound A [U0D06]. The > pure forms of consonats is writing with a 'chandrakkala' (virama > [U0D4D]) above the consonant. While pronouncing the pure forms of > consonants there should be clear sound of vowel U [U0D09]. Some > consonants another form, which is called 'chillu'. A 'chillu' is a > consonant which do not require any vowel support to prounce. It is > writing with a vowel sign U [U0D41] and 'chandrakkala' (virama > [U0D4D]) above that. Infact Malayalam has seperate 'lipi' (script) for > 7 chillu forms of consonants which are widely using in Malayalam. > Since we have seperate scripts for most of the chillus, in writing > system we almost stopped writing chillu forms of other consonants > (which is rarely occurs) as explained above. Eventhough still you can > see some texts written in this style. Antoine said this is half form > of u that is the 'samvrutokaram' of U [U0D09] (infact 'samvrutokaram' > has a sound of A and U, so the 'virama', 'vowel sign U' and > 'combination of this two' is used in diffnerent places and texts, some > lingusits says that 'samvrutokaram' has a vowel value.) Now many are > writing consonants with virama for chillu forms of other consonats One > example is that Antoine said : U0D15 + U0D41 + U0D4D (ka, u, virama). > So internaly a chillu can be represented with unicode character > sequence like this : <consonant> + <vowel sign U [U0D41]> + <virama > [U0D4D]>. Then you can render 7 chillu forms with correct script. I > will explain how to do this below. For making inputting very easy you > can use the inscript keyboard layout standardised by kerala govt. (See > they just added chillus to original inscript keyboard layout at > appropriate positions, they considered the frequency of occurense of > this chillu forms. I will explain the drawback of this keyboard layout > below.) > > The proposal for inclusion of scripts of chillus forms of consonants > as basic characters should not be accepted by Unicode consortium. > (This is going to be submitted (or already submitted?) by Ministry of > Information Technology (Govt. of India), a member of Unicode > consortium) The prosal includeds some other things, in my opinion > those changes should be accepted. > > Now I will explain howto represent chillu forms of consonants in > unicode sequence. An important thing to be noticed is that two (or > more) consonants may have same script for their chillu forms. And its > pronouciation is also same. Though it should be represented in correct > unicode sequence. Script for chillu forms of both RA [U0D30] and RRA > [U0D31] are same. Similary script for chillu forms of both LLA [U0D33] > and LLLA [U0D34] are same. Other consonants which has chillu forms > with unique scripts are NNA [U0D23], NA [U0D28] and LA [U0D32]. > > Why 5 scripts of 7 chillus forms of consonants should not be included > in unicode ? > ---------------------------------------------------------------------- > ---------------- > > * The basic reason is that those 5 'lipi' (script) are not part of > Malayalam 'Aksharamala' > (character set). instead these are chillus only (See it is not a > 'koottaksharam' > (consonanat conjunct) ) > > Sopporting reasons :- > > + As I explained above two (or more) consonants is using same script > for > their chillu > forms. So if these 'simple shapes' are going to be part of > unicode > hard encoding of > hard encoding of chillus wll be impossible. If someone input in > correct unicode seqence > the renderer should render those characters, this will make more > problems. > > + Sorting rule cannot impliment effectively. > > Inscript keyboard layout problems :- > ------------------------------------- > > I think the drawback of new inscript keyboard layout standardised > by > Kerala govt. > will be clear from the above discussion. Eventhough the layout can be > accepted with practical consideration. Since we are only using those > scripts, we can compose any character sequence to keys allocated to > them. Here the choice is coiming in between RA [U0D30] and RRA [U0D31] > chillu and LLA [U0D33] and LLLA [U0D34]. By considering the accent of > pronounciation and freequency of occurense of these chillus, you can > choose RRA [U0D31] and LLA [U0D33]. Infact this only can be decided by > cosidering the words. For example :- RA [U0D30] + vowel sign U [U0D41] > + virama [U0D4D] is correct in words : neer - neere (water), avar - > avare (they), aar - aare (who) etc. > > and RRA [U0D31] + vowel sign U [U0D41] + virama [U0D4D] is correct in > words : car - caRe (car), kiNar - kiNaRe (well), sir - saRe (sir) etc. > > So if someone input the other correct sequences (without using those > keys), it should render properly. > > P.S : please reply to un...@un... > > Regards, > Baiju M > -- > http://baijum81.tripod.com > > > --- In unicode@y..., Antoine LECA <Antoine10646@l...> wrote: > > Hi folks, > > > > A problem was signaled in the Microsoft VOLT mailing list (this list > > should be dedicated to typographic, but it appears that it deals > > more with Indic scripts, because VOLT is the MS tool to use to > > encode OpenType informations in a font, which in turn is required to > > display Indic scripts on Windows.) > > > > The problem deals with Malayalam half-u. An user signaled as an > > error the fact that Uniscribe displays a dotted circle in the middle > > of a Malayalam half-u. He wrote > > U+0D15 U+0D41 U+0D4D (ka, u, virama) > > and Uniscribe displayed (in reformed style) the ku syllable, then a > > dotted circle, then a virama sign hanging alone. > > > > Of course, the problem is that Uniscribe expects virama to come only > > after consonants, so it displayed it as an error. But I believe the > > misunderstood hides a real problem: how can be displayed the half-u. > > Hence I am coming here to see what the gurus believe about this. > > > > To help you, I have done some researches. Here is what I have found. > > > > First, the phonetic reality: the root is when a word ends with > > halanta (virama); while in other languages, this "kills" the > > a-sound, in Malayalam it rather replaces it with the half-u sound, > > particularly when the consonant is a conjunct. This is for example > > described in the ISO 15919 standard, available with detailed > > explanations at Dr Anthony P. Stone site, > > <URL:http://homepage.ntlworld.com/stone-catend/trind.htm> > > > > According to Varamozhi (a site well informed about Malayalam), > > <URL:http://varamozhi.sourceforge.net/varamozhi-doc/varamozhi-6.html > > > when it comes to representation, there exists differing writing > > "styles" contemplating this single phonetic reality; in North > > Kerala, usage is to write the halanta sign in place, and Done! > > Obviously, this is very much in line with the other scripts. > > > > However, in South Kerala, as Mr. Cibu said, usage is to write the > > halanta sign as well as to show the matra for the u vowel. While it > > is said that this latter usage occurs with the reformed style, I > > have seen examples with the traditional style as well (although this > > is from a book printed in Madras, so it might be wrong.) Obviously, > > the user of Uniscribe intended to display this combination, which to > > him is the normal way to display a word, when it ends with halanta! > > > > Knowing that, we can now notice that Unicode has a note under > > Malayalam virama (U+0D4D), saying it is the same as Malayalam > > half-u. To me, this means that under Unicode, the half-u is supposed > > to *not* be specifically encoded, and only the usage from North > > Kerala is supposed to be followed. > > > > Other relevant informations: ISCII-91 seems mute about the subject, > > and THE CDAC products (like iLeap) seems unable to render the half-u > > in Malayalam (until one "cheats" using the INV pseudo-consonant.) > > > > It is too late to discuss the pros and cons of the choice of > > Unicode, back in 1992 (probably, they chose to ease as far as > > possible the unification of encoding, in order to ease sorting and > > similar tasks.) Now, the problem is, if someone wants to > > specifically encode the showing of the u matra, in a context (like > > is Uniscribe) where both usages from North and South Kerala could be > > intended, how should it be done? It seems rather natural to use then > > the combination > > U+0D41 U+0D4D, > > following the precedent established in Unicode 3.1 (IIRC) for the > > modern Bengali A and E initial vowels (from English borrowed words), > > which are written as Bengali A or E, followed by virama then ya > > (hence a exception to the rule virama may only follow a consonant.) > > > > Are the gurus here OK with this "solution"? > > > > Can it be "sanctified", for example with the inclusion of the > > adequate words in some revision of Unicode? > > > > > > If this is agreed, when dealing with other aspects than rendering, > > people should take in account this, and effectively ignore the > > U+0D41 when followed by U+0D4D, when the task is about searching, > > sorting, etc. While this is a nuisance, it does not appear > > completely prohibitive to me. But I admit I have not think a lot > > about the consequences of allowing such "presentation encoding." > > > > > > Regards, > > Antoine > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Indic-computing-standards mailing list > http://indic-computing.sourceforge.net/ > Ind...@li... > https://lists.sourceforge.net/lists/listinfo/indic-computing-standards > [Other Indic-Computing mailing lists: -users, -devel, -announce] > > ----------------------------------------------------- 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 |
From: Bharateeya-OpenOffice <bha...@nc...> - 2002-11-12 11:21:39
|
Hi All, We are a team from NCST, Bangalore, working on the localizaon and internationalization of OpenOffice.org in Indian Languages. We have localized OpenOffice.org in Hindi on Windows and Linux, and in Tamil on Windows. We have also enabled Complex Text Layout support for all main Indian languages as well as other Internationalization features like Indian currency and calendar translations in Hindi and Tamil, on Windows. Localization work in Tamil on Linux, as well as Complex Text Layout support and other Internationalization aspects on Linux OO.o is going on. Refer to our site http://www.ncb.ernet.in/bharateeyaoo for more information on our work. Our work has been recognized by OpenOffice.org Ref: http://l10n.openoffice.org/localization_responsibilities.html and granted copyright approval. Ref: http://www.openoffice.org/copyright/copyrightapproved.html We have uploaded some screenshots of the localized applications on both Windows and Linux, and the localized binaries for Hindi and Tamil on Windows are available for a free download. The localized binaries on Linux will be uploaded soon. We have a requirement for OT fonts in Tamil as well as in other languages for our localization work on Linux. Would anyone help us in this direction? We also welcome any suggestions, comments and feedback about our work. Thank you and Best regards, BharateeyaOO.o Team ------------------------------------------------------------ |Bhupesh Koli <bh...@nc...>| |Shikha G Pillai <sh...@nc...> | |Velmani N <ve...@nc...>| ------------------------------------------------------------ |BharateeyaOO.o - Indian Language support in OpenOffice.org| |National Centre for Software Technology | |68, Electronics City, Bangalore - 561229 | |Tel: +91 80 852 3300/0239 | |Web: http://www.ncb.ernet.in/bharateeyaoo | |Email: bha...@nc... | ------------------------------------------------------------ |
From: Baiju M <ba...@fr...> - 2002-11-12 10:32:03
|
> While pronouncing the pure forms of consonants > there should be > clear sound of vowel U [U0D09] here one correction : there should not be Regards, Baiju M |
From: Baiju M <ba...@fr...> - 2002-11-12 09:32:44
|
In Malayalam (iso639-2 language code : mal) there are 37 'vyanchanangal' (consonants). All these consonants are usually pronounced with a support of 'swaram' (vowel) sound A [U0D06]. The pure forms of consonats is writing with a 'chandrakkala' (virama [U0D4D]) above the consonant. While pronouncing the pure forms of consonants there should be clear sound of vowel U [U0D09]. Some consonants another form, which is called 'chillu'. A 'chillu' is a consonant which do not require any vowel support to prounce. It is writing with a vowel sign U [U0D41] and 'chandrakkala' (virama [U0D4D]) above that. Infact Malayalam has seperate 'lipi' (script) for 7 chillu forms of consonants which are widely using in Malayalam. Since we have seperate scripts for most of the chillus, in writing system we almost stopped writing chillu forms of other consonants (which is rarely occurs) as explained above. Eventhough still you can see some texts written in this style. Antoine said this is half form of u that is the 'samvrutokaram' of U [U0D09] (infact 'samvrutokaram' has a sound of A and U, so the 'virama', 'vowel sign U' and 'combination of this two' is used in diffnerent places and texts, some lingusits says that 'samvrutokaram' has a vowel value.) Now many are writing consonants with virama for chillu forms of other consonats One example is that Antoine said : U0D15 + U0D41 + U0D4D (ka, u, virama). So internaly a chillu can be represented with unicode character sequence like this : <consonant> + <vowel sign U [U0D41]> + <virama [U0D4D]>. Then you can render 7 chillu forms with correct script. I will explain how to do this below. For making inputting very easy you can use the inscript keyboard layout standardised by kerala govt. (See they just added chillus to original inscript keyboard layout at appropriate positions, they considered the frequency of occurense of this chillu forms. I will explain the drawback of this keyboard layout below.) The proposal for inclusion of scripts of chillus forms of consonants as basic characters should not be accepted by Unicode consortium. (This is going to be submitted (or already submitted?) by Ministry of Information Technology (Govt. of India), a member of Unicode consortium) The prosal includeds some other things, in my opinion those changes should be accepted. Now I will explain howto represent chillu forms of consonants in unicode sequence. An important thing to be noticed is that two (or more) consonants may have same script for their chillu forms. And its pronouciation is also same. Though it should be represented in correct unicode sequence. Script for chillu forms of both RA [U0D30] and RRA [U0D31] are same. Similary script for chillu forms of both LLA [U0D33] and LLLA [U0D34] are same. Other consonants which has chillu forms with unique scripts are NNA [U0D23], NA [U0D28] and LA [U0D32]. Why 5 scripts of 7 chillus forms of consonants should not be included in unicode ? -------------------------------------------------------------------------------------- * The basic reason is that those 5 'lipi' (script) are not part of Malayalam 'Aksharamala' (character set). instead these are chillus only (See it is not a 'koottaksharam' (consonanat conjunct) ) Sopporting reasons :- + As I explained above two (or more) consonants is using same script for their chillu forms. So if these 'simple shapes' are going to be part of unicode hard encoding of hard encoding of chillus wll be impossible. If someone input in correct unicode seqence the renderer should render those characters, this will make more problems. + Sorting rule cannot impliment effectively. Inscript keyboard layout problems :- ------------------------------------- I think the drawback of new inscript keyboard layout standardised by Kerala govt. will be clear from the above discussion. Eventhough the layout can be accepted with practical consideration. Since we are only using those scripts, we can compose any character sequence to keys allocated to them. Here the choice is coiming in between RA [U0D30] and RRA [U0D31] chillu and LLA [U0D33] and LLLA [U0D34]. By considering the accent of pronounciation and freequency of occurense of these chillus, you can choose RRA [U0D31] and LLA [U0D33]. Infact this only can be decided by cosidering the words. For example :- RA [U0D30] + vowel sign U [U0D41] + virama [U0D4D] is correct in words : neer - neere (water), avar - avare (they), aar - aare (who) etc. and RRA [U0D31] + vowel sign U [U0D41] + virama [U0D4D] is correct in words : car - caRe (car), kiNar - kiNaRe (well), sir - saRe (sir) etc. So if someone input the other correct sequences (without using those keys), it should render properly. P.S : please reply to un...@un... Regards, Baiju M -- http://baijum81.tripod.com --- In unicode@y..., Antoine LECA <Antoine10646@l...> wrote: > Hi folks, > > A problem was signaled in the Microsoft VOLT mailing list (this list > should be dedicated to typographic, but it appears that it deals > more with Indic scripts, because VOLT is the MS tool to use to encode > OpenType informations in a font, which in turn is required to display > Indic scripts on Windows.) > > The problem deals with Malayalam half-u. An user signaled as an error > the fact that Uniscribe displays a dotted circle in the middle of a > Malayalam half-u. He wrote > U+0D15 U+0D41 U+0D4D (ka, u, virama) > and Uniscribe displayed (in reformed style) the ku syllable, then a > dotted circle, then a virama sign hanging alone. > > Of course, the problem is that Uniscribe expects virama to come only > after consonants, so it displayed it as an error. But I believe the > misunderstood hides a real problem: how can be displayed the half-u. > Hence I am coming here to see what the gurus believe about this. > > To help you, I have done some researches. Here is what I have found. > > First, the phonetic reality: the root is when a word ends with halanta > (virama); while in other languages, this "kills" the a-sound, in > Malayalam it rather replaces it with the half-u sound, particularly > when the consonant is a conjunct. > This is for example described in the ISO 15919 standard, available > with detailed explanations at Dr Anthony P. Stone site, > <URL:http://homepage.ntlworld.com/stone-catend/trind.htm> > > According to Varamozhi (a site well informed about Malayalam), > <URL:http://varamozhi.sourceforge.net/varamozhi-doc/varamozhi-6.html> > when it comes to representation, there exists differing writing > "styles" contemplating this single phonetic reality; in North > Kerala, usage is to write the halanta sign in place, and Done! > Obviously, this is very much in line with the other scripts. > > However, in South Kerala, as Mr. Cibu said, usage is to write the > halanta sign as well as to show the matra for the u vowel. > While it is said that this latter usage occurs with the reformed > style, I have seen examples with the traditional style as well > (although this is from a book printed in Madras, so it might be wrong.) > Obviously, the user of Uniscribe intended to display this combination, > which to him is the normal way to display a word, when it ends with > halanta! > > Knowing that, we can now notice that Unicode has a note under Malayalam > virama (U+0D4D), saying it is the same as Malayalam half-u. To me, this > means that under Unicode, the half-u is supposed to *not* be specifically > encoded, and only the usage from North Kerala is supposed to be followed. > > Other relevant informations: ISCII-91 seems mute about the subject, > and THE CDAC products (like iLeap) seems unable to render the half-u > in Malayalam (until one "cheats" using the INV pseudo-consonant.) > > It is too late to discuss the pros and cons of the choice of Unicode, > back in 1992 (probably, they chose to ease as far as possible the > unification of encoding, in order to ease sorting and similar tasks.) > Now, the problem is, if someone wants to specifically encode the > showing of the u matra, in a context (like is Uniscribe) where both > usages from North and South Kerala could be intended, how should it be > done? It seems rather natural to use then the combination > U+0D41 U+0D4D, > following the precedent established in Unicode 3.1 (IIRC) for the modern > Bengali A and E initial vowels (from English borrowed words), which are > written as Bengali A or E, followed by virama then ya (hence a exception > to the rule virama may only follow a consonant.) > > Are the gurus here OK with this "solution"? > > Can it be "sanctified", for example with the inclusion of the adequate > words in some revision of Unicode? > > > If this is agreed, when dealing with other aspects than rendering, > people should take in account this, and effectively ignore the U+0D41 > when followed by U+0D4D, when the task is about searching, sorting, etc. > While this is a nuisance, it does not appear completely prohibitive to > me. But I admit I have not think a lot about the consequences of > allowing such "presentation encoding." > > > Regards, > Antoine |
From: <ar...@bg...> - 2002-11-08 12:19:53
|
ANARCHY OF KANNADA STANDARDS IN IT. Historically, standards were never forced or defined without thorough evaluation to analyse the pros/cons and implementations on trial basis. Standards evolve and becomes mandatory for a measure of quality assurance and building consensus among all the concerned regarding norms for compliance and criteria for certification. How the goals of standardisation could be achieved by adopting controversial methods in evolving standard glyph set / font / encoding for Kannada. Since, topic of this mail is around code set - about its usefulness and interoperability. I take an example of PC character set. How this character set has become acceptable to all PC manufacturers, OS developers, application developers etc, inspite of the provision to alter or change the character generator to define ones choice of character set. The character set defined by IBM was accepted by the whole Industry for the sake of interoperability. Interoperability is an important criteria for a standard to succeed. Well. Is there interoperability in the standards of Kannada for computers. Introduction Often Indian Languages complexities really complicates the so called expert of the field and influence the officials to favour their idealism and get funded their efforts and confuse those end users, who are already in dilemma say a typist - a government employee who is at the receiving end of the resultant half baked potatoes. You may be wondering what relevance this mail has to you. As you are interested in Indian Language computing, I thought it would be of some interest to you. Is there any single product available for Indian Languages, which can talk of some technological marvel. No. It is to be noted that every Indian Language is now implemented just by hacking the fonts. Even the hacking of font is not made properly in many instances. I take the example of Kannada to go into the details of "How Kannada Language / Script / Glyph / Font / Code is being handled for standardisation". I have included Language, Script, Glyph, Font and code just to throw some light on the ambiguities the people concerned have implied in standardising Kannada. Indian Script code standard All the Indian Languages were encoded as ISCII (Indian Script Code for Information Interchange - this often misinterpreted as Indian Standard Code for Information Interchange) based on the script principles of Vowels and Consonants. Hence, this standard has only Signs, Vowels, Vowelconsonants (instead of using of pure consonant, a consonant having an initial vowel in it, which is a base for writing the script and non-use of pure consonant in Devanagari is the reason.), Vowel signs (to differentiate from the vowels in a string and to avoid auto-combining feature of consonant and vowel when a vowel comes in the non-initial position). This principle is also adopted in the Unicode (Which is supposed to be a character encoding) for Indian Languages based on the earlier version of ISCII. Indian Script implementation As the existing OS (except MS Windows 2000 and MS Windows XP) does not have the capability to handle these standards, the enthusiastic developers found a trick of having the glyphs in some useful manner for these languages and handle the combinational complexities at the input level. As this kind of trick was being followed with the MS DOS based DTP softwares prior to MS Windows popularisation, the same trick was followed even for MS Windows for the sake of convertibility and its ease of use. When all the available Indian Language solutions are based on these hack tricks, NO technology is existing on the GUI based operating systems like MS Windows to handle ISCII with the off-the-shelf application software like Office suites. It is this annoying trick which is being followed by the 'Specific Group' for Kannada in standardising and developing NUDI for Kannada while blaming the developers. Why this 'Specific Group' never attempted to invent a technology to handle Kannada efficiently using ISCII on computers for the off-the-shelf applications. I leave it to your guess and further pacifying. Kannada standards Let me focus on, how ambiguously they interpret the Language, which resulted in today's anarchy. Leave alone the complexities of script composition, Kannada has one special interpretation of consonant 'r' as in Karnataka when written in Kannada. Which is a most commonly used form of 'r'. The so called experts, instead of handling the complexity of 'r' in the software have introduced it as one of the symbol in the standards announced for Kannada Keyboard (reference Karnataka G.O sa am ka e 70 kaa 99 dated 4-2-1999). In this standard, 47 necessary Kannada characters and 4 symbols are listed for modern Kannada language issued by the secretariat of Kannada and Culture. When the same Specific Group sent recommendation for Kannada in Unicode to Government of India through Directorate of Information Technology of Government of Karnataka, have left two diacritic marks(part of the above standard), which were recommended for composing Vedic text. But, included a new set of additional characters. Later on, when the Specific Group reached the peak of confusion, came out with another altogether different set of character set as Kannada Standard Code for Language Processing. Strangely, the arguable special symbol for 'r' is left out in this character set. If KSCLP code set is meant for Language processing, then what else the other encodings ISCII/UNICODE etc., do. Does it mean that the Group is not aware of the sorting problems when they submitted the recommendation. Why the Government is insisting on SORTING order as per ISCII when KGP is allowed to do sorting based on KSCLP. Is it not a malpractice recommending two different standards based on altogether different principle and use it for self advantage. Are they not misleading the Kannada people, people of Karnataka and the Government of Karnataka. If Character encoding (KSCLP) is the most suitable for Kannada Language processing, why the same was not recommended for Unicode. Is it not a wonder ? Font Standards Leave apart the Kannada character set, which the Specificd Group handle/suggest/innovate. Let me throw some light on their script handling glyph code standards. To solve the Kannada text portability and its compatibility, the Government of Karnataka have appointed a Committee, which included constituents of Specific Group. The Specific Group has submitted the report recommending a set of Glyphs and Glyph codes and was announced as standard on Nov 1, 2000. The Specific Group has managed to get funding to develop a model software (an input handling software), and the same was developed and announced without even bothering about the minimum features, which were recommended by the same Specific Group. Later on, when a difficulty arose in using their standards for e-governance projects which requires English to be part of the user choice, they had silently included a bi-lingual glyph encoding by making use of the code positions which were spared due to its unusability of nature. I wonder how the Government is promoting the bi-lingual encoding which is based on the codes which are spared while evolving the mono-lingual glyph standard. If the Specified Group decide as they wish, then why the Government appoints committee to standardise glyphs and glyph codes for Kannada. Is it to approve by stamping or to elevate the Specific Group to a level of consultants to Microsoft. Conversion When a document created using KGP recommended Unicode is converted to KSCLP, it will be a lossy conversion resulting into loss of diacritic marks recommended for Vedic texts and 'ru' long vowel and 'ru' long vowel consonants. Similarly, when one tries to convert the text created in mono-lingual encoding into bi-lingual encoding it will result into loss of data. As the diacritic marks were not part of the recommended glyph set but recommended as part of the keyboard standard, any software to be developed as per the prevailing standard, developers are allowed to accommodate the diacritic marks as per their convenience. If such Software are used, it will only result into non-standard, non-compatible font and text will result in non-portable format. How anybody can write a converter utility to convert the texts created with diacritic marks, which are allowed in any vacant codes in any order. This may be the reason why the Specific Group has not attempted to provide a conversion utility for their software NUDI. Keyboard standard It is often argued that the strength of the standardised keyboard lies in the layout being managed within the keys meant for English. English keys are used as reference for the user to remember the keys. However, it is conveniently forgotten the loading of fingers. In the standard Kannada keyboard, left hand is loaded with 15 keys and the right hand is loaded with 11 keys (excluding the punctuation keys). Normally, when a keyboard layout is designed, the frequency analysis of letters and in turn keystrokes are considered. When, language specific encoding standards and keyboard layouts are getting evolved worldwide, it is strange that the Specific Group managed to get attestation from the Government for their unscientific keyboard layout. It is alarming the Group also try to influence the other language groups working in the area of standardisation efforts. NUDI The Specific Group cleverly managed to get the support of the concerned authorities of the Government of Karnataka and made use of the Government machinery to fulfill their whimsical will. As once one amongst the Specific Group was blaming the developers for proprietary glyph encoding "We feel the best solution is to have the storage in ISCII. Other solutions have attempted to tie up the user in their own software solutions". But in reality they have succeeded in announcing their proprietory set of glyphs as standard and have not provided a solution for storage in ISCII for the off-the-shelf applications. It amply proves of their lip service. You may be wondering as who are these friends. They are none other than Dr. U.B Pavanaja, who holds Vishva Kannada Softech, Mr C. V Srinatha Sastry, General Secretary of Kannada Ganaka Parishat, Mr. G. N Narasimha Murthy, Secretary of Kannada Ganaka Parishat (I have not mentioned their attached institutions to maintain the dignity of the Institutions) Now the KGP has tied up the Government users by forcing to use the proprietary non-standard bi-lingual encoding by implementing the e-governance projects with the blessings of Kannada Development Authority and with the support of Directorate of Information Technology which is the controlling and monitoring body of the IT requirements of Government of Karnataka. Can any one list out the ten features that KGP has provided with NUDI as claimed by the Specific Group. NUDI, purported to be the benchmark software has been developed with non-standard fonts like English numerals, bi-lingual fonts, No conversion utilities. While KGP sings for standard for Kannada, what has prompted them to develop NUDI using a non-standard bi-lingual font. When the Directorate of Information technology penalises the shortlisted developers for not having followed the standard, what is the modus operandi behind promoting the non-standard uncertified software NUDI. Kannada Development KGP is successful in implementing (by influencing the project handling agencies) e-governance projects in non-standard proprietary bi-lingual glyphs by restricting all the Government data flow only confining to its wishes. Is it not a dirty trick. KGP is increasingly using yet another proprietary encoding for its own internal implementations and pass on their invisible internal encoding in the name of SDK, just crawl and grab the entire application development in Kannada. This proprietary encoding is also being used in the New NLP projects which KGP has started developing with huge funds flooded from the Government. With this initiative, KGP would build a considerable size of MRD, which are necessary for NLP projects. Can anyone explain how this huge size of MRD is interoperable and how it is going to help develop Kannada on computers. Kannada has become a victim of jealousy KGP. I wish Kannada with its outstanding 2300 years of survival and very rich literary contribution has to face this challenge and expose the erratic management of Kannada standards by KGP to maintain its sustained growth and enthronement on digital media. With my everlasting love and creed towards Kannada Kasthuri I have taken your precious time. I welcome your views on this subject. N. ANBARASAN email : ar...@bg... , phone : +91-080-3386167. |
From: Guntupalli K. <kar...@fr...> - 2002-10-22 07:18:49
|
Begin forwarded message: Date: Mon, 21 Oct 2002 18:55:20 +0100 From: "Richard Ishida" <is...@w3...> To: <www...@w3...> Subject: Call for Papers: IUC23 (23rd Internationalization and Unicode Conference) >>>>>>>>>>>>>>>>>>>>>>>>>> Call for Papers! ><<<<<<<<<<<<<<<<<<<<<<<<< Twenty-third Internationalization and Unicode Conference (IUC23) Unicode, Internationalization, the Web: The Global Connection Week of March 24-28, 2003 Prague, Czech Republic >>>>>>>>>>>>>>>>>>>> Send in your submission now! ><<<<<<<<<<<<<<<<<<< Submissions due: November 15, 2002 Notification date: November 29, 2002 Completed papers due: January 6, 2003 (in electronic form and camera-ready paper form) >>>>>>>>>>>>>>>>>>>>>>>> Just 4 weeks to go! <<<<<<<<<<<<<<<<<<<<<<< The Internationalization & Unicode Conference is the premier technical conference worldwide for both software and Web internationalization. The conference (renamed from "Unicode Conference" to more accurately reflect its content) features tutorials, lectures, and panel discussions that provide coverage of standards, best practices, and recent advances in the globalization of software and the Internet. Attendees benefit from the wide range of basic to advanced topics and the opportunities for dialog and idea exchange with experts in the field. The conference runs multiple sessions simultaneously to maximize the value provided. New technologies, innovative Internet applications, and the evolving Unicode Standard bring new challenges along with their new capabilities. This technical conference will explore the opportunities created by the latest advances and how to leverage them for global users, as well as potential pitfalls to be aware of, and problem areas that need further research. There will also be demonstrations of best practices for designing applications that can accommodate any language. We invite you to submit papers that relate to Unicode or any aspect of software and Web Internationalization. You can view the programs of previous conferences at: http://www.unicode.org/unicode/conference/about-conf.html CONFERENCE ATTENDEES Conference attendees are generally involved in either the development and deployment of Unicode software, or the globalization of software and the Internet. They include managers, software engineers, systems analysts, font designers, graphic designers, content developers, web designers, web administrators, technical writers, and product marketing personnel. THEME & TOPICS International computing is the overall theme of the Conference. Presentations should be geared towards a technical audience. Topics of interest include, but are not limited to, the following (within the context of Unicode, internationalization or localizability): - Internationalization issues with new technologies - XML and Web protocols - The World Wide Web (WWW) - Security concerns e.g. Avoiding the spoofing of UTF-8 data - Impact of new encoding standards - Implementing Unicode: Practical and political hurdles - Implementing new features of recent versions of Unicode - Evaluations (case studies, usability studies) - Natural language processing - Algorithms (e.g. normalization, collation, bidirectional) - Programming languages and libraries (Java, Perl, et al) - Optimizing performance of systems and applications - Search engines - Library and archival concerns - Portable devices - Migrating legacy applications - Cross platform issues - Printing and imaging - Operating systems - Databases - Large scale networks - Government applications - Testing applications - Business models for software development (e.g. Open source) We invite you to submit papers which define tomorrow's computing, demonstrate best practices in computing today, or articulate problems that must be solved before further advances can occur. SESSIONS The Conference Program will provide a wide range of sessions including: - Keynote presentations - Workshops/Tutorials - Technical presentations - Panel sessions All sessions except the Workshops/Tutorials will be of 40 minute duration. In some cases, two consecutive 40 minute program slots may be devoted to a single session. The Workshops/Tutorials will each last approximately three hours. They should be designed to stimulate discussion and participation, using slides and demonstrations. PUBLICATIONS If your paper is accepted, your details will be included in the Conference brochure and Web pages and the paper itself will appear on a Conference CD, with an optional printed book of Conference Proceedings. CONFERENCE LANGUAGE The Conference language is English. All submissions, papers and presentations should be provided in English. SUBMISSIONS Submissions MUST contain: 1. An abstract of 150-250 words, consisting of statement of purpose, paper description, and your conclusions or final summary. Also, if this is a paper for an intermediate or advanced audience, please specify what assumptions you are making about the attendees' prior knowledge. 2. A brief biography. 3. The details listed below: SESSION TITLE: _________________________________________ _________________________________________ TITLE (eg Dr/Mr/Mrs/Ms): _________________________________________ NAME: _________________________________________ JOB TITLE: _________________________________________ ORGANIZATION/AFFILIATION: _________________________________________ ORGANIZATION'S WWW URL: _________________________________________ OWN WWW URL: _________________________________________ ADDRESS FOR PAPER MAIL: _________________________________________ _________________________________________ _________________________________________ TELEPHONE: _________________________________________ FAX: _________________________________________ E-MAIL ADDRESS: _________________________________________ TYPE OF SESSION: [ ] Keynote presentation [ ] Workshop/Tutorial [ ] Technical presentation [ ] Panel PANELISTS (if Panel): _________________________________________ _________________________________________ _________________________________________ _________________________________________ _________________________________________ _________________________________________ _________________________________________ _________________________________________ TARGET AUDIENCE (you may select more than one category): [ ] Content Developers [ ] Font Designers [ ] Graphic Designers [ ] Managers [ ] Marketers [ ] Software Engineers [ ] Systems Analysts [ ] Technical Writers [ ] Others (please specify): _________________________________________ _________________________________________ LEVEL OF SESSION (you may select more than one category): [ ] Beginner [ ] Intermediate [ ] Advanced Submissions should be sent by e-mail to either of the following addresses: pa...@un... in...@gl... They should use ASCII, non-compressed text and the following subject line: Proposal for IUC 23 If desired, a copy of the submission may also be sent by post to: 23rd Internationalization and Unicode Conference c/o Global Meeting Services, Inc. 8949 Lombard Place #416 San Diego, CA 92122 USA Tel: +1 858 638 0206 Fax: +1 858 638 0504 CONFERENCE PROCEEDINGS All Conference papers will be published on CD. Printed proceedings will be offered as an option. EXHIBIT OPPORTUNITIES The Conference will have an Exhibition area for corporations or individuals who wish to display and promote their products, technology and/or services. Every effort will be made to provide maximum exposure and advertising. Exhibit space is limited. For further information or to reserve a place, please contact Global Meeting Services at the above location. CONFERENCE VENUE This 3 day Conference will be held during the week of March 24-28, 2003 in Prague, Czech Republic. Exact venue to be announced. THE UNICODE CONSORTIUM The Unicode Consortium was founded as a non-profit organization in 1991. It is dedicated to the development, maintenance and promotion of The Unicode Standard, a worldwide character encoding. The Unicode Standard encodes the characters of the world's principal scripts and languages, and is code-for-code identical to the international standard ISO/IEC 10646. In addition to cooperating with ISO on the future development of ISO/IEC 10646, the Consortium is responsible for providing character properties and algorithms for use in implementations. Today the membership base of the Unicode Consortium includes major computer corporations, software producers, database vendors, research institutions, international agencies and various user groups. For further information on the Unicode Standard, visit the Unicode Web site at http://www.unicode.org or e-mail <in...@un...> * * * * * Unicode(r) and the Unicode logo are registered trademarks of Unicode, Inc. Used with permission. |
From: G K. <kar...@fr...> - 2002-10-14 19:00:54
|
This could be one area where the groups can play a role, esp as this relates to i18nizing & l10n of web services, the much touted next information revolution. Karunakar |
From: Dr. U.B. P. <pav...@vi...> - 2002-10-10 03:00:28
|
Here is the reply I got from Paul Nelson about what's new in OTF 1.4 ------------ Begin -------------------------- Your fonts still need to be Unicode encoded. Most changes are editorial, with some other minor changes made. Nothing that impacts Indic scripts. Regards, Paul -----Original Message----- From: Dr. U.B. Pavanaja [mailto:pav...@vi...] Sent: Wednesday, October 09, 2002 7:19 AM To: Paul Nelson Subject: What's new in OTF 1.4? Hi Paul, Hope you remember me. I came to know that new specs of OTF 1.4 will be announced this Friday. What's new in this, esp regarding Indic? Can I have different display forms based on my keyboard input? Thanks and regards, Pavanaja- ------------- End ---------------------- > > > Begin forwarded message: > > Date: Tue, 8 Oct 2002 14:53:36 -0700 > From: Paul Nelson <pa...@wi...> > To: ope...@to... > Subject: [OpenType] Updated OpenType specification > > > Microsoft and Adobe are happy to announce the forthcoming release of > the OpenType specification version 1.4. This will be live on Friday, > 11 October 2002 on both the Microsoft Typography > (http://www.microsoft.com/typography/specs/default.htm) and Adobe > (http://partners.adobe.com/asn/developer/opentype/main.html) sites. > > Paul Nelson > Microsoft Typography > > Thomas Phinney > Adobe > > -- > OpenType - a discussion group for technical issues specific to > building and using OpenType fonts. > > ==^^=============================================================== > This email was sent to: kar...@fr... > > EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFCd.bWiE4J > Or send an email to: ope...@to... > > T O P I C A -- Register now to manage your mail! > http://www.topica.com/partner/tag02/register > ==^^=============================================================== > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Indic-computing-users mailing list > http://indic-computing.sourceforge.net/ > Ind...@li... > https://lists.sourceforge.net/lists/listinfo/indic-computing-users > [Other Indic-Computing mailing lists: -devel, -standards, -announce] > > ----------------------------------------------------- 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 |
From: Guntupalli K. <kar...@fr...> - 2002-10-09 13:45:19
|
Begin forwarded message: Date: Tue, 8 Oct 2002 14:53:36 -0700 From: Paul Nelson <pa...@wi...> To: ope...@to... Subject: [OpenType] Updated OpenType specification Microsoft and Adobe are happy to announce the forthcoming release of the OpenType specification version 1.4. This will be live on Friday, 11 October 2002 on both the Microsoft Typography (http://www.microsoft.com/typography/specs/default.htm) and Adobe (http://partners.adobe.com/asn/developer/opentype/main.html) sites. Paul Nelson Microsoft Typography Thomas Phinney Adobe -- OpenType - a discussion group for technical issues specific to building and using OpenType fonts. ==^^=============================================================== This email was sent to: kar...@fr... EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFCd.bWiE4J Or send an email to: ope...@to... T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^^=============================================================== |
From: Tapan S. P. <ta...@ya...> - 2002-09-20 05:56:12
|
Please note the addition of a new mailing list: ind...@li... It is intended to be a high-volume list for bringing together all kinds of indic-computing practitioners: linguists, engineers, users, developers, to discuss various aspects and problems in indic-computing. Many of the recent workshop participants have been subscribed to that list. We will be posting complete proceedings and results documentation from the workshop onto that list in the next few days, and we expect some of the discussion from the conference to spill onto -users. Even if you couldnt join us in Bangalore, we hope you can join us in this virtual forum. -- Tapan ------------------------------------------ Tapan S. Parikh ta...@ek... http://www.cs.washington.edu/homes/tapan |
From: Guntupalli K. <kar...@fr...> - 2002-09-09 10:13:23
|
Hi, A small snippet from http://www.acelinguasolutions.com/c-dac%20info.htm ---------- Inscript Keyboard layout This layout emerged out of brainstorming by several committees in DoE and was published in the IPAG journal in 1986. The concerns which it addressed were- a) People perceived Indian languages as very difficult to use on mechanical typewriters and avoided using them. This mental block arose due to the keyboard learning difficulty encountered on vernacular typewriters. b) There was no standardisation of vernacular keyboard layouts. c) If we were to increase the usage of Indian languages in future and make them co-exist and flourish on computers in harmony with English, it was imperative to develop a keyboarding scheme even simpler than English. Fortunately, our languages have a phonetic nature, this led to the development of a common phonetic layout based on consonants and vowels alone. All compositions and conjuncts were now handled by a computer with intelligent algorithms. This also gave rise to the acronym ?GIST? for Graphics and Intelligence based Script Technology. With this phonetic keyboard one can work in multiple languages, it is most easy to learn for infrequent users, is excellent for touch typing by typists, and provides ease of use for Indian languages. Today it is most popular amongst new users and many die-hard typewriter fanatics who tried it have switched over to it. Since it is common for all Indian scripts, it has been named as Inscript (Indian script) keyboard. ----------- We need to get hold of IPAG journals ( What is it & where is it available ). Regards, Karunakar |
From: Vijay P. S. A. <vi...@sr...> - 2002-08-18 18:49:31
|
Hi, A good resource: vijay -------------------------------------------------------------------------= ------- the entire directoryonly in Arts_and_Entertainment/Language =20 NissR: Regional: Asia: India: Arts and Entertainment: Language = (28) =20 -------------------------------------------------------------------------= ------- See also:=20 a.. Science: Social Sciences: Language and Linguistics: Natural = Languages (3,226)=20 b.. World: Bangla (39)=20 c.. World: Hindi (354)=20 d.. World: Kannada (52)=20 e.. World: Marathi (49)=20 f.. World: Tamil (95)=20 g.. World: Telugu (154)=20 -------------------------------------------------------------------------= ------- a.. Bharatbhasha - On setting up Hindi, Marathi, Gujarati, Bangla and = Gurmukhi fonts on Windows and Linux. Free help and technical queries.=20 b.. Ethnologue: Languages of the World - List of languages of India = and the geographical areas where it is spoken.=20 c.. FCFLRC: Hindi Language Resources - Provides computing aids and = tools for learning the Hindi language.=20 d.. Hindi Language - Resources for learning Hindi.=20 e.. The Hindi Language - Promoting Indian culture and the Hindi = language.=20 f.. Hindi Language and Literature - Hindi language links and resources = directory.=20 g.. Hindi Study Resources - Hindi language study books and links.=20 h.. Hindi Teacher - Learn Hindi through web lessons Kit. Designed and = produced by Bharat-Darshan, Hindi literary magazine from New Zealand.=20 i.. Indian Language Alphabet Comparison Page - Eden Golshani's website = - charts showing all the letters of the Hindi, Punjabi, Bengali, and = Gujarati syllabaries.=20 j.. Indian Languages - Brief rundown on major Indian languages.=20 k.. Indian Languages - Source of fonts for many Indian languages.=20 l.. ITRANS package - Produce high quality typeset documents in = Devanagari (Hindi/Marathi/Sanskrit), Telugu, Gujarati, Tamil, Romanized = Sanskrit, etc. for printing as well as for Web display using the ITRANS = pre-processor for TeX or for HTML output.=20 m.. Kalanjyam - Tamil Computing Dictionary - Computer related words = both in English and Tamil. Tamil words are in Murasu Anjal font.=20 n.. Katha a nonprofit working in the areas of languages, literatures, = education & development in India - A non-profit organization devoted to = publishing, workshops, cooperative centres, non-formal education centres = and pro-poor activities.=20 o.. Language Exercise in Hindi - This page contains links to several = Hindi exercises developed by Gabriela Nik. Ilieva and the Less Commonly = Taught Languages project at the University of Minnesota. Supplementary = to a language course.=20 p.. Mailjol Email - A free email service for sending emails in Indian = languages including Assamese, Bengali, Hindi, Gujarati, Kannada, = Marathi, Malayalam, Oriya, Punjabi, Sanskrit, Tamil, Telugu, and also = English. Requires login.=20 q.. Online Dictionary of the Oriya Language - Online dictionary of the = Oriya language, also known as Odia Shabdakossa. Links and some = information in English.=20 r.. Project Madurai - A project to convert older Tamil literary works = as electronic text stored in easily accessible archives.=20 s.. Roja Muthiah Research Library - Provides research material for = students of Tamil studies. Online catalogue search is available.=20 t.. Softech Creations - A set of commercial programs for teaching = Tamil.=20 u.. Tamil at Penn Language Center - Contains a number of different = kinds of teaching materials suitable for studying spoken and written = Tamil with a teacher.=20 v.. Tamil Electronic Library - A site for loads of links to Tamil = related websites and other web resources.=20 w.. Tamil Literature Online - An index (in English) to sites and = information about Tamil and Tamil literature.=20 x.. Telugu Books - Telugu Pusthakaalu - Telugu dictionaries, = encyclopaedia, Telugu bible, spoken Telugu.=20 y.. Telugu Literary Page - This website is partly in Telugu and = represents an effort to bring Telugu literature to the web.=20 z.. Ukindia - Learn Urdu Page - Free lessons for beginning Urdu = readers.=20 aa.. UPenn Page for Hindi Alphabet - Learn Hindi through video and = audio presentations in the Real Video file format.=20 ab.. Urdu Dictionary - Urdu (and Hindi) dictionary and thesaurus.=20 -------------------------------------------------------------------------= ------- =20 a.. "Language" search on: =20 All the Web - AltaVista - Google USENET - Google - HotBot - Lycos - = Northern Light - Yahoo =20 -------------------------------------------------------------------------= ------- Category editor: navan=20 =20 =20 =20 Help build the largest human-edited directory on the web.=20 Submit a Site - Open Directory Project - Become an Editor =20 =20 -------------------------------------------------------------------------= ------- Designed and Maintained by NissR Design. Part of this site is modified = from the Open Directory Project. Copyright =A9 2001 All rights reserved, NissR Design=20 |
From: glamsham.com <new...@gl...> - 2002-08-14 13:51:45
|
From: Srinatha S. <sa...@ea...> - 2002-08-13 11:11:40
|
Hi All, Kindly excuse me for one more mail. You can download NUDI Kannada software developed with the standards prescribed by the Govt. of Karnataka from the Web Site bangaloreit.com Thanks C V Srinatha Sastry Mahesh T Pai wrote: > Guntupalli Karunakar wrote: > > > What would you prefer > >(a) A keyboard with <insert ur language> printed on it (lets say > > with both <ur language> & roman alphabet printed), as per inscript > > layout (or similar one not needing a keyb driver). Here simple keymaps are used. > > > >(b) Keyboard like the ones available in market today (only roman) + > > if u need to type <ur language>, you stick keyboard stickers as per > > layout needed. Layout could be straight one like inscript or > > one requiring a keyboard driver/Input method. > > > > Speaking for myself, it is not relevant as to what character appears on > my keys so long as there is some kind of indentifiable symbol ( a raised > dot, a raised dash, etc) to position my fingers. I do not look at the > keyboard to type. On the Computer, it always easy to create a typing > tutorial showing the onscreen layout. for example, iLeap has an > excellent feature, whereby keyboard is displayed on the screen, with a > toggle switch, and also a drop down menu, showing the key combinations > required to create complex characters, which shows only the indian > script on screen, but on mouseover, the roman key and the indian > character on the roman key are displayed. > > Assuming that the industry adopts standard suggested in the first > question, the keyboard market in India is going to be divided into 17 > segments, we lose the economies of scale, and this will drive up cost of > keyboards from the present Rs. 250 odd to stratospheric levels, like > 1000 + charged by TVS for their keyboards. > > What? Did somebody say that competition will drive down prices? No, > competition is not likely to arise in such a fragmented market. > > >(c) Roman keyboard, using a phonetic or transliteration schemes for > > typing. You basically type in english to type in ur language. > > > Provided we arrive at a proper and refined transliteration schema, there > is no reason to have a inscript keyboard at all. I often find that it > takes a lot of trial and error to find the correct keyboard combinations > to get the exact character I want. Only justification for inscript is > that it is a 'learn once type all' overlay. Now, if the qwerty layout > can be used for the Indian languages, why should the user learn two > overlays (roman and inscript)? > One issue that may need to be considered in choice of keyboard over lays > is the by now infamous diesease affecting the fingers of computer user ( > something tunnelling syndrome ). Whether using the qwerty layout for > Indian languages is likely to put strain on the weaker finger is a > question which needs to be studied. > > Being a user of the inscript lay out (malayalam), I will certify that > inscript does not pass this test. The nukta, and the frequently used > vowel signs a aa, apart from the frequest use of the shift key means > that the inscript keyboard layout extremely unfriendly to your weaker > fingers. ( by the time you finish a legal size page - 10 to 15 minutes > for me ) my finger start aching. > > Regards, > Mahesh T Pai. > > ________________________________________________________________________ > Want to sell your car? advertise on Yahoo Autos Classifieds. It's Free!! > visit http://in.autos.yahoo.com > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Indic-computing-standards mailing list http://indic-computing.sourceforge.net/ > Ind...@li... > https://lists.sourceforge.net/lists/listinfo/indic-computing-standards |