Re: [Gzz] PEG 1003

[Tuomas Lukka]

> 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*.

Yes.

> 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.

Agreed.

> 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.

I commented on this in another mail. There are so many options
that it would actually be best to use a "clipping vob".

> 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).

And scale. Don't forget the scale.

> 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.

Aaaa, this is getting good. 

Yes, separating the shape and the transformation .

> 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.

But what about the shape? How does the techreport stuff work here?

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

Not only in affine: you do need the width-height for scaling the 
text inside cells in the usual views.

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

Yes, it seems like a good direction.

        Tuomas