Making PDF rasterizer extensible - First design meeting

12/11/2012 By Frank 0 comments

Starting with version 4.0 of PDFRasterizer.NET, we will make our PDF render engine extensible in the sense that you can plug-in your own output device. This should enable developers to render (or convert) PDF to e.g. SVG, HTML5 or something else. This also serves an internal purpose; conversions that we already offer (e.g. render PDF to a GDI bitmap or XPS) will be implemented using this same plug-in API.

This article reports about our first design meeting. Much of what is included here will evolve over time. We will make small iterations and implement mutliple output devices to continuously validate the plug-in API. We will try to release these iterations as often as possible. To join the beta program, send a request to We welcome any feedback obviously.

the whiteboard notes:



The starting point of the plug-in API will be the OutputDevice class that must be specialized (inherited). It represents the device/format to which you want to render. By overriding a set of methods you implement your own output device (class MyOutputDevice). These methods will likely fall into one of two categories: 1. resource factories and 2. drawing methods. We will make the model such that you may choose to not implement everything and rely on the base class to simplify things if desired. A typical example is to not draw glyphs but rely on the base class to convert them to paths and render those instead. Another example is to support RGB only and have the base class do the color conversions for you.


The PDF imaging model includes the following resource types:

  • Paths
  • Fonts
  • Images
  • Color spaces
  • Colors
  • Patterns
  • Shadings
  • Groups

The OutputDevice class has virtual methods that return instances of these resources. These resource factory methods will be called when the given resource is required during rendering. The API model includes a base class for each resource type. The implentation of the override returns a specialization of the resource (e.g. SvgFont). If the resource is not supported, the virtual is not overridden.


The second category of methods are the drawing methods. These are virtual methods of OutputDevice and can be overridden in MyOutputDevice. The drawing methods include at least:

  • DrawText
  • DrawPath (stroke and fill)
  • DrawImage

When these methods are called, the corresponding resources (e.g. Path when DrawPath is called and Font when DrawText is called) will either be passed with the method, or it will be accessible through the graphics state. This is yet to be decided.

Graphics State

Like many other imaging models, PDF has the notion of a graphics state. Here is part of what is included in the graphics state:

  • current transformation matrix (CTM)
  • current path
  • current font and font size
  • current color space and color (both for stroking and filling)

Operations inside a PDF document modify the graphics state in order to achieve the desired result when a drawing operation is performed.

How the graphics state will be part of the plug-in API is not sure yet. There several options:

1. We offer it as a base property of OutputDevice.

2. We offer overridables that will be called when the graphics state is modified. These methods can either be members of OutputDevice or of a class called GraphicsState that can be specialized.

3. We pass the relevant information to the drawing methods.

4. A combination of the three above.

Finally, there are operations that explicity save and restore the graphics state and there are operations that do this implicitly. This results in a stack of graphics states. Consequently, there may also be a property that reflects this stack while the current state is simply the top element of this stack.

Final words

As said, we will release iterations of the plug-in API in the coming weeks and months. To join the beta program, send a request to

Looking forward to your feedback!