indic-computing-devel Mailing List for The Indic-Computing Project (Page 7)
Status: Alpha
Brought to you by:
jkoshy
Menu
▾
▴
indic-computing-devel — Discussing the development of tools for Indian language information processing
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(14) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(25) |
Feb
(90) |
Mar
(41) |
Apr
(16) |
May
(8) |
Jun
|
Jul
(37) |
Aug
(35) |
Sep
(62) |
Oct
(37) |
Nov
(22) |
Dec
(7) |
| 2003 |
Jan
(16) |
Feb
(19) |
Mar
(10) |
Apr
(5) |
May
(26) |
Jun
(11) |
Jul
(35) |
Aug
(4) |
Sep
(14) |
Oct
(5) |
Nov
(5) |
Dec
(10) |
| 2004 |
Jan
(25) |
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(10) |
Aug
(2) |
Sep
(2) |
Oct
(1) |
Nov
(9) |
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2006 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(4) |
Dec
|
|
From: <a_j...@ya...> - 2003-05-23 00:45:59
|
[Second try] I am happy to announce an interim snapshot of the Python FreeType wrapper. This 'Milestone-1' release implements enough functionality to allow a Python version of the FreeType demo program 'ftdump' to be written. This is an interim snapshot and would be of interest to Python and FreeType users. in particular, the "Pythonic" view of the API is still being designed. If you are using the FreeType library to do any Indic rendering from C, please send me a URL to your code. One of the goals of this effort is to make common FreeType programming idioms easy to express using Python. Sub-project home page: http://indic-computing.sourceforge.net/projects/pyfreetype2.html Download (Milestone-1) http://prdownloads.sourceforge.net/indic-computing/py-freetype.tar.bz2?downloa d CVS Tree: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/indic-computing/src/py-freetype ===== Joseph Koshy, FreeBSD Developer, http://people.freebsd.org/~jkoshy/ Founder/Manager/Programmer/Peon, The Indic-Computing Project http://indic-computing.sf.net ________________________________________________________________________ Missed your favourite TV serial last night? Try the new, Yahoo! TV. visit http://in.tv.yahoo.com |
|
From: Kanti J. <j_...@re...> - 2003-05-20 03:55:45
|
On Mon, 19 May 2003 Primoz PETERLIN wrote : >-----BEGIN PGP SIGNED MESSAGE----- > >On Wed, 14 May 2003, Kanti Jadia wrote: > > > Cyberscape ,the company which released the first set of >Indic > > fonts under GPL has withdrawn some of the fonts due to >possible > > copyright issues. > > ... > > Devnagari - dev1-n.ttf and dev1-b.ttf > > Gujarati - guj2-n.ttf and guj2-b.ttf > > Bengali - bng1-n.ttf and bng1-b.ttf > > Kannada - knd2-n.ttf and knd2-b.ttf > > Tamil - tml2-n.ttf and tml2-b.ttf > > Telugu - tlg1-n.ttf and tlg1-b.ttf > > Punjabi - pnj1-n.ttf and pnj1-b.ttf > > Oriya - ori2-n.ttf and ori2-b.ttf > > Malayalam - mal1-n.ttf and mal1-b.ttf > > > > FSF-India discourages the use of the above mentioned fonts >for > > your work, particularly GPL based work. > >I'll have to have a look. Does this mean that the rest 17 fonts >are kosher >and suitable for GPL based work? Yes,to the best of our knowledge you can use them. >These are: > >Bengali bng2-n.ttf bng2-b.ttf >Devanagari dev2-n.ttf >Gujarati guj1-n.ttf guj1-b.ttf >Kannada knd1-n.ttf knd1-b.ttf >Malayalam mal2-n.ttf mal2-b.ttf >Oriya ori1-n.ttf ori1-b.ttf >Punjabi pnj2-n.ttf pnj2-b.ttf >Telugu tlg2-n.ttf tlg2-b.ttf >Tamil tml1-n.ttf tml1-b.ttf > >With kind regards, Primoz > >- -- >Primo¾ Peterlin, In¹titut za biofiziko, Med. fakulteta, >Univerza v Ljubljani >Lipièeva 2, SI-1000 Ljubljana, Slovenija. >pri...@bi... >Tel +386-1-5437632, fax +386-1-4315127, >http://biofiz.mf.uni-lj.si/~peterlin/ >F8021D69 OpenPGP fingerprint: CB 6F F1 EE D9 67 E0 2F 0B 59 AF >0D 79 56 19 0F >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.0.6 (HP-UX) >Comment: For info see http://www.gnupg.org > >iQB1AwUBPsirIj3bcxr4Ah1pAQEuSgMAswUh5uh5pZA8NWcih3VNpR+ND/fn4kKi >Á>7n4FH6VzxYbAb6TB90RotJu7sWkAyC7fjXvf6ifhiYHLEgpRnUeLhcYefyASFY4K >7HvSjZNH5kffBqScW8ny4Yesyma309bX >=RZLt >-----END PGP SIGNATURE----- > ----------------------------------------- Enjoy your Freedom,use GNU/Linux. http://www.gnu.org/gnu/why-gnu-linux.html ----------------------------------------- |
|
From: Primoz P. <pri...@bi...> - 2003-05-19 10:01:44
|
-----BEGIN PGP SIGNED MESSAGE----- On Wed, 14 May 2003, Kanti Jadia wrote: > Cyberscape ,the company which released the first set of Indic > fonts under GPL has withdrawn some of the fonts due to possible > copyright issues. > ... > Devnagari - dev1-n.ttf and dev1-b.ttf > Gujarati - guj2-n.ttf and guj2-b.ttf > Bengali - bng1-n.ttf and bng1-b.ttf > Kannada - knd2-n.ttf and knd2-b.ttf > Tamil - tml2-n.ttf and tml2-b.ttf > Telugu - tlg1-n.ttf and tlg1-b.ttf > Punjabi - pnj1-n.ttf and pnj1-b.ttf > Oriya - ori2-n.ttf and ori2-b.ttf > Malayalam - mal1-n.ttf and mal1-b.ttf > > FSF-India discourages the use of the above mentioned fonts for > your work, particularly GPL based work. I'll have to have a look. Does this mean that the rest 17 fonts are kosher and suitable for GPL based work? These are: Bengali=09=09bng2-n.ttf=09bng2-b.ttf Devanagari=09dev2-n.ttf Gujarati=09guj1-n.ttf=09guj1-b.ttf Kannada=09=09knd1-n.ttf=09knd1-b.ttf Malayalam=09mal2-n.ttf=09mal2-b.ttf Oriya=09=09ori1-n.ttf=09ori1-b.ttf Punjabi=09=09pnj2-n.ttf=09pnj2-b.ttf Telugu=09=09tlg2-n.ttf=09tlg2-b.ttf Tamil=09=09tml1-n.ttf=09tml1-b.ttf With kind regards, Primoz - -- Primo=BE Peterlin, In=B9titut za biofiziko, Med. fakulteta, Univerza v Lj= ubljani Lipi=E8eva 2, SI-1000 Ljubljana, Slovenija. primoz.peterlin@biofiz.mf.uni-= lj.si Tel +386-1-5437632, fax +386-1-4315127, http://biofiz.mf.uni-lj.si/~peterl= in/ F8021D69 OpenPGP fingerprint: CB 6F F1 EE D9 67 E0 2F 0B 59 AF 0D 79 56 19= 0F -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (HP-UX) Comment: For info see http://www.gnupg.org iQB1AwUBPsirIj3bcxr4Ah1pAQEuSgMAswUh5uh5pZA8NWcih3VNpR+ND/fn4kKi 7n4FH6VzxYbAb6TB90RotJu7sWkAyC7fjXvf6ifhiYHLEgpRnUeLhcYefyASFY4K 7HvSjZNH5kffBqScW8ny4Yesyma309bX =3DRZLt -----END PGP SIGNATURE----- |
|
From: Bharateeya-OpenOffice <bha...@nc...> - 2003-05-19 08:42:00
|
Hi, OO.o 1.1 Beta (644) incorporates some major changes in implementation, and includes a generalized framework for CTL-based languages like Hindi and Thai. The BharateeyaOO.o version that we have developed, (taken from the 641 source tag), has support only for Indian languages in general. OO.o 1.1 Beta (note: implementations are still in beta stage, and are being perfected for Beta2 and stable releases) provides good initial support for Indian CTL and locales; however, a stable release with complete support is our lookout. We are also testing some extended features like dictionary, Indian language templates and helpcontent, and you will be able to see these incorporated soon. We are planning to release BharateeyaOO.o ,*OO.o 1.1 Beta* and newer stable build localizations soon, specifically on Linux. These will be made available, not only on our site, but also on OO.o mirrors. The urls will be specified on our hi.openoffice.org -> download page. Best Regards, BharateeyaOO.o Team <http://hi.openoffice.org> <http://www.ncb.ernet.in/bharateeyaoo> ----------------------------------------------------------------------- Bhupesh Koli <bh...@op...> Shikha G Pillai <sh...@op...> ----------------------------------------------------------------------- On Mon, 19 May 2003, Guntupalli Karunakar wrote: > On Mon, 19 May 2003 13:36:14 +0530 (IST) > Bharateeya-OpenOffice <bha...@nc...> wrote: > > > Hello All, > > > > (We were going to formally announce the news today..., but well > > information goes around faster than we thought :-) Prakash Advani > > has already announced for us, thank you.) > > > > The Indian Flag flies high on OpenOffice.org!!! > > ----------------------------------------------- > > > > We have started the first Indian Native Language Project on > > OpenOffice.org - http://hi.openoffice.org/ which brings OO.o to > > Indian users in Hindi. This will be the official site for our work, > > through which we hope to represent and coordinate the Indian > > linguistic communities on OpenOffice.org. The site has mailing > > lists, members and issue tracking, which can be used to tackle > > Indian language support problems in OO.o, as well as other language > > issues. The site is just in its initial phase... there will be lots > > more to come soon. > > > > We hope that this will mark a new beginning in the field of > > indic-computing as well as Indian language representation in OO.o, > > and we look forward to some comments and/or feedback. > > > > Is there a Linux version of BharateeyaOO out? How different is it from > OOO 1.1 beta announced to have Hindi support. > > Regards, > Karunakar > > -- > "The best way to cheer yourself up is to try to > cheer somebody else up." -Mark Twain > > --------------------------- > * Indian Linux project * > * http://www.indlinux.org * > --------------------------- > |
|
From: Guntupalli K. <kar...@fr...> - 2003-05-19 08:09:07
|
On Mon, 19 May 2003 13:36:14 +0530 (IST) Bharateeya-OpenOffice <bha...@nc...> wrote: > Hello All, > > (We were going to formally announce the news today..., but well > information goes around faster than we thought :-) Prakash Advani > has already announced for us, thank you.) > > The Indian Flag flies high on OpenOffice.org!!! > ----------------------------------------------- > > We have started the first Indian Native Language Project on > OpenOffice.org - http://hi.openoffice.org/ which brings OO.o to > Indian users in Hindi. This will be the official site for our work, > through which we hope to represent and coordinate the Indian > linguistic communities on OpenOffice.org. The site has mailing > lists, members and issue tracking, which can be used to tackle > Indian language support problems in OO.o, as well as other language > issues. The site is just in its initial phase... there will be lots > more to come soon. > > We hope that this will mark a new beginning in the field of > indic-computing as well as Indian language representation in OO.o, > and we look forward to some comments and/or feedback. > Is there a Linux version of BharateeyaOO out? How different is it from OOO 1.1 beta announced to have Hindi support. Regards, Karunakar -- "The best way to cheer yourself up is to try to cheer somebody else up." -Mark Twain --------------------------- * Indian Linux project * * http://www.indlinux.org * --------------------------- |
|
From: Bharateeya-OpenOffice <bha...@nc...> - 2003-05-19 07:56:03
|
Hello All,
(We were going to formally announce the news today..., but well
information goes around faster than we thought :-) Prakash Advani has
already announced for us, thank you.)
The Indian Flag flies high on OpenOffice.org!!!
-----------------------------------------------
We have started the first Indian Native Language Project on
OpenOffice.org - http://hi.openoffice.org/ which brings OO.o to Indian
users in Hindi. This will be the official site for our work, through which
we hope to represent and coordinate the Indian linguistic communities on
OpenOffice.org. The site has mailing lists, members and issue tracking,
which can be used to tackle Indian language support problems in OO.o, as well
as other language issues. The site is just in its initial phase... there will
be lots more to come soon.
We hope that this will mark a new beginning in the field of
indic-computing as well as Indian language representation in OO.o, and we
look forward to some comments and/or feedback.
So, see you at hi.openoffice.org! :-)
Best Regards
BharateeyaOO.o (& now hi.openoffice.org too!) Team
<http://hi.openoffice.org/>
<http://www.ncb.ernet.in/bharateeyaoo>
----------------------------------------------------------------
Bhupesh Koli <bh...@op...>
Shikha G Pillai <sh...@op...>
----------------------------------------------------------------
|
|
From: Venky H. <ve...@vs...> - 2003-05-15 06:35:21
|
What happens to the work that was done after the fonts were released under GPL? Does that get nullified? Some clarity on that would be a great help. Venky ----- Original Message ----- From: Kanti Jadia <j_...@re...> To: <ind...@li...> Sent: Wednesday, May 14, 2003 6:51 PM Subject: [Indic-computing-devel] Akruti fonts > > http://www.gnu.org.in/ > > Cyberscape ,the company which released the first set of Indic > fonts under GPL has withdrawn some of the fonts due to possible > copyright issues. > Cyberscape ,which released the Akruti fonts under GPL has > withdrawn the following fonts due to possible copyright issues. > > Devnagari - dev1-n.ttf and dev1-b.ttf > > Gujarati - guj2-n.ttf and guj2-b.ttf > > Bengali - bng1-n.ttf and bng1-b.ttf > > Kannada - knd2-n.ttf and knd2-b.ttf > > Tamil - tml2-n.ttf and tml2-b.ttf > > Telugu - tlg1-n.ttf and tlg1-b.ttf > > Punjabi - pnj1-n.ttf and pnj1-b.ttf > > Oriya - ori2-n.ttf and ori2-b.ttf > > Malayalam - mal1-n.ttf and mal1-b.ttf > > FSF-India discourages the use of the above mentioned fonts for > your work, particularly GPL based work. > > We regret for the inconvenience caused > > > > ----------------------------------------- > Enjoy your Freedom,use GNU/Linux. > http://www.gnu.org/gnu/why-gnu-linux.html > ----------------------------------------- > > > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise solutions > www.enterpriselinuxforum.com > > _______________________________________________ > Indic-computing-devel mailing list > http://indic-computing.sourceforge.net/ > Ind...@li... > https://lists.sourceforge.net/lists/listinfo/indic-computing-devel > [Other Indic-Computing mailing lists available: -users, -standards, -announce] > |
|
From: Kanti J. <j_...@re...> - 2003-05-14 13:23:12
|
http://www.gnu.org.in/ Cyberscape ,the company which released the first set of Indic fonts under GPL has withdrawn some of the fonts due to possible copyright issues. Cyberscape ,which released the Akruti fonts under GPL has withdrawn the following fonts due to possible copyright issues. Devnagari - dev1-n.ttf and dev1-b.ttf Gujarati - guj2-n.ttf and guj2-b.ttf Bengali - bng1-n.ttf and bng1-b.ttf Kannada - knd2-n.ttf and knd2-b.ttf Tamil - tml2-n.ttf and tml2-b.ttf Telugu - tlg1-n.ttf and tlg1-b.ttf Punjabi - pnj1-n.ttf and pnj1-b.ttf Oriya - ori2-n.ttf and ori2-b.ttf Malayalam - mal1-n.ttf and mal1-b.ttf FSF-India discourages the use of the above mentioned fonts for your work, particularly GPL based work. We regret for the inconvenience caused ----------------------------------------- Enjoy your Freedom,use GNU/Linux. http://www.gnu.org/gnu/why-gnu-linux.html ----------------------------------------- |
|
From: Krishnamurthy N. <kn...@ya...> - 2003-05-13 08:30:50
|
Hi Surya, --- Suryaprakash Kompalli <kom...@ce...> wrote: > Hello, > > > So, what kind of a standard are we planning to > use for the transliteration itself? Well, we need not really get into standards for transliteration - it can easily be made generic enough and modifiable by either end-user or other developers. >True in the current scenario, but why in the > long run?? We can create engines to do this, > something > like say-flash - If you want to view falsh based > content, > you need flash to be on your machine (client side) - > similar way - if you need to view Devanagari text - > install our XYZ (preferably opensource) package, and > any > website that conforms to these standards will be > able to > display Devanagari to you. This will allow - > A central body to easily make modifications to how > the software > behaves, instead of individual websites having > arbitrary > control. > A (ServerSide) JScript + (ClientSide)Java based > solution might > allow us to come up with a quick fix to do something > like this. And at a > subsequent time, we can do away with the quick fix > and develop our own > packages to deal with any kind of character > rendering or input schemes. > (option buttons, password entry, input boxes etc.) Yes, I agree that we can create engines that can be downloaded by a client and can be centrally controlled. This would also make the apps as interactive as possible. > This is exactly what I am hinting at - > It might be difficult to get instant results in the > short > term - but in the long term, a client side solution > would > help. Yes. > I have done the transliteration to unicode part > for devanagari - for a tool we use for our research > work. > If someone sheds light on the transliteration scheme > being used, I could help. Pls see the reply further down in this mail. > We are using unicode encoding for such purposes and > I am in the process of developing a query and > retrieval > system using the same scheme (for the tool mentioned > earlier) > > However, There could be some misinterpretations > on my part, I think I need to brush up on the > activities in our group. I have been working on > Indic > Computing for a short while, but I do not know where > to get technical-info about the various > ideas/projects that > everyone is posting here - If there is a web-site(s) > from > where I can get more info, it would be gr8. I did > not > notice info about the translib project at - > http://indic-computing.sourceforge.net/projects/index.html Since it's still work-in-progress, we haven't put up a downloadable tarball. You can check out, as anon user, the entire indic-computing project CVS tree from the cvs page of this project (http://sourceforge.net/cvs/?group_id=38057) or navigate thru the main page and reach at the same page from the 'Sources' sub-section. Pls go thru the documentation (and source) of translib and other projects and let's know your comments. > And, is there a pdf verion of the handbook? > http://indic-computing.sourceforge.net/handbook/index.html I suggest you download the doc-tool-chain tarball and run the docbook to get a single document in your preferred format. Thanks for your interest! cheers, Nagarajan __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com |
|
From: Krishnamurthy N. <kn...@ya...> - 2003-05-13 06:06:56
|
Hi Tapan, --- "Tapan S. Parikh" <ta...@ya...> wrote: > This is debatable (and has been debated). Doing > glyph composition on > the server will preclude user-installed fonts on the > client with > variable glyph sets. Also, depending on how you > define input > processing, it might also preclude different types > of keyboard mappings > (and input methods) on the client side. Yes, it's debatable for more reasons than this. First, as I pointed out and also by Suryaprakash, it can't really be very interactive on the client-side. About user-installed fonts on client side : as we all know, it's not just the fonts that are enough to do rendering for Indian languages - you need to do process the input key sequence according to certain rules, and do or don't do translitration and do the appropriate glyph mapping for 'a given' font, and not any and every font. We all know the issue of lack of any standard for Indian scripts. I guess until we have any standards for Indian script fonts, we can't give full freedom on the client side to choose any font. > Part of this seems like a worthy effort, but the > need for the > transliteration is not clear to me. Why is it > required, what purpose > does the romanized text serve? Why not just go from > UTF-8 directly to the glyph names? Direct mapping of input sequence, whether in utf-8 or Romain phonetic, to an appropriate sequence of glyphs is not feasible for any of the Indian languages, due to the various complexities related to all kinds of contextual details. As I developed the generic transliteration rules framework that would work for any Indian language/script, this had become quite clear to me. Why utf-8 to romanized text : this was more convenient to do this and apply the generic transliteration rules that I developed. > > Its seems that you are proposing now three standards > - Unicode, the > transliteration standard, and the glyph standard > (for storage, > transmission and display respectively). It is > unclear to me why the > storage and transmission standards have to be > different (in fact they > already are - UCS-2 vs. UTF-8). It has been hard > enough to get 1 > standard in place. Why shoot for two more now, when > only one is > required (for glyphs)? No, I am not proposing any new standards. If you have seen the sample fontmaps that give 'symbolic' names to glyphs or cluster of glyphs in a font, and the generic mappings I have given to map the vowels, consonants and other entities of Indian scripts to phonetic keybd input sequences in the transliteration rule map files, I left everything open to the end-user or user of translib. The mappings can freely modified and as long as what's 'stored' is based on an accepted standard such as utf8, that is enough. If at all, we will need a 'minimalistic' glyph standard for each Indian 'script'. > > Also, unless the glyph names are somehow "abstract", > and do not stand > for direct 1-1 mappings to actual glyph indices, > this precludes variable > glyph sets which would be a requirement for > different quality (and cost) > fonts and advanced typography. Yes, glyph names are 'abstract', as defined in the fontmap file format by Koshy. The very precise reason why we developed such abstract glyph names is for usability across different fonts. > > It seems to me you are proposing an alternative to > OTF, which MAY be a > worthy effort if the IPR issues remain muddy w/ that > technology. But > you seem to be doing that at the expense of some of > the complexity and > expressivity of the OTF standard. IMHO that may not > be a wise long term > compromise. Am I missing the point? It's not that I am proposing an alternative to OTF. It's just that I see that with a few special mapping rules for special 'input sequence combinations', we can use special glyphs or clusters of glyphs for effective high quality rendering (e.g in the CDAC Devanagari font, there are four different glyphs for dependent vowel sign 'i' and it takes just four simple rules in the translit. rule file (simple text file) to effectively specify the context where each of these four different glyphs need to be used). cheers, Nagarajan __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com |
|
From: Tapan S. P. <ta...@ya...> - 2003-05-12 21:02:48
|
> > In a web-based client-server model of app development, > unlike Latin scripts/languages, it would be more > appropriate to do input processing, transliteration > and glyph composition for rendering on the server > side. This is debatable (and has been debated). Doing glyph composition on the server will preclude user-installed fonts on the client with variable glyph sets. Also, depending on how you define input processing, it might also preclude different types of keyboard mappings (and input methods) on the client side. > A couple of weeks back, I made an enhancement to my > transliteration library (translib under the > indic-computing project on sourceforge) to take a > 'word' in an Indian language encoded as a sequence of > Unicode characters (in UTF-8 format), kind of map it > (using a user-defined lookup mapping file) to the most > appropriate Roman phonetic input and then apply the > transliteration rules for that language+script by > looking up the transliteration rule file. The output, > as before, is a sequence of symbolic glyph names that > correspond to glyph indices in a given font file. This > can be fed to a font reading and rendering library > such as freetype2 for final display (Koshy wrote a > python script to do this using gozer, but he is now > replacing gozer with a python wrapper to ft2). > Part of this seems like a worthy effort, but the need for the transliteration is not clear to me. Why is it required, what purpose does the romanized text serve? Why not just go from UTF-8 directly to the glyph names? Its seems that you are proposing now three standards - Unicode, the transliteration standard, and the glyph standard (for storage, transmission and display respectively). It is unclear to me why the storage and transmission standards have to be different (in fact they already are - UCS-2 vs. UTF-8). It has been hard enough to get 1 standard in place. Why shoot for two more now, when only one is required (for glyphs)? Also, unless the glyph names are somehow "abstract", and do not stand for direct 1-1 mappings to actual glyph indices, this precludes variable glyph sets which would be a requirement for different quality (and cost) fonts and advanced typography. > > Unicode is neither an input mapping scheme nor a glyph > mapping scheme; it's just an encoding scheme, as all > of us know. It has limitations, but with a sound > transliteration library in place, utf-8 can be used > for > storing Indian language content for further processing > (search, sort, display etc etc). > It seems to me you are proposing an alternative to OTF, which MAY be a worthy effort if the IPR issues remain muddy w/ that technology. But you seem to be doing that at the expense of some of the complexity and expressivity of the OTF standard. IMHO that may not be a wise long term compromise. Am I missing the point? Any other views? -- Tapan |
|
From: Suryaprakash K. <kom...@ce...> - 2003-05-12 20:29:16
|
Hello, > A good, generic transliteration library for the Indian > languages/scripts is what is needed, IMHO. As anyone So, what kind of a standard are we planning to use for the transliteration itself? > In a web-based client-server model of app development, > unlike Latin scripts/languages, it would be more > appropriate to do input processing, transliteration > and glyph composition for rendering on the server True in the current scenario, but why in the long run?? We can create engines to do this, something like say-flash - If you want to view falsh based content, you need flash to be on your machine (client side) - similar way - if you need to view Devanagari text - install our XYZ (preferably opensource) package, and any website that conforms to these standards will be able to display Devanagari to you. This will allow - A central body to easily make modifications to how the software behaves, instead of individual websites having arbitrary control. A (ServerSide) JScript + (ClientSide)Java based solution might allow us to come up with a quick fix to do something like this. And at a subsequent time, we can do away with the quick fix and develop our own packages to deal with any kind of character rendering or input schemes. (option buttons, password entry, input boxes etc.) > side. So, using Javascript may not be that feasible to > achieve this. At the same time, if all processing is > on the server side, then the application can't be > really that interactive (such as showing the display > to the user for each syllable typed in). Some This is exactly what I am hinting at - It might be difficult to get instant results in the short term - but in the long term, a client side solution would help. > intermediate soluton would be needed. Also, using PHP > may be a better idea than Javascripts or jsp. What do > you folks think ? > A couple of weeks back, I made an enhancement to my > transliteration library (translib under the > indic-computing project on sourceforge) to take a > 'word' in an Indian language encoded as a sequence of > Unicode characters (in UTF-8 format), kind of map it > (using a user-defined lookup mapping file) to the most > appropriate Roman phonetic input and then apply the > transliteration rules for that language+script by > looking up the transliteration rule file. The output, > as before, is a sequence of symbolic glyph names that > correspond to glyph indices in a given font file. This > can be fed to a font reading and rendering library > such as freetype2 for final display (Koshy wrote a > python script to do this using gozer, but he is now > replacing gozer with a python wrapper to ft2). I have done the transliteration to unicode part for devanagari - for a tool we use for our research work. If someone sheds light on the transliteration scheme being used, I could help. > I tried out this utf8-to-final-glyph rendering for > Hindi+Devanagari with very minimal mapping done and > did some prelim testing and it's ok. All the > intelligence is in the user-defined mapping files and > the source code itself has no knowledge of any Indian > language. Yes, I agree.... > Unicode is neither an input mapping scheme nor a glyph > mapping scheme; it's just an encoding scheme, as all > of us know. It has limitations, but with a sound > transliteration library in place, utf-8 can be used > for > storing Indian language content for further processing > (search, sort, display etc etc). We are using unicode encoding for such purposes and I am in the process of developing a query and retrieval system using the same scheme (for the tool mentioned earlier) However, There could be some misinterpretations on my part, I think I need to brush up on the activities in our group. I have been working on Indic Computing for a short while, but I do not know where to get technical-info about the various ideas/projects that everyone is posting here - If there is a web-site(s) from where I can get more info, it would be gr8. I did not notice info about the translib project at - http://indic-computing.sourceforge.net/projects/index.html And, is there a pdf verion of the handbook? http://indic-computing.sourceforge.net/handbook/index.html This site had some circular links - but I did not find the pdf version. Thanks, Surya __ __ |__ |__| |/ __|urya |rakash |\ompalli Email - kom...@cs... Phone - Home - (716) 834 6859 - Work - (716) 645 6164 X 519 Personal - http://www.cse.buffalo.edu/~kompalli Academic - http://www.cedar.buffalo.edu/ilt |
|
From: Krishnamurthy N. <kn...@ya...> - 2003-05-12 12:32:58
|
Hi Suryaprakash, Arun and others, A good, generic transliteration library for the Indian languages/scripts is what is needed, IMHO. As anyone who has studied the structure of Indian languages and scripts would appreciate, there is good structure in the phonetic input and how the input syllables are encoded using a script and how they are mapped to a series of simple or composite glyphs. In a web-based client-server model of app development, unlike Latin scripts/languages, it would be more appropriate to do input processing, transliteration and glyph composition for rendering on the server side. So, using Javascript may not be that feasible to achieve this. At the same time, if all processing is on the server side, then the application can't be really that interactive (such as showing the display to the user for each syllable typed in). Some intermediate soluton would be needed. Also, using PHP may be a better idea than Javascripts or jsp. What do you folks think ? A couple of weeks back, I made an enhancement to my transliteration library (translib under the indic-computing project on sourceforge) to take a 'word' in an Indian language encoded as a sequence of Unicode characters (in UTF-8 format), kind of map it (using a user-defined lookup mapping file) to the most appropriate Roman phonetic input and then apply the transliteration rules for that language+script by looking up the transliteration rule file. The output, as before, is a sequence of symbolic glyph names that correspond to glyph indices in a given font file. This can be fed to a font reading and rendering library such as freetype2 for final display (Koshy wrote a python script to do this using gozer, but he is now replacing gozer with a python wrapper to ft2). I tried out this utf8-to-final-glyph rendering for Hindi+Devanagari with very minimal mapping done and did some prelim testing and it's ok. All the intelligence is in the user-defined mapping files and the source code itself has no knowledge of any Indian language. Unicode is neither an input mapping scheme nor a glyph mapping scheme; it's just an encoding scheme, as all of us know. It has limitations, but with a sound transliteration library in place, utf-8 can be used for storing Indian language content for further processing (search, sort, display etc etc). cheers, Nagarajan --- Suryaprakash Kompalli <kom...@ce...> wrote: > Hello, > > What about Javascript ? When user types in a text > field using some > > Transliteration scheme or Inscript KeyBoard layout > convert it to font > > For collecting data on Indic scripts, we had > created an interface > that uses Java. I had used ITRANS transliteration > and the default java > fonts to come up with an input window that accepts > transliteration in > Latin script and outputs Devanagari on another > window. > I am not familiar with CMS or *nuke - but with what > I gather > reusable java classes could be a good way to look at > it. We can develop > classes to work with other languages - > Right now, the tool might be a bit bulky to work > with since the > package has a lot of Image Processing related code > to go with it. But > its' good to test offline - Ppl can take a look at > it here - > www.cedar.buffalo.edu/ilt > If its' useful, we can plan to make the input > system independant > of the IP part - > > > http://www.wandel.subnet.dk/hindi.html > I tried the site out - it didnt need applets - but > it didnt work > on netscape either - gave me a message saying it > needs windows to work > with but then behaved OK on mozilla. :) :( What it > is doing is - it > takes the unicode value for the character, converts > it into int and this > is what we can do with the o/p - > > <html> > ???? > </html> > > But since what it is in the background is basically > unicode, we > still need a *properly configured* browser to view > the stuff - It came > out properly on Mozilla, didnt show up on netscpape. > Pretty nifty - but > the addition of transliterated/keyboard based input > might be more welcome. > The characters present in the interface are the ones > from the unicode > table for Devanagari. > > Bye, > Surya > On 5 May 2003, Arun M wrote: > > > Hi Friends, > > > > We see a lot of community portals coming up > these days based on > > CMS like *nuke. But one of these CMS supports > Indic. Also we dont see > > any community discussion boards in Indian > languages (Pls correct me). > > > > Some issues I see are: > > > > - There is no indic(Unicode/Non unicode) support > in most platforms. > > - Most browsers doesnt support unicode. > > > > Any community portal we build should be based on > font encoding > > systems, at least for some more time. A idea is > store > > the data in Unicode and then convert to font > encoding at the server > > side. A special proxy should help here. > > > > Second issues is entering data from the client > side. This is major > > prob. Most of the sites uses Java applets for > entering the data in > > local languages. This may require good amount of > modification in the > > CMS we have now like *nuke. > > > > Yesterday I made a proto of this. A crude one. It > works. > > > > Do you think this will be of use ? If so I will > work on it and > > make the code better and generic(I dont know > Javascript much , will have to > > learn it first). > > > > > > Arun. > > __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com |
|
From: Dr. U.B. P. <pav...@vi...> - 2003-05-06 04:28:51
|
> 2. Also may be Javascript wasnt as powerful as it is now, when these > Java solutions came up. And then people simply followed the Java. > (Dont have much idea abt history of web technologies) As per my knowledge, Javascript can trap and handle ASCII values of the trapped keys and not keyboard scancodes (check http://javascript.internet.com/forms/block-key-press.html). To write a keyboard handler, we need to trap the keyboard scnacodes. -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 |
|
From: Arun M <ar...@gn...> - 2003-05-06 03:19:06
|
> Aha. Karunakar hit the nail on the head. No one *wanted* to think of using
> Javascript before because they were thinking commercial, and they didn't want
> their code to be copy-able.
I dont take that reason completely.
1. The problem we are trying to address here is some thing different
from what Indic sites tries to solves with Java.
(Java solution has some advantages in comparison with Javascript
solution)
2. Also may be Javascript wasnt as powerful as it is now, when these
Java solutions came up. And then people simply followed the Java.
(Dont have much idea abt history of web technologies)
|
|
From: Arun M <ar...@fr...> - 2003-05-06 03:08:54
|
> I certainly think this will be of huge value. Input methods are on the > client have been a huge hurdle and often forces clients to go to Windoze So, I've to add one more item to todo list. > XP over other platforms like Linux or even (gasp!) Windoze 98. I didnt > realize this would be possible using javascript, if so I am wondering > why noone thought of it before. may be because it is too simple ;) arun. |
|
From: Arun M <ar...@fr...> - 2003-05-06 03:02:40
|
> Something about the social aspect of using Indic scripts on the web: While > these are valid points, the browsers most people use do support unicode.(all > right flame me but face the truth first!) Unless the existing users, who use > English, start using Indic languages in mailing lists and boards, users who > don't know English very well are not going to get much encouragement either. > Developing a user base is crucial because that's where future developers would > emerge from. The old chicken, egg prob. > > - Most browsers doesnt support unicode. > I think most of them do, thanks to CJKV. What they *don't* support is indic > script rendering. Sorry for the mistake. I think you got the point. arun. |
|
From: <al...@ya...> - 2003-05-05 12:29:29
|
> "Tapan S. Parikh" <ta...@ya...> wrote: > > 98. I didnt realize this would be possible using javascript, if so > > I am wondering why noone thought of it before. > > > Sites like epatra.com have used it before, but they used to send the > text to the server to get the glyph codes (they couldnt have it all in > JS else nyone else would have easily copied it for own sites ). Aha. Karunakar hit the nail on the head. No one *wanted* to think of using Javascript before because they were thinking commercial, and they didn't want their code to be copy-able. ===== Contribute to http://indic-computing.sourceforge.net +91-80-653-8200 http://groups.yahoo.com/group/linux-bangalore-hindi/ Can't see Hindi? http://geocities.com/alkuma/seehindi.html http://9211.blogspot.com Set View->Encoding->UTF-8 à¤à¤ªà¤à¥ सà¥à¤à¤¾à¤µ शà¥à¤à¥à¤°à¤¤à¤¾ सॠतà¤à¥ सà¥à¤µà¥à¤à¤¾à¤° हà¥à¤à¤à¥ à¤à¥ à¤à¤¬ à¤à¤ª à¤à¤¨à¥à¤¹à¥à¤ लाà¤à¥ à¤à¤°à¤¨à¥ à¤à¤¾ बà¥à¤¡à¤¼à¤¾ à¤à¥ सà¥à¤µà¤¯à¤ à¤à¤ ायà¥à¤à¤à¥à¥¤ ________________________________________________________________________ Missed your favourite TV serial last night? Try the new, Yahoo! TV. visit http://in.tv.yahoo.com |
|
From: Suryaprakash K. <kom...@ce...> - 2003-05-05 12:18:07
|
Hello, > What about Javascript ? When user types in a text field using some > Transliteration scheme or Inscript KeyBoard layout convert it to font For collecting data on Indic scripts, we had created an interface that uses Java. I had used ITRANS transliteration and the default java fonts to come up with an input window that accepts transliteration in Latin script and outputs Devanagari on another window. I am not familiar with CMS or *nuke - but with what I gather reusable java classes could be a good way to look at it. We can develop classes to work with other languages - Right now, the tool might be a bit bulky to work with since the package has a lot of Image Processing related code to go with it. But its' good to test offline - Ppl can take a look at it here - www.cedar.buffalo.edu/ilt If its' useful, we can plan to make the input system independant of the IP part - > http://www.wandel.subnet.dk/hindi.html I tried the site out - it didnt need applets - but it didnt work on netscape either - gave me a message saying it needs windows to work with but then behaved OK on mozilla. :) :( What it is doing is - it takes the unicode value for the character, converts it into int and this is what we can do with the o/p - <html> उऊक़ख़ </html> But since what it is in the background is basically unicode, we still need a *properly configured* browser to view the stuff - It came out properly on Mozilla, didnt show up on netscpape. Pretty nifty - but the addition of transliterated/keyboard based input might be more welcome. The characters present in the interface are the ones from the unicode table for Devanagari. Bye, Surya __ __ |__ |__| |/ __|urya |rakash |\ompalli Email - kom...@cs... Phone - Home - (716) 834 6859 - Work - (716) 645 6164 X 519 Website - http://www.cse.buffalo.edu/~kompalli On 5 May 2003, Arun M wrote: > Hi Friends, > > We see a lot of community portals coming up these days based on > CMS like *nuke. But one of these CMS supports Indic. Also we dont see > any community discussion boards in Indian languages (Pls correct me). > > Some issues I see are: > > - There is no indic(Unicode/Non unicode) support in most platforms. > - Most browsers doesnt support unicode. > > Any community portal we build should be based on font encoding > systems, at least for some more time. A idea is store > the data in Unicode and then convert to font encoding at the server > side. A special proxy should help here. > > Second issues is entering data from the client side. This is major > prob. Most of the sites uses Java applets for entering the data in > local languages. This may require good amount of modification in the > CMS we have now like *nuke. > > Yesterday I made a proto of this. A crude one. It works. > > Do you think this will be of use ? If so I will work on it and > make the code better and generic(I dont know Javascript much , will have to > learn it first). > > > Arun. > > > |
|
From: Guntupalli K. <kar...@fr...> - 2003-05-05 11:27:37
|
On Sun, 4 May 2003 21:39:21 -0700 "Tapan S. Parikh" <ta...@ya...> wrote: > > I certainly think this will be of huge value. Input methods are on > the client have been a huge hurdle and often forces clients to go to > Windoze XP over other platforms like Linux or even (gasp!) Windoze > 98. I didnt realize this would be possible using javascript, if so > I am wondering why noone thought of it before. > Sites like epatra.com have used it before, but they used to send the text to the server to get the glyph codes (they couldnt have it all in JS else nyone else would have easily copied it for own sites ). There are some convertors from ISCII -> ISFOC , shusha etc, which can be used. See http://www.iiit.net/ltrc/FC-1.0/fc.html Regards, Karunakar -- "Twenty years from now you will be more disappointed by the things that you didn't do than by the ones you did do. So throw off the bowlines. Sail away from the safe harbour. Catch the trade winds in your sails. Explore. Dream.Discover." - Mark Twain --------------------------- * Indian Linux project * * http://www.indlinux.org * --------------------------- |
|
From: <al...@ya...> - 2003-05-05 06:27:33
|
> > We see a lot of community portals coming up these days based on > CMS like *nuke. But one of these CMS supports Indic. Also we dont see > any community discussion boards in Indian languages (Pls correct me). http://groups.yahoo.com/group/linux-bangalore-hindi/ Well, not exactly a discussion board, but a mailing list. Wonder if you have seen this(doesn't need applents but is of course still not the perfect input method): http://www.wandel.subnet.dk/hindi.html > Some issues I see are: > > - There is no indic(Unicode/Non unicode) support in most platforms. > Something about the social aspect of using Indic scripts on the web: While these are valid points, the browsers most people use do support unicode.(all right flame me but face the truth first!) Unless the existing users, who use English, start using Indic languages in mailing lists and boards, users who don't know English very well are not going to get much encouragement either. Developing a user base is crucial because that's where future developers would emerge from. > - Most browsers doesnt support unicode. I think most of them do, thanks to CJKV. What they *don't* support is indic script rendering. > Arun. > > > > ATTACHMENT part 2 image/png name=Screenshot.png ===== Contribute to http://indic-computing.sourceforge.net +91-80-653-8200 http://groups.yahoo.com/group/linux-bangalore-hindi/ Can't see Hindi? http://geocities.com/alkuma/seehindi.html http://9211.blogspot.com Set View->Encoding->UTF-8 à¤à¤ªà¤à¥ सà¥à¤à¤¾à¤µ शà¥à¤à¥à¤°à¤¤à¤¾ सॠतà¤à¥ सà¥à¤µà¥à¤à¤¾à¤° हà¥à¤à¤à¥ à¤à¥ à¤à¤¬ à¤à¤ª à¤à¤¨à¥à¤¹à¥à¤ लाà¤à¥ à¤à¤°à¤¨à¥ à¤à¤¾ बà¥à¤¡à¤¼à¤¾ à¤à¥ सà¥à¤µà¤¯à¤ à¤à¤ ायà¥à¤à¤à¥à¥¤ ________________________________________________________________________ Missed your favourite TV serial last night? Try the new, Yahoo! TV. visit http://in.tv.yahoo.com |
|
From: Tapan S. P. <ta...@ya...> - 2003-05-05 04:38:22
|
I certainly think this will be of huge value. Input methods are on the client have been a huge hurdle and often forces clients to go to Windoze XP over other platforms like Linux or even (gasp!) Windoze 98. I didnt realize this would be possible using javascript, if so I am wondering why noone thought of it before. -- Tapan On 05 May 2003 10:07:54 +0530 Arun M <ar...@fr...> wrote: > Hi Friends, > > We see a lot of community portals coming up these days based on > CMS like *nuke. But one of these CMS supports Indic. Also we dont see > any community discussion boards in Indian languages (Pls correct me). > > Some issues I see are: > > - There is no indic(Unicode/Non unicode) support in most platforms. > - Most browsers doesnt support unicode. > > Any community portal we build should be based on font encoding > systems, at least for some more time. A idea is store > the data in Unicode and then convert to font encoding at the server > side. A special proxy should help here. > > Second issues is entering data from the client side. This is major > prob. Most of the sites uses Java applets for entering the data in > local languages. This may require good amount of modification in the > CMS we have now like *nuke. > > What about Javascript ? When user types in a text field using some > Transliteration scheme or Inscript KeyBoard layout convert it to font > encoding scheme and show Indic on the fly. Data will be posted to CMS > based on unicode or font encoding scheme. Theme change should be > sufficiant get *nukes support Indic(I've not looked into *nuke code in > detail. Just a guess) > > Yesterday I made a proto of this. A crude one. It works. > > Do you think this will be of use ? If so I will work on it and > make the code better and generic(I dont know Javascript much , will > have to learn it first). > > > Arun. > > > |
|
From: Arun M <ar...@fr...> - 2003-05-05 04:33:52
|
Hi Friends, We see a lot of community portals coming up these days based on CMS like *nuke. But one of these CMS supports Indic. Also we dont see any community discussion boards in Indian languages (Pls correct me). Some issues I see are: - There is no indic(Unicode/Non unicode) support in most platforms. - Most browsers doesnt support unicode. Any community portal we build should be based on font encoding systems, at least for some more time. A idea is store the data in Unicode and then convert to font encoding at the server side. A special proxy should help here. Second issues is entering data from the client side. This is major prob. Most of the sites uses Java applets for entering the data in local languages. This may require good amount of modification in the CMS we have now like *nuke. What about Javascript ? When user types in a text field using some Transliteration scheme or Inscript KeyBoard layout convert it to font encoding scheme and show Indic on the fly. Data will be posted to CMS based on unicode or font encoding scheme. Theme change should be sufficiant get *nukes support Indic(I've not looked into *nuke code in detail. Just a guess) Yesterday I made a proto of this. A crude one. It works. Do you think this will be of use ? If so I will work on it and make the code better and generic(I dont know Javascript much , will have to learn it first). Arun. |
|
From: Krishnamurthy N. <kn...@ya...> - 2003-04-28 10:47:51
|
Hi Alok, --- Alok Kumar <al...@ya...> wrote: > http://web.mit.edu/afs/sipb.mit.edu/user/aatharuv/projects/xindic/ > Just want to know if any of you have tried this. > Thought I will immediately reply, but forgot. I took a look at the source code of libxindic. IMHO, the author seems to have fallen into some of the very familiar traps. Here are my observations : 1. The author doesn't make a distinction between script and language. This is subtle, but very important. 2. The author assumes a direct 1-1 mapping b/n Unicode character code points and glyphs of the currently active font in X for the current 'Display', which is again wrong. 3. The author hard-coded glyph composition methods for various scripts (to whatever extent he understood the languages and scripts he attempted to implement) into the source code itself, which again is a very bad practice. Overall, you could just play around with it but it's far from becoming a generic base for Indic X app development. regards, Nagarajan __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com |
|
From: Dr. U.B. P. <pav...@vi...> - 2003-04-25 04:53:58
|
Dear all Indians, Very often I read people refering to Indian languages as vernacular languages. This was the word used by British while refering to the languages used by Indians, Africans, etc. meaning the language of slaves. Please check the Webster meaning of the word at http://www.m-w.com/. You can find out yourself. I have attached below the meaning of the word vernacular from the above site ------------------------------------------------- Main Entry: 1ver=B7nac=B7u=B7lar Pronunciation: v&(r)-'na-ky&-l&r Function: adjective Etymology: Latin vernaculus native, from verna slave born in the master's house, native Date: 1601 1 a : using a language or dialect native to a region or country rather tha= n a literary, cultured, or foreign language b : of, relating to, or being a nonstandard language or dialect of a place, region, or country c : of, relating to, or being the normal spoken form of a language 2 : applied to a plant or animal in the common native speech as distinguished from the Latin nomenclature of scientific classification 3 : of, relating to, or characteristic of a period, place, or group; espec= ially : of, relating to, or being the common building style of a period or place - ver=B7nac=B7u=B7lar=B7ly adverb Bottom of Form 0 ------------------------------------------ I humbly request all patriotic Indians to refrain from using the word "vernacular". 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 |
3 messages has been excluded from this view by a project administrator.
