[fitz-dev] transparency

tor andersson tor at ghostscript.com
Fri Nov 28 07:55:44 PST 2003


I read through the PDF 1.4 transparency chapter, and I'm fairly convinced
the current architecture with blend (in,over,...) nodes will work more than
well enough :) Care needs to be taken with how to implement knock-out groups.
Backdrops wreak havoc on the dependency graph though :(

Currently, where over has left and right children, the left is the
source object, and the right is the backdrop. Actually, right is the
list of objects below current source in the 'stack'.
This is a special case though, the backdrop needs to be supplied as
an argument to render() and needs the backdrop (backdrop + earlier stuff in
the stack) to be rendered to be complete before rendering the node.
Shouldn't pose a problem.

Transform nodes, clip nodes (in), and transparency groups (over, ...) just
fork out to the left of an over node:

a over ((in ...) over c)

See the tree building code in tiger.c. It works out to be a very nice
but extremely simple and flexible model that should take care of all
the quirky details in PDF by simplifying them all away. Generating
PDF from an arbitrary tree could cause some grief though, as it is more
general than the PDF imaging model, but it could be worked around
by abusing transparency groups in PDF 1.4 :)

Note about memory usage: a simple colored path in my model uses four nodes:

(over (in solid path) ...)

However, the nodes I envision are very lightweight. In my protoype I have
found no need for storing parent, reference counts or bounding boxes.

Blend nodes contain the tag + flags (4 bytes), op (enum),
left and right children (two pointers) for a grand total of 16 bytes
on 32-bit architectures.

Transform contains tag, 6 doubles and one pointer.

Color contains tag, 4 doubles (argb).

Path is fairly heavyweight given that it contains the tag, all the line
state (linecap, linejoin, linewidth, miterlimit, flatness), paint mode
(stroke, fill, eofill) and also a dash pattern (not implemented yet)
plus the path data which is a fairly compact packed representation I'm
particularly proud of :)




More information about the fitz-dev mailing list