[Gnome-print] Gnome-print imaging model

[Lauris Kaplinski <lauris helixcode com>]

Hello!

After spending some time with gnome-print, I found, that we need a more
clearly defined description of it's imaging model. Our 'official'
blueprint:
http://developer.gnome.org/arch/imaging/printing.html
refers only to current postscript-like API. But:
1. There is possibility to add different API-s
2. It does not give exact definition of imaging process

To start filling the gap, I propose the following drawing model for
gnome-print. It is not an API - more the description of possibilities
and invariants for all output drivers and guidelines for API sets (although
the latter can circumvent these, using state-storing)

1. Coordinates
Final image will be generated to 2-dimensional euclidean space

2. Atomic operations
Every primitive drawing operation can be considered atomic without
any other side effects than the image appearing to final output

3. Irreversibility
Once operation is carried out, its effects are irreversible. You cannot
draw anything under existing object. You cannot erase anything.

4. Inaccesibility
There is no way to programmatically access final output (the only effect
of basic operation can be immediate drawing to paper)

5. Drawing primitives
There are 4 drawing primitives:
2.1. Shape (a filled vector path)
2.2. Line (a stroked vector path)
2.3. Image (bitmap object)
2.4. Glyphs (laid out text)

6. Drawing attributes:
Each drawing primitive is carried out, using set of attributes (its
graphic state)
The graphic states of primitives are:

6.0. Common state to all primitives
- ctm (affine transformation from object coordinate space to output coordinates)
- clipping path (a closed cubic bezier path, with evenodd rule?)

6.1. Shape
- path (a closed cubic bezier path)
- painting style (color, opacity, gradients...)
- fill rule (nonzero, evenodd)

6.2. Stroke
- path (a cubic bezier path)
- painting style
- line width (uniform in output coordinate system)
- join style (miter, round, bevel)
- cap style (butt, round, square)
- dash style (pattern of segment lengths + offset)

6.3. Image
- rectilinear bitmap with defined color model
- overall opacity

6.4. Glyphs
- positioned glyphs (including exact font specification)
- painting style

Using that as general driver-side model, we can generate different client-side
API-s, with well-defined behaviour. Currently we have only postscript-like
streamed API, but others like 'Java2D style' or 'GnomeCanvas style' will
probably implemented in future.
Currently the paintstyle consists of:
- RGB fill color
- opacity
Potential additions very soon are:
- colorspace
- colorspace-specific values (CMYK...)
- gradients
- bitmap patterns
Unimplemented is global opacity for bitmaps
Only RGB8, RGBA8 and Gray8 bitmap formats are supported
Prepositioned text API is not stabilized. Instead most programs use text
layouting ::show() method, which does not have well-defined behaviour.
According to proposed imaging model we do not support directly non-uniform
stroking pens.

Depending of API, the client-side drawing process can seemingly circumvent
the base model requirements. This most probably means generating temporary
display-list or raster image, and sending data to output as complete page
(this happens with current postscript like API). Other API-s can provide
client-side access to rendered buffer etc.

Comments?

Lauris