We have released the source code of vteindic as sourceforge project. We are still fixing the issues in VTE.
The issues are not at all related to rendering but other processing. We are about to finalize the complete
documentation of the project, and will be released soon.
Author Archives: Indic Language Computing
We have released the source code of vteindic as sourceforge project. We are still fixing the issues in VTE.
Our project “Indianization of GNOME-terminal” stood 1st runner up in the project fair organized by PSPL. The unique thing about our project was that, our project was the only FOSS project on platform “GNU/Linux” and released under GPL license. It was quiet encouraging for us. We had never participated in such fair before. Project fair was organized by PSPL. There were around 40 projects participating from 16 different colleges. Each project was one of the top three projects from that college. We were fortunate that we were representing our college as one of the top three project. We started with great enthusiasm, explaining each person all details of our project.There was a lot of demand from visitors to know about project. We never hesitated in explaining the project. As our project was different from other projects, we had to explain our project with all minute details like why there is rendering problem in GNOME-terminal, what is rendering engine, working of terminal emulator, our work etc. We were talking continuously for almost 7 hours, had no chance of rest. We were very much glad to see the response from the visitors to our project. All the visitors loved our project very much and their feed-backs were awesome like “Great job”, “Nice project, and nice implementation”, “We also have similar problem, and your implementation will help our project to solve our problems”,etc.
Evaluation process of the project was a three round process.First round was elimination round where top 10 projects among all were selected.Evaluation was done by experienced professional people and professors from various colleges. In first round of evaluation process, various testcases like rendering complex Devanagari words, Sanskrit words, etc. were designed by the examiner and our project was tested against those testcases. After that our project was selected for the next round of evaluation process. In the second round of process examiner asked about the generality of the project, i.e. whether the implementation can be generalized for other languages. We explained the examiner how we have generalized the implementation for other languages. The examiner was very much delighted on our project and our work. Final round of evaluation was the minute level implementation. Examiner was very well known about the problem, the process of rendering in the terminal. He asked about the algorithm of implementation, how the rendering of Devanagari script is implemented as it is very dynamic in nature,etc. We explained our finite state machine implementation for the project, how the inter-cell interaction works for this state machine, etc. We explained the rendering process in detail. Examiner was very much satisfied with our answers and the implementation. After all this process of evaluation our project was declared as the 1st runner up in the competition.
There are some issues yet to be fixed, but those issues are not at all related to the rendering. Rendering of Devanagari script is almost perfect and the prize we won is the proof for that. This prize have boosted our confidence.
When we started with the project we had no idea that whether it is doable or not, we have worked very hard to solve the problem and of course under valuable guidance of prof. Abhijit A.M. without which the project would never have got completed. Our next task is to solve the issues that are created due to changes in the rendering part in VTE, and we are sure we will fix these issues but we need help from the community for that.
Swapnil Sudhakar Kulkarni
These are the screen shots of the Devanagari support in VTE. We are in process of releasing it. We doing the documentation and testing part. We will be completing it soon.
Exploration of Problem as per discussions from Bugzilla In Gedit, the whole text is rendered as a single unit, as it's proportional by nature. So, the rendering engine is free to interact between character cells, including reordering and composing conjuncts as required by Indic and other CTL scripts. Terminals, on the other hand, are display grid, where individual characters are put in grid. And the grid cells are independent of one another. That's how it works from the beginning. This is fine for Latin and CJK, and probably for Thai-Lao with typewriter convention applied. But it needs a tremendous change to support complex text like Indic and Arabic, where adjacent display cells must interact with one another. So, such deep structural change is not an easy task. It even deserves a redesign. One solution can be rendering the Indic languages can be doing it in a way that our traditional typewriters do. We followed this Idea and pursued this idea for implementation. Problem exploration at Code Level: I am not explaining the exact code path, I will explain it later posts, but I am explaining the VTE internals at higher level. Whenever a character is to be inserted onto the screen there are event handlers for key press, key release and for output from process to be shown. These are taken in chunks. These chunks are queued and then processed. Information regarding the chunk of data is computed i.e. number of Unicode characters, length of the chunk, sequence handler,etc. It then it calls the insert_char function. In code view as per our convention, insert_char is lower level code and actual rendering call cairo_show_glyph is at higher level. So at lower level,character is inserted in the respective fixed width column of the screen and cairo_show_glyph call does the rendering on that column at higher level. So now the "deadlock" problem occurs. Rendering of Indic languages require variable width cell structure. Variable width can be handled at higher level which we have tried to implement with partial success. When variable width is implemented in higher level lower level doesn't know about the variable width structure, because it is designed for fixed width cell structure. It does all the processing as fixed width character cell. And we can't vary the cell width at lower level. I also tried with integrating the pango calls for rendering, but the same loop problem persists. I am trying my best to solve the problem.
For last three years we were playing with small programs and debugging them. I don’t remember that I have written a code of more than 2000 lines. And then we are in a situation of playing with giant,complex code of almost 37000 lines with full implementation of object oriented, event driven, programming concepts in C language and gtk.
For last 3 to 4 months, we were in process of making the perfect rendering of complex script in VTE. Initial help from Behadad was quiet useful for us, that made us quick implementation. We did this in December’10.
Partial implementation of rendering in VTE (as explained in earlier post) made us, thinking positively about the perfect rendering of complex script in VTE. So we started with more minute and finer details of VTE rendering process and finding the way where it can be done.We went through all code paths and processing part related to rendering process in VTE. As Behdad, the author of VTE also didn’t know about how complex rendering can be implemented in VTE we didn’t get any further help from him, so the only way we had was, understanding the code, thinking of the solution and try to implement it. Though this trial and error method was not good, but for this we felt it right. So we have been doing a lot of trial and error methods for implementation.
Firstly, we started with thinking of replacement of cairo_show glyph_call which is for fast rendering with higher level pango library call for complex rendering. For this we gone through pango library manual, Cairo manuals,gtk manuals,etc. We wrote dummy programs to understand working. So I created a coverage that is used for rendering the Devanagari script. As we are working in parallel on different approaches other team mates are working on the variable width adjustments of characters. To achieve this we have divided the main task into small tasks and are trying to implemented it. In further blogs I will be explaining the VTE-Internals as per our understanding.
We are Currently working on the Devanagari support on GNOME terminal as our B.Tech. project. Gnome terminal is vital and commonly used application in Linux. There are problems in rendering complex scripts like Devanagari. Our work deals with the improvement in rendering the Devanagari scripts. We have done part of it but facing some problems.
The following screen shot we had taken before making changes to the Virtual Terminal Emulator code. We typed the word “swapnil” on VTE and it rendered as shown in the screen shot.
The following screen shot is taken after we made changes to the VTE. VTE renders the Devanagari properly to some extent but not perfectly as in gedit or Open Office, etc.
Rendering in VTE
VTE is Virtual Terminal Emulator Library(version 0.25.1). Gnome Terminal uses this Library. VTE does rendering using pango and cairo. Pango and cairo support complex scripts but VTE is designed for fast rendering and for that it uses cell structure(grid of cells).
In VTE, each glyph is rendered on each cell. There is no interaction between the two cells. This works perfectly for the languages like English because it doesn’t require any interaction with adjacent cells. But in case of Devanagari we have to interact with the previous cells for composite characters or ligatures.
Work We Have Done
We started our work with reading source code of gnome terminal. We got some part of it. We came to know that gnome terminal is using virtual terminal emulator(VTE) library. So we focused on VTE source code.
We understood the rendering part of the code. We increased the inter-cell interaction. VTE was fixed for the zero-width characters(े,ु,ू,ै,े,etc) already we just extended it for non zero-width characters(ि,ी,ौ,etc.) and composite characters also. What we have done in this case is we append these non zero-width characters that require one complete cell and some part of the next cell depending on the width of that character and move cursor to the next cell due to which some space is left out empty that makes the word rendered in discontinuous manner.
We have uploaded the .diff files here. We have also added the comments that will help to understand the changes we have made and why those changes are made.
Problems that need to be solved
After the work that is done up till now there are some problems that are yet to be fixed as explained earlier. The problems that we are currently facing:-
1. The cell width needs to be adjusted properly for characters that require fractional widths (1.5 times cell width). This has been explained earlier.
2. We can not make any changes to the grid structure to vary cell size because grid structure is uniform and gets defined prior to rendering.
1. We can do this in the way as it is done in pre-edit. In pre-edit it stores the characters in the buffer and when the complete word is formed, it is rendered.
1. Kulkarni Mihir (email@example.com)
2. Kulkarni Swapnil (firstname.lastname@example.org)
3. Dige Sourabh (email@example.com)
Prof. Abhijit A.M. (College Of Engineering, Pune).
Pravin A. , Pravin S. , Behdad.