Currently, there is no quick and dirty way to use opensource Java tools to convert Word Documents to PDF. So, to do this task I've been using BCL Technologies' Easy PDF. Since this application is written as COM, a java to COM bridge is necessary to use the SDK with Java. With Easy PDF 5.0, I had set up my own method of using the opensource tool Jawin to do this bridging. Now, I'm upgrading to Easy PDF 5.1 and they have a Jawin Java build included in their build, which I was pretty excited about. However, they built the jar with Java version 6, which I cannot use as we're stuck with Java 5 since we are dependent on Websphere (why would you not include more than one build with different java versions anyway? Whatever).
Since I had used Jawin before, I decided to attempt to do what we needed to do with Jawin, Java 5 and Easy PDF 5.1. The initial backwards compatibility with our code that was using Easy PDF 5.0 was smooth and simple - the build worked the same as I'd done before and no code changes were required.
Moving on to the new requirements, which is why we're upgrading Easy PDF. We needed to utilize additional features - merging two or more PDFs into one, splitting one PDF into two, deleting pages from a PDF, adding a watermark to a PDF. I rebuilt the code with Jawin to use these new features. And, there were difficulties. This is more of a complaint about Jawin than about Easy PDF.
Jawin is a great idea and on the surface (at least for my purposes), easy to use. However, the current version is an alpha version, and hasn't been released in several years. The real problem using it came from trying to use the Variant object. Documentation for how to use this object is spotty. Examples in the sample code are non-existent. Internet searches brought back a couple of threads, but most were just people asking the same questions that I had and not getting any answers.
Trying to create a Variant object was my first problem. I ran into multiple issues, and I was simply trying to pass something an array of Strings. That should not be as difficult as it was. I did get the "org.jawin.COMException: 8000ffff: A VT_VARIANT must be combined with VT_BYREF (base vartype 12)" yesterday, when trying to use myvariant.vt = VarTypes.VT_VARIANT or even using VarTypes.VT_BSTR, which is what I thought I was supposed to be doing. It is difficult to comprehend WHY we are putting things into a stream in order to make them into a variant, and how to get them out again.
So, I finally followed this guy's advice, which I found this morning. I overrode the class that was generated by the type browser. Instead of creating a method that accepts a Variant that is an array of strings, I created a method that just takes an array of strings and still invoked in the same way that Jawin was doing. And guess what? It worked! So, why does the typebrowser create the Variant method in the first place?
I wish the Jawin folks would continue to work on their project and get some of these bugs fixed. It's a great product with a lot of hope, but it needs help and it needs to be more user friendly to those java folks out there who don't know COM.
Java tips and tricks from a lady trying to play with the boys...
Wednesday, July 9, 2008
Subscribe to:
Posts (Atom)