vteindic — Source code Released on sourceforge

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.

Leave a comment

Posted by on May 3, 2011 in Project


Indianization of GNOME-terminal: 1st runner up at PSPL project fair

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

1 Comment

Posted by on May 3, 2011 in Project


VTE with Devanagari Support Releasing Soon

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.


Posted by on April 8, 2011 in Project


Detailed Exploration of the Problem in VTE

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

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.
Leave a comment

Posted by on March 31, 2011 in Project


Experiencing The Virtual Terminal Emulation

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.


Leave a comment

Posted by on March 31, 2011 in Project


Devanagari support on GNOME Terminal


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.

Previous VTE

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.

Updated VTE

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 gone through bugs 584160 and 321490 and some related bugs at gnome-bugzilla as suggested by Behdad(Developer of VTE). That helped us to exact part of the code that is used for the rendering.

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.

Probable solutions
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.

Project Group

1. Kulkarni Mihir (

2. Kulkarni Swapnil (

3. Dige Sourabh (

Project Guide

Prof. Abhijit A.M. (College Of Engineering, Pune).

Thanks to

Pravin A. , Pravin S. , Behdad.


Posted by on January 6, 2011 in Project