[fitz-dev] display tree models

[tor]

Hi Raph et al.

I've given some thought to various ways to represent the page tree.
There are two wildly different representations that I think are fairly
good.

The first is my original proposition from way back, where the nodes are
graphical objects and all attributes are inherited from parent. This one
would have nodes such as Path, Text, Image as graphical objects. Attribute
setting nodes such as Transform, Color, LineAttrs would override the
graphics state used for their children. Clipping would be a special case
node, as would PDF 1.4 transparency...

The special cases talk against it, but there are some advantages because
it matches the PDF graphics model better in the case of XObject forms and
Type3 fonts.  Extra care is needed in the caching system, because the
way a node is rendered depends on the attributes inherited from above,
so the gstate needs to be part of the cache key.

The second is a distillation of our talk about thinking of the tree
as a functional program from yesterday. I'm not sure if it holds up,
but I thought I'd bring the idea up for discussion, because I find it
strangely appealing in its simplicity.

At the core of the model are abstract images, not the bitmap kind. The
nodes of the tree are functions that take zero, one, or more arguments
(which are images) and produce a new image.

Node types Path and Text produce an image which masks the area covered,
and take no arguments. Color produces an image of a solid color.
Transform takes one image, applies an affine transform on that image
yielding a new image. In and Over are compositing nodes that take two
(or more) images, combine them a la Porter-Duff.

The images have, as an optimisation, a bounding box. All source nodes
(the ones with no arguments, that only produce data) have natural bounds,
except Color which is unbounded. In intersects, and Over unions. Transform
transforms :)

[see attached illustration for an example of a display tree]

A renderer would of course do various optimisations when rendering, such
as keeping the transform as a graphics state passed down when rendering
child nodes, and getting rid of intermediate images by combining various
operations and compositing, as when an In node has two children, a Color
and a Path.

How well would a scheme like this work with PDF 1.4 transparency?

-- 
55.7N 13.2E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fig1.jpg
Type: image/jpeg
Size: 13092 bytes
Desc: not available
Url : /pipermail/fitz-dev/attachments/20031009/44b966d4/fig1.jpg