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.
Monthly Archives: March 2011
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.