gzz-commits
[Top][All Lists]
Advanced

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

Re: [Gzz-commits] gzz/doc/pegboard 1008/PEG_1008.rst 1009/PEG_100...


From: Tuomas Lukka
Subject: Re: [Gzz-commits] gzz/doc/pegboard 1008/PEG_1008.rst 1009/PEG_100...
Date: Mon, 7 Oct 2002 07:59:52 +0300
User-agent: Mutt/1.4i

I mentioned earlier on IRC: we should probably keep the discussions on the 
mailing
lists: putting these in the semi-permanent docs makes them difficult to read
and it's harder to know when to erase something.

> +                     (Benja:) Ah. Now I understand somewhat... However,
> +                     even then, you cannot satisfy scaling in two dimensions,
> +                     so it would have to be ``scale(int into, float scale)``.

No, the point is that we define rendering text into a coordinate system that has
been scaled anisotropically to be undefined in AWT.

And like I said, coordsys already allows you to do such a scale. scale() is just
shorthand for coordsys.

Making boxes of different sizes *is* using the scale.

> +                     Also, you're talking about the "height" of a coordsys--
> +                     what is this? Coordsys are, at this point, 
> transformations
> +                     of points-- so what's the "height" of a transformation?

Would be the distance between (0,1) and (0,0).

> +                     Finally, I still don't like scale being here, because
> +                     generally having to know the scale before the view
> +                     comes in means that we cannot switch to a system where
> +                     (in gl) we determine the parent transformations
> +                     *after* the views have done their job. 

We do have the setXParams calls; we can just specify that their effect
in AWT may include problems with text.

Maybe we should have a flag in the VobCoorder or VobMap: whether text width 
depends on coordsys.

> For example in
> +                     text layout, it would be nice if we could first render
> +                     the text with a given width, then look at the resulting
> +                     height and decide how to translate the result-- this
> +                     requires that a coordsys gets its parent after it
> +                     is first created-- not currently allowed, but not 
> +                     impossible to change.
> +                     

Actually, as I mentioned it above, it *WILL* be allowed, after PEG 1009.

> !     (Benja:) ``buoyCS`` would be an addition to ``VobScene``? Also,
> !     ``translate`` should be ``translateCS`` as of PEG 1009.

Oh, buoyCS: not yet. Using it just as an example.

        Tuomas




reply via email to

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