Re: [Gnome-print] Gnome-print imaging model

[Lauris Kaplinski <lauris helixcode com>]

First self-reply ;)

On 07 Dec 2000 23:22:24 -0200, Lauris Kaplinski wrote:
> 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

I tend to think that we do not need complex paint style for strokes and
glyphs.
I.e.
- fill paint style (color model, color, opacity, gradient, pattern...)
- stroke and glyphs paint style (color model, color, opacity)
If users wants more elaborate stroke or text painting he/she (or
corresponding API) has to generate shape representation of given
operations (a la postscript strokepath/charpath

More rules:
7. lack of predefined limits
All coordinates, image and path sizes etc. are practically limitless - i.e.
constrained only with platform architecture and available memory.

8. Sequentiality
Later primitive operation paints on top of earlier. What that exactly
means is defined by corresponding colorspace.

Lauris