[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] Re: Rotation, new view system
- To: Benjamin Fallenstein <b.fallenstein@xxxxxx>
- Subject: Re: [zzdev] Re: Rotation, new view system
- From: Tuomas Lukka <lukka@xxxxxxxxxx>
- Date: Fri, 23 Feb 2001 17:11:14 +0200
- Cc: zzdev@xxxxxxxxxx
- In-reply-to: <3A966295.E8891093@xxxxxx>; from b.fallenstein@xxxxxx on Fri, Feb 23, 2001 at 02:16:05PM +0100
- Mail-followup-to: Benjamin Fallenstein <b.fallenstein@xxxxxx>, zzdev@xxxxxxxxxx
- References: <20010222172054.B10331@xxxxxxxxxxxxxx> <3A963AC5.1C259749@xxxxxx> <20010223142900.A21645@xxxxxxxxxxx> <3A966295.E8891093@xxxxxx>
> I think it's important that the rendering methods of the vobs and the
> cascading vob sets don't have to know anything about the rotation. They
> should draw into a Graphics object assuming they're straight up, and the
> architecture module should rotate that afterwards. The rotation itself
> should be attached "from the outside"--
> the new view system has a scheme
> for that, where information objects about a wide range of things can be
> attached to any vobset, e.g. whether this vob set is interpolated or
> not, or possibly which font to use for all the text vobs inside a vob set.
Which font? That doesn't sound right, as FontMetrics are not the
same between fonts. The fonts have to be measured when the view is
> There is a KILLER PROBLEM though: connections.
> All this makes NO sense
> if we cannot draw connections between stuff rotated at different angles.
> Even with lines, where the endpoints need to be rotated internally, this
> is hard, but with beams, it becomes impossible without giving the beamer
> intelligence about the rotation, it seems to me.
> This is an ugly one...
I don't know... basically the beamer needs only to be able to find
out the absolute coordinates of a given thing. That shouldn't be too hard