000007

Mozilla Plug-in Updated to the MuPDF 1.3 release

     Once again, I've updated  the code on my 'moz' branch, this time to the 1.3 tagged revision, only this time it means I'm up-to-date with the latest( for now) release, and only behind the most recent commits.This means it's high time I get off my lazy but, and get started on my own improved plug-in.
    As usual, I kept out of this updates improvements to features I don't support, and new features like progressive uploading and cURL support. The former means a total re-write to the plug-in code( and will eventually make it into my own plug-in), and the latter is unneeded, as the NPAPI of the plug-in handles URLs on it's own( though improvements are needed). On the other hand I updated the pug-in related rule in the makefile, so that the plug-in specific code gets built in it's own sub-directory.
     While making this latest update( specifically, while reviewing the exception handling changes commit), I realized that I had done a lousy job of handling password protected encrypted PDF files in my initial commit for the branch. I decided to leave that out of my plug-in update, as this specific update wasn't going t be used in the code as was, and fixing the password handling was separate from the actual plug-in update. I then updated the password handling in a new commit, applying the "exception handling changes" to it. Basically, I made it so that the plug-in returns an error if a password is needed( as the plug-in does not support password protected PDFs). Also, while at it, I made sure the plug-in returned on error( fixing another oversight of my initial commit).
    Code of the latest commit is here.

000006

Mozilla Plug-in Updated to the MuPDF 1.2 release

     Once again, I'm updating the code on my 'moz' branch, this time to the 1.2 tagged revision.( Now only one release behind the upstream branch.)
     As with my previous update, I avoided supporting interactive and PDF forms related improvements. What I did do was implement the changes made by eliminating the fz_bbox structure, and those made by passing structures to and from functions by pointer. Also, I noticed that some of my internal functions were still not being declared as static, so I fixed that as well( in a separate commit).
     My updated code is available here.

000005

Mozilla Plug-in Updated to the MuPDF Technology Preview release

     As the title suggests, I've just updated the code on the 'moz' branch of my MuPDF fork to support the 1.1-forms-tech-preview revision of the library( It's still two releases behind the upstream branch).
     I actually decided to not support almost all the new features to the library that the release was meant to showcase - the interactive features like form filling, JavaScript and transitions - because, as I said in a previous post, my intention with this branch is to have the same basic plug-in as the one that was available with the 0.3 release, without all the new features added to the library and viewer since the 0.3 release. Also, I left out adding the colorspace entry as I saw no need and use in manipulating that variable.
     What I did update in the plug-in, beside merging the '1.1-forms-tech-preview ' tagged commit in, was to apply the use of a separate display list for PDF annotations, and change the warning function to use a safer string function. With the last one, I considered doing the same for the error function, but as it only gets used once in the plug-in, is a bit of a bother to implement, and the equivalent wasn't done for the viewer, I decided to leave it at that.
     If you want to take a look at what I've done, you can do so here: commit b4c1fa624c... .

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.

000001

My Inaugural Post

I've decided to start this blog, to chronicle my adventures in programming. I have a list of project ideas that I want to get working on, that I'm listing here.
    My initial set of intended projects are to provide plug-ins/extensions to replace Adobe's PDF and Flash Mozilla plug-ins with open sourced ones, based on existing libraries, preferably written in C( which is the programming language I'm most familiar with). for rendering PDF's, I'm intending on using the MuPDF library, already used as the back-end for Sumatra PDF, updating it's very outdated Mozilla plug-in. For Flash I'll use the Swfdec library and it's already-existing Mozilla plug-in, porting both to the windows platform.
    In researching for these projects I've come up with more ideas for projects, to support and extend, in the future, my intended plug-ins:

• To extend the plug-ins to full blown extensions.
• To extend the MuPDF library to be able to render other document formats( such as MS Word's .doc, and .djvu). Also I want to change certain parts of the library( like separate the lbfitz module from the others, and make libmupdf, libmuxps and the others separate modules).
• To create a MIME-type-plug-in associations manager extension( that will aim at working around Bug 19118, and related bugs).
• To create ActiveX controls for all the above( including a plug-in hub and manager, for using Mozilla plug-ins in Internet Explorer)

    Besides replacing Adobe's plug-ins, I have other unrelated idea's that I want to pursue:

• An Opera extension to show Hebrew Biblical verses with cantillation marks in a font that supports them. Though something like תּוֹרָ֥ה צִוָּה־לָ֖נוּ מֹשֶׁ֑ה מוֹרָשָׁ֖ה קְהִלַּ֥ת יַעֲקֹֽב׃ is properly viewable in Firefox, in Opera ( and in Internet Explorer and Safari, as well) it isn't. I would like to change that. [Edit(11-10-2013): That shouldn't be necessary now, as cantillation marks seem to show well now in Opera, and in Internet Explorer as well for that matter]
• A program that allows Windows program to be run( and seen and interacted with) in a Cygwin/X window( something like the XOpenWin project, that never took off).

    I think that will do for now. I'll post more about these project ideas, and other programming related things,  as they develop.