jPod

This comes to its full power when integrated in a feature rich, JavaScript enabled interactive application. All this features can be made available to jPod via the application level frameworks ( for example for handling appearances and actions).

Concrete implementations have to be provided by the application itself, as the heavily depend on the applications abilities (JavaScript) and interaction behavior.

Examples of such data structures that are no longer COS "primitives" (like strings and numbers) or "composites" (like arrays or dictionaries) but have already domain specific behavior are the date or rectangle object.

The CDS objects are implemented as wrappers on COS objects. Every change is reflected immediately in the implementation (COS) layer and vice versa.

Content streams define a page or form content, implemented using COSStreams with a specific format. The stream data is built using a sequence of content stream operators. The stream dictionary additionally contains resources referenced by these operators.

This package contains higher level abstractions of the COSStream representing a content stream, CSContent, CSOperation and CSOperator.

A list of all known CSOperators is provided with CSOperators.

A framework for interpreting content streams is provided with ICSInterpreter and ICSDevice.

This is not yet application level but also not pure "specification" level, so we put it here.

The most interesting class is PCContentStreamCreator, allowing to create CSContent via high level API calls. This class is used througout the PDF implementation for clean content construction and even higher level tasks, for example when it comes to cross rendering from HTML.

Every PDF document is finally composed using COS primitive and composite objects. These objects are aggregated to a COSDocument. The available primitives are

• Boolean: true or false
• Name: A special unique string like object, most often used as a key for dictionaries.
• Fixed: A fixed point real number.
• Integer: An integer number
• String: A string object

• Array: A dynamic indexed collection implementation.
• Dictionary: A associative (Map) data structure.

• Stream: A sequence of bytes, combined with a dictionary with additional information about the stream itself.

This implementation uses a special object representing "null", COSNull. A lookup in a composite will never return an ordinary Java null, always COSNull, so you are never forced to check (obj == null || obj.isFoo()). Another useful convention is the "marshalling" using the "as" flavor of methods. This methods will return either Java "null" or an instance of the requested type. These conventions help around the sometimes lazy implemented data structures of the PDF documents available out there.

In a COS structure, other standalone objects and substructures can be referenced. This is represented using COSIndirectObject. An indirect object is not returned by the standard accessors or iterators from composite COS objects, you will always receive the dereferenced COS object. To access the reference itself, you have to use the "basic" flavor of methods.

Based on these purely technical objects without PDF domain specific behavior the meaningful data types like "Rectangle", "Page" and so on are defined. This is reflected in the framework provided by COSBasedObject, the super class for all PDF domain objects. Only a few are defined directly in the COS level itself, the most of them are found in the "pd" package.

While this seems not to be too complicated, this implementation is a quite complex and powerful one, supporting things like

• update propagation
• lazy reading
• swapping
• state management (for example for simple undo)
• preserve COS invariants that in most implementations lead to failures in the resulting documents that are hard to debug, like constraints on containement, identity etc.

Performing an encryption from scratch for a document is currently not implemented.

This implementation is guided by the following rules:

• META class structure:
  Every PD class is accompanied with a META class defining META information and acting as a factory.
• Factory creation:
  The PD level object is created or looked up using the factory methods provided by its META class.
• Identity:
  A PD object is always 1:1 associated with a COSObject.
• COSObject and Java return types:
  The return types of the PDObject level methods are as follows: All "cos" prefixed methods reference back to the COS level and return COSObjects. All other methods return (or act upon) either higher level data structures like CDS or PD itself or plain Java objects.
• COSObject, COSNull and plain null:
  All methods with a COSObject in return signature will never return plain Java null, but COSNull. Methods that are already narrowed to a specific subtype, like COSName, will return either an instance of that type or Java null.

Serializing currently supports "full" and "incremental" writing.

Somebody around wants to do linearization??