Coherent Graphics Ltd

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:

• PDFSpace (Parsing Colourspaces)
• PDFText module extended for more encodings and better text extraction
• Cff module (Parse Type 1 fonts and convert to Type 3)
• PDFMarks (Bookmark handling – unfinished)
• PDFAnnot (PDF Annotations – unfinished)
• PDFGraphics (Structured graphics – unfinished – included only because Cff uses it

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.

PDF Command Line Tools 1.3 now out, with new features for fonts, better splitting by bookmark, and dozens of smaller improvements.

There will be a new release of CamlPDF in the next few months. It will be somewhat backward-incompatible due in part to the changes required to get it cross-compiling with F#, and partly due to some redesigning due to experience.

New modules:

• Pdfspace: Colourspaces
• Cff: Parse Type 1 Compact Format Fonts


and graphic_elt =
| Path of (path * path_attributes)
| Text of textblock list * textblock_attributes
| MCPoint of string
| MCPointProperties of string * Pdf.pdfobject
| MCSection of string * graphic_elt list
| MCSectionProperties of string * Pdf.pdfobject * graphic_elt list
| Image of image_attributes * int
| GraphicInlineImage of Pdf.pdfobject * bytestream * Transform.transform_matrix
| Clip of path * graphic_elt list
| Shading of path option * shading * Transform.transform_matrix

and graphic =
{elements : graphic_elt list;
fonts : fontname list;
resources : Pdf.pdfobject}


I’ve been turning our cpdf PDF command line tools into a .NET DLL by cross-compiling it with F#. Here are a couple of screenshots of editing code using the library in C#.

And here are a couple of screenshots of Microsoft’s CLRProfiler which profiles garbage collection and memory usage.

There’s a lot more work to be done on speed and functionality, but I’m hoping to have it out by the end of November. A new release of CamlPDF which cross-compiles with F# will be released shortly after. There’s a lot of new stuff in CamlPDF too, especially text support.

Dear Customer,

Attached is the software for which you paid several hundred pounds. It should work. Maybe on larger inputs it will fail. Sometimes several small parts of it will work, but when you put them together it will fail.

You see, there’s a maximum input data size for which it works. I don’t know exactly what that is, and it may vary according to your platform, configuration, or the day of the week.

On some platforms it might fail cleanly, on some it might segfault. We’re not sure.

(Our codebase is entirely tail-recursive, but people I’ve mentioned this to in passing seem to consider this an extreme position, citing loss of speed. Really?)