[tei-council] surfaces, surfaceGrps, etc. [was : minutes/release deadline]
mholmes at uvic.ca
Mon Nov 14 00:09:42 EST 2011
I said at the time, but I don't think anyone took me seriously:
<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".
Anything wrong with that?
On 11-11-13 09:35 PM, Lou Burnard wrote:
> On 13/11/11 16:15, Sebastian Rahtz wrote:
>> I think my problem is that I don't understand how you thought nested<surface> was ever going
>> to work. In the given example:
>> <line>As in Visions of — at</line>
>> <line>night —</line>
>> <line>All sorts of fancies running through</line>
>> <line>the head</line>
>> <surface type="newsprint" binder="glue" flipping="false">
>> <zone>Spring has
>> just set in here, and the weather.... a
>> there are no coordinates, but we can imagine that the outer surface might have had
>> 0,0,100,100 and the<zone> with the<line>s might have 10,10,23,42. But
>> how were we ever going to know where the inner surface _is_? it is all very
>> well to say you want that<surface> to have a grid of 0,0,10,10, and then talk
>> about the Spring<zone> within it, but we have no means of anchoring this
>> surface relative to the outer one.
> We do, if we accept that the attributes have different meanings. Here's
> the same example with some co-ords.
> <surface ulx="0" uly="0" lrx="200" lry="270">
> > <zone ulx="10" uly="10" lrx="100" lry="180">
> > <line>Poem</line>
> > <line>As in Visions of — at</line>
> > <line>night —</line>
> > <line>All sorts of fancies running through</line>
> > <line>the head</line>
> > </zone>
> > <surface type="newsprint" binder="glue" flipping="false"
> ulx="50" uly="130" lrx="150" lry="220">
> <zone ulx="50" uly="130" lrx="150" lry="220">
> Spring has just set in here, and the weather.... a
> This defines a coordinate space (0,0,200,270) on the outer surface, and
> then a zone. and a nested surface containing a zone, all (ex hypothese)
> within the same space. The positions and sizes *in that coordinate
> system* for all of them are explicit.
> The problem which is worrying me, and possibly also Sebastian, is that I
> have no way of distinguishing this case from the less likely but not
> impossible case where the coordinates given for the inner nested surface
> are actually defining a completely new coordinate system.
>> This _could_ all work if we had _two_ sets of coordinates, one to
>> declare oneself relative to the outer<surface>, and one to
>> set a new new coordinate system relative to the outer one, but I really
>> cannot see how you can work with one set of coordinates.
> A new coord system isn't *relative* to the outer one, methinks. It's
> just new.
>> notion that you have a switch which flips between the two uses of coordinates
>> cannot fly, because you need both.
> Well, the recognition that we need both possible semantics is why I say
> we need some way of indicating which applies in a given case. I can't
> see that it would ever make sense to want both cases to apply for a
> single instance!
> If you don't like the idea of an attribute (I don't much) I have three
> other suggestions:
> 1. Enforce somehow a rule which says that you can only have one coord
> system in a given hierarchy of surfaces, and it is the one given by the
> element at the root of that hierarchy (which will be either a surface or
> a surfaceGrp or conceivably a sourceDoc). This involves no change to the
> existing schema, but does require some careful rewriting and some
> special case rules.
> 2. Introduce a new element<coords> which sits anywhere within the
> hierarchy and defines the coordinate system for all of its children.
> 3. Introduce a new attribute @coords for<surface> or<surfaceGrp> which
> defines the coordinate system for all of its children. Cannot co-exist
> with either the ulx, urx etc. quartet, or the @points.
> I think all of these are less ugly than sin. Any preferences? Any
> One other thought about all this -- might it be worth sounding out the
> person responsible for much of our current thinking on this topic, i.e.
> Conal, as to how he rates our development of it ?
>> The example above is just fine to describe the structural relationship
>> between what we see on the MS, but not the layout. IMHO.
>> Simplest suggest is to abandon the idea that we'll ever be able to say _where_
>> the patch is, and just accept that each new<surface> is in its own
>> little world, with its own coordinate space.
>> My next suggestion is that we say that inner<surface> cannot have
>> coords, and that its simply a way of grouping<zone>s. In which case
>> perhaps you'd rather call it a<zomeGrp>? in that case, I'd
>> vote for going back to<patch>...
>> My last suggestion is that we add a new set of x1,y1,x2,y2 attributes
>> called rel_llx, rel_lly, rel_ury,rel_urx to<surface>, which allow it
>> to say where it is relative to its parent<surface>. Ugly as sin, but
>> it would work.
>> Stormageddon Rahtz
>> Head of Information and Support Group, Oxford University Computing Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>> Sólo le pido a Dios
>> que el futuro no me sea indiferente
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> PLEASE NOTE: postings to this list are publicly archived
More information about the tei-council