[tei-council] FW: Further update on PH

[Conal Tuohy]

On 19/09/2007, Sebastian Rahtz <sebastian.rahtz at oucs.ox.ac.uk> wrote:
>
>
> With regard to @box, consider this example:
>
>     <facsimile>
>         <surface xml:id="grave" box="358 0 700 681">
>             <zone box="437 223 626 256" xml:id="line1"/>
>             <zone box="446 251 610 282" xml:id="line2"/>
>             <zone box="375 281 684 308" xml:id="line3"/>
>             <zone box="390 306 674 332" xml:id="line4"/>
>             <zone xml:id="grave-partial" box="364 171 693 390">
>                 <graphic url="gravestone-partial.jpg"/>
>             </zone>
>             <zone xml:id="grave-full" box="0 0 1024 681">
>                 <graphic url="gravestone.jpg"/>
>             </zone>
>         </surface>
>     </facsimile>
>
> The @box of 358 0 700 681 says that we will talk in terms of a
> grid of 342 x 681 when we define zones on the  surface. Why
> not be explicit, then, and say <surface xMax="342" yMax="681">?

If I understand correctly, the xMax and yMax are intended to represent the
width and height of the physical surface, isn't that right? Why do we need
to encode this, though? Isn't it redundant since the information is present
in the @box attribute of the surface, and the @box attributes of the
surface's graphics? Encoding information redundantly is just another
opportunity for making arithmetic errors that introduce inconsistency, IMHO.

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.

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. 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.

Cheers!

Con