In our business we produce mostly one-page-size landscape documents (containing tables and graphics).
In my first implmentation I created these documents using OpenOffice/LibreOffice, which was slow, but the user had the chance to change the document afterwards – a nice feature.
But it was slow and LibreOffice (and its .NET interface) made some trouble for us. The OLE/.NET interprocess communication does not seem to be well tested by the developers and in some releases it works and in others not (as for example in the actual 3.5.0 release).
I looked for alternatives and of course PDF should always be considered in this area. Some postings ago I talked about producing PDF documents using libHaru with VASmalltalk under Windows. This approach is very speedy (though I do not need that speed) and much more stable than the OLE approach.
We generated some basic commands (Each command is an instance of a class. Commands are like “insert table”, “insert graphics”, “fill cell content” etc ..) to create the output we wanted to have. Smalltalk created the PDF documents according to these commands.
The tools generating the content of these pages are actually written in C#. We introduced the same commands in C#, filled those instances of classes with values (even the raw byte data of inserted images).
We serialized the commands via MessagePak and send those commands to VASmalltalk. “Executed” them there, produced the result and the pdf content was returned to the calling program. More on that later.
We realized very soon, that the MessagePak implementation for .NET is very powerful – but I got the feeling, that it was written in mind, that everywhere is .NET. They added features not available on other platforms – making it more time consuming to find these changes on other language platforms. Some missing features are still there (like support for byte output – which should be serialized as raw data and not as an array of bytes).
One of these packager helper classes available under .NET/MP creates on the fly (during runtime) methods for domain classes. Powerful, technical features showing what is possible under .NET. But what happens, if the binary stream is broken? Then those methods throw an exception and what shows the debugger under VS 2010? Exception thrown in external code – no source code available. More or less very difficult to debug. Therefore I do not use it any more. Took one day to find and implement the basic MP code to serialize the commands.
Now only the transport channel between C# and VASmalltalk has to be considered and I created a very special one:
I decided, that I wanted to use 0MQ (also mentioned in some postings earlier) – but in this special case I did it not in a direct way, but I transferred the MP (MessagePack) data via a special http server: Mongrel2.
The very special feature of the Mongrel2-http server is, that it communicates with application-servers via 0MQ. I wrote a Mongrel2 handler in VASmalltalk and now VASmalltalk is able to answer HTTP requests – actually without any need to load HTTP-code in VASmalltalk or even the SocketInterface. There is also no need for these SstAdapter instances … but I am still waiting for someone to make the glue code to use Seaside this way ( ;-))
Therefore now in C# we created a POST-“WebRequest” instance and added the MP data as the body of this request. Via HTTP, Mongrel2 and 0MQ the data enters the VASmalltalk world and a simple response (with the PDF binary data as the content of the answer) is returned (via 0MQ and Mongrel2 …).
Of course in an inhouse application I would (and have to) connect both applications using 0MQ directly, but this was also a nice try to introduce some WAN communication for services ….
Now I had the pdf document on the user side (under C# control) and thought about how to show the content to the user. I tried to use a WebBrowser control (from VS 2010) showing a local pdf file and that looked promising – but the user must have a specific software on his computer installed (e.g. some PDF Reader software) and I managed to crash this system while refreshing the PDF content too fast.
Then another idea came to my mind: how about using Ghostscript to convert this single page pdf file to an image and show this image within the user interface ?
The viewing of an image (with smoother AND faster scaling) can be done by nearly all GUI tools (even with VASmalltalk).
If you want to write such a GUI in VASmalltalk and have very fast graphical helper methods (smooth conversion and scaling) I would guess using my FreeImage wrapper for VASmalltalk will help you a lot here.
I introduced the VASmalltalk interface to Ghostscript already in an earlier posting.
In the following source code ALL pages of a pdf document are exported and converted to png files (smaller than jpg ones) with a resolution of 300dpi. The larger resolution is needed to have a smoother view on the screen. You may even try 600dpi – but then then viewer has to handle much more data (fast scaling !).
anArray := Array new: 8. anArray at: 1 put: '-dSAFER' ; at: 2 put: '-dBATCH' ; at: 3 put: '-dNOPAUSE' ; at: 4 put: '-sDEVICE=png16m' ; at: 5 put: '-dGraphicsAlphaBits=4' ; at: 6 put: '-sOutputFile=d:\temp\output\test_%04d.png' ; at: 7 put: '-r300'; at: 8 put: 'd:\input.pdf'. anInstance := MSKGSWrapper new initialize newInstance: nil. anInstance initWithArgs: anArray ; exit; deleteInstance.
Using additional parameters you may only convert specific pages of a pdf document.