gzz-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gzz] PEG 1003


From: Benja Fallenstein
Subject: Re: [Gzz] PEG 1003
Date: Sat, 07 Sep 2002 09:57:20 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020615 Debian/1.0.0-3

Tuomas Lukka wrote:

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.


Yes, but there's the difficulty in AWT, where fonts scale non-uniformly (20pt isn't two times as high as 10pt). As we need to determine the cell box size through the font size, we cannot easily pass the scale through the vob system... Though I'd prefer it that way.

The question here is whether to let text vobs in GL determine their size through the scale passed by the vob system, or whether also to respect the font size passed to them in their constructor... probably the former.

The problem with having scale in OrthoCoorder is: Let's assume we have a coordsys showing a window, with cells in it. If we put the window coordsys into another coordsys scaled by factor 2, the rect bg vobs in the window would scale uniformly by factor 2, but the fonts would scale by something else, probably a little more. That would look very ugly, as the text would be badly clipped. :-(

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?


Sorry, I don't understand the question: What do you mean by, "what about the shape?"

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.


As I explained above, this is made difficult by AWT's non-uniform font scaling... Currently for AWT, each text vob stores its scale as a field inside itself. The vob scene doesn't know anything about it.

- Benja





reply via email to

[Prev in Thread] Current Thread [Next in Thread]