Thread: [Indic-computing-devel] Re: [smc-devel] FW: Malayalam Cillaksharams (was Ya-phalaa)
Status: Alpha
Brought to you by:
jkoshy
Menu
▾
▴
indic-computing-devel
|
From: Baiju M <bai...@ly...> - 2003-03-06 09:22:39
|
If none of ZWJ and ZWNJ is specified after a virama it should be rendered as an explicit virama. ie., NA + VIRAMA (should render as NA+VIRAMA) If we are adopting the new Malayalam Inscript layout propsed by Kerala govt. (which has got single keys for 5 chillus ), Inputing chillus will be very easy (It can impliment very easily by using Compose keys in GNU/Linux) Regards, Baiju M On Wed, 5 Mar 2003 22:09:51 Andy White wrote: >"This is part of the improvements to [the] Unicode [Standard] that have >been made for [Version] 4.0" > >[...] >> To reiterate our consistency in using this model, I will give you a >> Malayalam example. >> >> NA + VIRAMA + MA --> NMA (a single conjunct) >> NA + VIRAMA + ZWNJ + MA --> NMA (with a visible virama breve >> above and between) NA + VIRAMA + ZWJ + MA --> NMA (with the >> cillaks.aram virama curl) >[...] >> Michael Everson > >I have always advocated the use of the above mentioned rendering rules >for Malayalam. However, people trying to Implement Malayalam in Unicode >have periodically asked on this list the question of how to encode >chillu forms. >Due to the lack of any official response, those implementations that I >have seen unfortunately do not follow the above rules. >***If you have such an implementation, Especially anyone responsible for >a rendering subsystem, please take note***. > >Andy > > > > >_______________________________________________ >smc-devel mailing list >smc...@no... >http://mail.nongnu.org/mailman/listinfo/smc-devel > _____________________________________________________________ Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year. http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus |
|
From: Arun M <ar...@fr...> - 2003-05-05 04:33:52
Attachments:
Screenshot.png
|
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: <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: 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: 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: 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: 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-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: 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: 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-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: 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 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: 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: 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...@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. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X