I’m beginning a closed beta test of our new PDF Editor for Mac OS X - see posts below for details.
If you’d like to be included, please use the contact form on our front page, giving if possible a short explanation of the kinds of things you might do with such a product. Feel free to pass on this invitation to friends who might be interested.
Not very mac-like or slick yet, but the core functionality is almost there. The architecture for error handling and progress-bars between Cocoa and Ocaml is now complete.
Launch sometime later this year.
Here’s a screenshot of an early version of our next product, a PDF editor for Mac OS X:
The architecture is:
The C wrapper will also be used to release a plain C version of our PDF tools to go with the .NET and command line versions, but not until the bugs are ironed out by using the same code to write the OS X product.
It ought to be possible to produce a Windows version of the product using the .NET version of CamlPDF at some point in the future.
Alan Murta’s General Polygon Clipper is the standard way of finding the intersection, union etc. of polygons.
I wrote an Ocaml interface for this many years ago for a dead project, but I’ve only just got around to packaging it up for release. You can get it here.
I’ve just completed a PDF version of the Graphics module from the standard OCaml distribution, based on CamlPDF and following the conventions of Pierre Weis’ Postscript version GraphPS.
The implementation is mostly straightforward, but there are are some complications - some shapes (arcs etc.) need to be approximated from bezier curves sections, since they don’t exist as primitives in PDF (Oddly, circles and arcs are primitive in PostScript).
In common with GraphPS, it doesn’t yet support the bitmapped image parts of the Graphics module, though that would be easy to add.
Here’s a particularly luridly coloured example (source PDF here):
GraphPDF will ship with the next release of CamlPDF.
What might be nice for the future would be a single module shipping with OCaml which can be used as the ordinary graphics module would be, and then dump the result to PDF when required.
We’d need to extend the graphics module with the ability to optionally keep a list of all commands executed thus far, but that’s about all. Getting the PDF output into Ocaml would require some license work on CamlPDF, though, so won’t happen yet.
CamlPDF Version 0.4 has been released.
The biggest change is that this release now compiles with Microsoft F Sharp as well as with OCaml.
Some major non-compatible changes have been made to the low-level API, due to the experience of building large software with the library. These should be the last such changes, at least to the basic modules.
One of the changes is that many functions which used to take a Pdf.pdfdoc and return another one now modify the document in-place. This is rather un-idiomatic for a functional library, but threading all the documents through complicated functions in code using CamlPDF became wearying.
There are several new modules:
This release is about a third faster in general than the last one, due to profiling under .NET. Many bug fixes are included, and extra facilities for dealing with malformed PDF files.
CamlPDF is in commercial use in our Command Line PDF Toolkit and PDF Toolkit for .NET.
We have to generate the following things from our OCaml codebase:
(a) Command Line PDF Tools for Windows, Mac, Linux and Solaris, demo and full versions
(b) .NET DLL by compiling with F#, demo and full versions
(c) The open-source CamlPDF library
(d) The demonstration renderer and its GUI
(e) Literate Programs for all the code
So far all this has been achieved with just plain Ocaml and a couple of makefiles and the very useful OCamlMakefile. A little trickery is required to have demo and full versions compiled from the same source.
Soon we’ll add:
(f) Plain C Wrapper for the same library exposed to .NET
which will allow the PDF library to work natively from C on any platform where OCaml can natively compile. This wrapper will be a little harder to write than the .NET wrapper, since we have less rich types available to express the various ML data structures.
I’ve also been playing with Apple’s Cocoa with Objective-C, in preparation for a new PDF-related product for OS X. I’ll be linking in the new Plain C wrapper to that. Cocoa and Objective C is all object-oriented-kool-aid, but seemingly of the less gross kind. I’ll only be using it for the interface, where it seems to work.
This will be our first consumer rather than business product, so a whole new set of problems to deal with.
Our .NET PDF Toolkit, in 100% F#, cross-compiled with OCaml is now available, starting at £495. It does everything the command line tools do, and more, but is usable natively from VB.NET, C# and ASP.NET.
At the same time, we’ve updated the Command Line Tools (written in pure OCaml) with bug fixes and new features, and now provided for Solaris 10 Sparc and Intel out of the box.
The codebase of about 40,000 lines ended up requiring only 30 points at which conditional compilation was needed to cover the differences between F# and OCaml, though plenty of code had to be modified to compile in both environments in a way that didn’t require conditional compiltion.
There will be a new release of CamlPDF soon, which will have many new features, and which will cross-compile with F# out of the box.
We’re almost ready to release the .NET SDK version of our PDF Command Line Toolkit, and are looking for feedback.
This is the fruit of altering our OCaml codebase of about 20,000 lines to cross-compile with F# - a not entirely straightforward process.
Here’s the .msi which installs a demo version of the SDK:
http://www.coherentpdf.com/cpdflib.msi
Here’s the PDF of the user manual:
http://www.coherentpdf.com/cpdflibmanual.pdf
Installation is covered in Chapter One of the manual, and is simple.
I’m particularly interested in feedback from existing .NET developers, so do take a look, and you can contact us with your suggestions and criticisms either in the comments below or by email.
I wrote earlier about profiling F# code for memory usage. I’ve been looking at products for profiling speed, and have settled on JetBrains dotTrace for the forthcoming .NET release of our PDF tools. Here are a couple of screenshots profiling speed on our PDF library:
The speed increases achieved are partly F#-specific, but plenty of the changes made have speeded up the code when compiled with OCaml too.