000004

My MuPDF Mozilla Plug-in: A Progress Report

     I've been getting busy these past few days moving forward with my MuPDF development plans, namely getting a Mozilla plug-in up and running. My eventual, though intermittent, goal is to build from scratch my own plug-in, but I've got some ways to even get there.
     As I wanted to be able to build my code with the MinGW toolchain, I first had to make sure I could build the existent GUI code, i.e. the MuPDF Windows viewer, with MinGW. Though it used to be possible to build the viewer with the provided makefile, today you can only build the commandline executables, or use Visual Studio to build the viewer. So first I set to getting that sorted out.
     To that effect, and towards the general goal of extending the MuPDF library, I set up my clone of their repository on GitHub, and got to work. I cloned the master branch only till version 1.0, as I was intending to start there implementing my changes to the library itself, and moved later updates to the 'upstream' branch.I created the 'mingw32gui' branch for making a MinGW buildable viewer, which I merge from the 'upstream' branch into, and update the makefiles as needed. And, once I had an initial code base for a plug-in ready, I created the 'moz' branch for it. Although I had initially planned to merge the plug-in code and the MinGW GUI code back into the master branch, and was held back mainly by not having made any progress on making the changes I wanted to the library itself, in the end I decided that even when I do make progress on the master branch, I'll leave the two out: the 'mingw32gui' is mainly there for making sure the base GUI code is is buildable under MinGW, and the 'moz' branch is there to measure the progress in my own Mozilla plug-in against. My plan now is to make my plug-in a separate project, and once it's up and running all I'll need from my fork of MuPDF is the library files to build it with.
     My original plan for the plug-in was to use an existing somewhat updated version of the code, add new include files from the npapi-sdk project, and update the whole thing to version 1.0 of the library, ready for my planned changes to the library itself. The "existing code" only got updated to version 0.8, and it turned out that the changes between 0.8 and version 1.0 of the library code made the updating the plug-in to version 1.0 a non-trivial task, to put it mildly. By comparison, updating all the way from version 0.3( the last stable release for which the upstream project had a DLL to download, and still maintained the plug-in code) would be cleaner and only slightly more complex. On top of that applying the new header files would mean rewriting some of the plug-in code to account for that change.
    As I said, in the end I decided to forgo updating the existing code into the plug-in I am intending, and instead take two routs. The one is update the code as is, using the original header files, so that I've got a working usable plug-in for my day-to-day use, and as something to compare my planed improved plug-in to. To that end, for my initial commit, what I did was compare the plug-in code( moz_main.c) and the GUI code( i.e. winmain.c, pdfapp.c and pdfapp.h) in version 0.3, and then reflected the changes in the GUI code, between version 0.3 and 1.0, back onto the plug-in code. To make things simpler for myself, I decided to leave out the new features that were added over that time( like the text manipulation stuff), and to present the same basic plug-in, just with an updated back-end. the rest of the plug-in code I copied as-is, with little to no updating, and added a rule to the makefile fore building the DLL, where my experience with getting the viewer to build came in handy.
     The second, as I mentioned above would be to start my own plug-in project( which I haven't yet), and implement in it any of the new features added to the library since version 0.3 as I would see fit( mainly: search for text, mark text, and copy it to clipboard). The new project would be written from scratch, and be based on the new npapi-sdk headers. To that effect, I have already started on creating a Windows basic plug-in( based on the Unix basic code), and am getting it ready to serve as a suggested patch for Issue 1( I've already, in preparing, stumbled upon an problem with using the headers under MinGW, submitted Issue 23 with a suggested fix, which got into the repository as r22). I have successfully built my windows basic plug-in both under MinGw and VS 2012 Express, but it's taking time getting the VS project files to a state were I'm comfortable sharing them, especially as this is my first time working with Visual Studio.
     The code on both the 'mingw32gui' and 'moz' branches build successfully for me and I use the plug-in in my browser. I haven't provided binaries for them, as (a) the MuPDF project already provides a Windows viewer, (b) They're both are more of a "proof of concept" code, and (c) the plug-in is still a little buggy and crashes sometimes, and I'm not really intending on improving it, as my main effort will be directed to my plug-in project, when it gets going.
     If you want to see how I'm coming along, check out my code at GitHub.