[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gzz] PEG 1003
From: |
Benja Fallenstein |
Subject: |
[Gzz] PEG 1003 |
Date: |
Fri, 06 Sep 2002 16:18:25 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020615 Debian/1.0.0-3 |
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
- [Gzz] PEG 1003,
Benja Fallenstein <=
- Re: [Gzz] PEG 1003, Benja Fallenstein, 2002/09/06
- Re: [Gzz] PEG 1003, Tuomas Lukka, 2002/09/06
- Re: [Gzz] PEG 1003, Tuomas Lukka, 2002/09/07
- Re: [Gzz] PEG 1003, Benja Fallenstein, 2002/09/07
- Re: [Gzz] PEG 1003, Tuomas Lukka, 2002/09/07
- Re: [Gzz] PEG 1003, Benja Fallenstein, 2002/09/07
- Re: [Gzz] PEG 1003, Tuomas Lukka, 2002/09/07
- Re: [Gzz] PEG 1003, Benja Fallenstein, 2002/09/07
- Re: [Gzz] PEG 1003, Tuomas Lukka, 2002/09/07
- Re: [Gzz] PEG 1003, Benja Fallenstein, 2002/09/09