[tei-council] Further update on PH

[Sebastian Rahtz]

Conal Tuohy wrote:
>
>
> If I understand correctly, the xMax and yMax are intended to represent 
> the width and height of the physical surface, isn't that right?
no, the dimensions of the theoretical grid imposed on the surface. I 
propose this to _replace_ @box
>
>     then replace the @box with @url, @ury, @llx and @lly, and then these
>     can default to 0, 0, $xMax and $yMax if not otherwise specified. It
>     would make writing retrieval programs easier.
>
>
> I'm not so sure it would. IMHO it would be simpler to code for 
> coordinates which are always explicitly given in @box (or @urx, @ury, 
> etc) form, rather than coding for a combination of explicit 
> coordinates and sometimes implicit coordinates derived from a default 
> specified on a parent element.
probably right. make them all compulsory
>
> In the example above, the coordinates of the zones (AND the 
> coordinates of the surface itself) are all given with respect to the 
> same coordinate space. The zones are not specified relative to the 
> upper left corner of the surface, which is what you seem to be implying.
its what I was proposing, not implying...
> If I understand it correctly, your suggestion boils down to allowing 
> the encoders to choose an arbitrary resolution for their coordinate 
> space, but requiring the origin of the space to be the upper left 
> corner of the surface. I don't think this helps them at all. In my 
> opinion, they should be able to pick a coordinate space with a 
> resolution and an origin that suits them. They will typically want (I 
> imagine) to encode coordinates obtained by counting pixels in a 
> particular bitmap image. The corner of the surface may not coincide 
> with the corner of that graphic (it may not even appear within the 
> graphic - the edge of the page may be cropped out of the image). 
> Finally, if the coordinate system of all the zones is not defined 
> relative to the corner of the surface, then it's possible to avoid 
> encoding the bounding box of the surface altogether.
ok, I see your point and will agree. stet.

but can we split up @box to make datatyping and calculation easier.

-- 
Sebastian Rahtz      
Information Manager, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431