[Gzz] PEG 1003

[Benja Fallenstein]

Hi,

some thinking about PEG 1003:

I think the difficulty really is that we use coordinate systems for two 
different purposes: a) to do translation/rotation/scaling/affine 
transformations; and b) to define *shapes*.

b) is used in clipping: "Clip this rectangle." It is also used for 
placing e.g. cell borders: A RectBgVob means, "Draw a bounding box with 
a background inside this rectangle." When we create a coordsys 
representing a shape, we give its width and height. When we create a 
coordsys representing a transformation, we give its unit vectors. 
Currently we use the same mechanism for both of this cases.

My hunch is that this is really where the problem lies, and it is where 
we can find a solution.

Note BTW that in fact, it would be nice to be able to use 
non-rectangular shapes, for clipping as well as for vob shapes... but 
it's not something we *need*. It would be nice to give arbitrary polygons.

Note also that not all vobs need a box/shape. For text vobs, it suffices 
in principle to have a position, which can be given through a 
translation (IF somebody else takes care of the clipping).

It seems that mixing *shape* with *transformation* is really what 
creates difficult problems here. The problem really is that each 
non-connection vob is only given one coordinate system, and that single 
coordinate system is supposed to contain information about both the 
shape and the transformation, i.e. translation PLUS unit vectors (for 
scaling, rotation etc.).

This is what creates the problems mentioned in the tech report: if the 
vobs of a cell knew a *shape* to draw a rectangle and clip the text, but 
also knew a *transformation* that gives the scale (which is 1 both 
before and after the interpolation) the interpolation would work 
correctly and the problem would never occur.

The information EVERY vob (I think) needs to draw itself is:
- a position on the screen
- a shape for clipping

The clipping shape can be set in the drawing context before the vob is 
asked to draw itself, so that the vob needn't worry about it.

In affine coordinate systems, for EVERY vob we also need:
- unit vectors of the affine transformation, for rotation/scaling/skewing

This, too, can AFAIK be set in the graphics context before the vob is 
called.

Finally, SOME vobs (which draw a border around something) will also need 
a shape to draw themselves in. This shape will often be the clipping 
shape for some other vobs.

Still thinking about how this can be put into a simple system, but I 
hope that defining the problem like this can help...

- Benja