Team Blog

Pali Text Reader - behind the scenes 



In case you happen to implement a F11 browser like "fullscreen" feature in your c# application and wonder, why you can't get on top of a fixed windows task bar: I knew only one application which got it right (Sharpdevelop) and when i looked up the code, i found a little note from one of their developers mentioning a bug in the .NET framework. In order to really get topmost on a windows desktop you have to implement a fullscreen like this: 


            Visible           = false;
                FormBorderStyle   = FormBorderStyle.None;
                WindowState       = FormWindowState.Maximized;
                Visible           = true;


It's the "visible" property which finally does the trick.



Today, i finished the commentary switcher's proof-of-concept. We are still missing a matching class which knows which mula text matches which kind of commentary/subcommentary, but that is not the tricky part. so i started with the tricky part :-). I hardwired Majjhima Nikaya1 and its commentary as being related into the code. As you know, we got the current paragraph number already earlier (see below). So, what was missing, was simply to open the corresponding commentary next (not much today here, just overload the PaliViewers constructor a bit to accept paragraph "jump to" whiches. But how to implement such a "go to" functionality in the IEs DOM? It was quite simple after all. We just get a ihtmlelementcollection on the ihtmldocument and step through the collection of <P> tags. Now, considering each ihtmlelement the collection returns we check its innerHTML and when the paragraph we were looking for comes along we trigger a "scrollIntoView" method of the current html element. And guess what? it works! Whenever you find an interesting part in the pali document and right click selecting "see commentary" in our custom  context menu, it magically opens the commentary text and jumps right to the paragraph in question. Nice! Next comes the even more important Boyer-Moore search implementation. Lots of open questions there, but not on the very fast algorithm, but on the space the corpus takes and how to limit the download package... 




Today, i am working on the switch mechanism from mula text to commentary. Its much easier after yesterday(night)s implementation of a google toolbar like word based translation mechanism. It sits inside the PaliViewer control, which hosts an IE control. After successful page load, i set up an event handler. On the mouse move event, we do some pretty stuff:

PTR's plugin architectures allows for the following to happen: the onmousemove event fetches the current word, the cursors sits upon (i used some javascript code as an example and ported it over to c# way of doing stuff) - then, an event is triggered. The workbench, which is a framework for the entire application, consumes this event and delegates a silent lookup on the pali dictionary plugin. The plugin does its lookup silently (showing no window, that is) and returns its found entry to the paliviewer (through the event mechanism). The PaliViewer show the answer via a title on the html element - voilà!

Fine thing: all 3 components taking part are loosely coupled.

 The switch works similar, but here i simply get the innerHTML and make a substring to extract the paragraph numbering. The paragraph counter is then submitted in case someone right-clicks on "switch to commentary". 

Of course, next thing will be  "manage" class, which knows which commentary to invoke based on which mula text. But thats tomorrows story...




Some more weeks have passed and our dear Pali Text Reader project is yet not mature enough to be dubbed "BETA". However, there are basicly only two more steps to be taken and we can issue a first beta version: The book selector plugin has to allow access to all CSCD books (only a view are mapped right now - if you select others they wont open) and our search plugin (DotLucene seems to be the search engine at hand) has to work. By the way, new alpha release is out, for the eager ones to see for themselves. Check out the new screenshots on the dictionary plugin and TwoPageViewer!




I added another view option for each open book - its kind of a two page layout which should make reading a pali text much more pleasant and eye-friendly. Scrolling down a long daring body of print doesnt really inspire reading long passages at a stretch. The TwoPageViewer comes with its own rendering and will hopefully allow kind of a bookmarking mechanism




After a few months of "rest" the Pali Text Reader project is back on track. You probably already figured out that it is part of Sourceforge now. If not, you may want to check out the screenshot section there first. I have evenly distributed the entire development up to the first stable release into four seperate milestones. The Pali Text Reader has been so far entirely remodeled - it supports plugins for almost all major features - thus everyone is welcome to add missing functionality without having to "rebuild" the entire application. Project state is Alpha right at the moment with the Beta period starting at July 25th.




After much positive feedback for the PTReader's project goal from Frank Snow and other Pali Group members, i decided to host PTReader at Sourceforge. Due to my Pali Wikipedia engagement lately (which lead to some other pali tools in due course) i will need some time to refurbish and refactor PTReader's source a bit before sourceforging it. Check out for news soon!