[tei-council] surfaces, surfaceGrps, etc. [was : minutes/release deadline]
mholmes at uvic.ca
Mon Nov 14 08:32:13 EST 2011
On 11-11-14 03:27 AM, Lou Burnard wrote:
> On 14/11/11 10:57, Sebastian Rahtz wrote:
>> On 14 Nov 2011, at 05:09, Martin Holmes wrote:
>>> <zone> should be able to contain<surface>. You define a<zone> to show
>>> the contextualized coordinates of the patch or whatever in the parent
>>> <surface> coordinate space, then you put a<surface> in it; the latter
>>> can then define its own coordinate space for<zone>s inside it.
>>> So the coordinates on<zone>s mean "my position and size in the parent
>>> space", and the coordinates on<surface> mean "the coordinate space in
>>> which child<zone>s will be defined".
>> I like it, a lot. Simple and effective, no ambiguity, meets all the needs. Lets do it.
> This looks like a gordian-knot-breaker... many thanks Martin! I will go
> away and redraft accordingly.
> p.s. while we're at it, how about renaming ulx, uly etc as one attribute
> @coords for the "coord-space-definition" sense? a different name reduces
> confusion as well as the amount of typing. Or do we think this would be
> a birnbaum-breaker?
It's definitely birnbomb, and in my initial thought was that I'd have to
go away and do a new release of the Image Markup Tool to handle this,
but when I checked, I discovered that I'm not establishing a coordinate
system on my <surface>s at all in the IMT output; I'm just assuming that
the @width and @height attributes on the <graphic> child of <surface>
constitute the coordinate space for the <zone>s. I hope that's still
Nevertheless, I'd be nervous about breaking backward compatibility here.
More information about the tei-council