[tei-council] Further update on PH

[Sebastian Rahtz]

I think I am finally understanding Conal, having studied his implementation.
It does mean a change of heart for Lou, though, if <surface> really
now does represent the abstract idea of the surface rather than an
image of it.

I still think that

  <facsimile>
    <surface xml:id="p1">
       <graphic url="p1.jpg"/>
   <surface>
</facsimile>

is a desirable shortcut for

<facsimile>
  <surface box="0 0 100 100" xml:id="p1">
    <zone box="0 0 100 100">
      <graphic url="p1.jpg"/>
    </zone>
  </surface>
</facsimile>


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

naturally, the "grave-full" would have negative values.

-- 
Sebastian Rahtz      

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