[Top][All Lists]
[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