Hi Doug,
Doug Reside wrote:
> Do we want to specify what the points mean? Pixels? Centimeters or
> Inches? Percentages?
This would be defined by the parent <surface>:
"The coordinate space defined by this element may be thought of as a
grid lrx - ulx units wide and uly - lry units high. This grid is
superimposed on the whole of any image directly contained by the surface
element. The coordinate values used by every zone element contained by
this surface are to be understood with reference to the same grid. "
<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-surface.html>
Cheers,
Martin
>
> Doug
>
>
> On Thu, Apr 1, 2010 at 9:42 PM, Dot Porter <[log in to unmask]
> <mailto:[log in to unmask]>> wrote:
>
> On Thu, Apr 1, 2010 at 12:23 PM, Martin Holmes <[log in to unmask]
> <mailto:[log in to unmask]>> wrote:
> > That's my understanding too. With regard to 2), I wonder if it
> @ulx, @uly
> > etc. ought to be mandatory on <zone> anyway. Isn't a <zone> pointless
> > without them? (The pun was unintended, but I like it anyway.)
> >
> :-)
>
> The argument in support of optional coordinates would be the case in
> which a <zone> contains a <graphic> that defines the area of <surface>
> - a separate file rather than a coordinate bounding box. Using
> coordinates may be preferable be we'd still want to allow this other
> sort of <zone>, I think.
> d
> I also note that the definition of <zone> (which currently specifies
> that the area is rectangular) needs to be changed. I've added a
> comment to the SF ticket.
>
> Dot
>
> Dot
>
> > Cheers,
> > Martin
> >
> >> Yes?
> >>
> >> Dot
> >>
> >> On Thu, Apr 1, 2010 at 11:23 AM, Martin Holmes <[log in to unmask]
> <mailto:[log in to unmask]>> wrote:
> >>>
> >>> Hi Conal,
> >>>
> >>> You've convinced me. The @points values should all fall within the
> >>> bounding
> >>> box of the @ulx, @uly etc.; or, to put it another way, any agent
> >>> generating
> >>> or editing @points should simultaneously create @ulx, @uly etc.
> for the
> >>> bounding rectangle.
> >>>
> >>> I've added that as a comment on the feature request in SF.
> >>>
> >>> Cheers,
> >>> Martin
> >>>
> >>> Conal Tuohy wrote:
> >>>>
> >>>> On 1 April 2010 02:53, Martin Holmes <[log in to unmask]
> <mailto:[log in to unmask]>> wrote:
> >>>>
> >>>>> Conal Tuohy wrote:
> >>>>>
> >>>>>> The @path should be constrained (in the prose of the
> guidelines, at
> >>>>>> least
> >>>>>> -
> >>>>>> possibly also in schematron) to fall entirely within the
> bounding box.
> >>>>>
> >>>>> I see your point here, and it's actually my intention to
> write IMT 2 to
> >>>>> comply with it. However, I can see use-cases where this would
> not be
> >>>>> the
> >>>>> desired behaviour.
> >>>>
> >>>> I do appreciate the pragmatic issue you describe, and I agree it
> >>>> should be possible to handle cases like that. I would like to
> see it
> >>>> handled without changing the currently-defined semantics of the
> >>>> "att.coordinated" attributes; namely that they constitute a
> "bounding
> >>>> box" (i.e. something like
> >>>> <http://en.wikipedia.org/wiki/Minimum_bounding_box>). The
> point of a
> >>>> bounding box being that it completely encloses the object of
> interest.
> >>>>
> >>>>> Imagine an oddly-shaped feature of a page (surface) which
> >>>>> is basically concentrated in the bottom left, but which has
> one long
> >>>>> thin
> >>>>> protrusion which pushes right up to the top right.
> >>>>
> >>>> OK. I'm imagining a photo of an industrial building covered in
> >>>> graffiti. There's even writing up the side of a chimney on the
> >>>> right-hand side of the picture..
> >>>>
> >>>>> When specifying a zone
> >>>>> for that feature, using @points we'd want to outline the
> whole thing,
> >>>>> including the protrusion.
> >>>>
> >>>> This hypothetical zone would include the part of the image in
> which
> >>>> the building is visible (including the chimney), e.g.:
> >>>>
> >>>> <zone id="entire-building-including-chimney"
> >>>> ulx="0" uly="0"
> >>>> lrx="100" lry="100"
> >>>> points="0,50 0,100 100,100 100,0 90,0 90,50"
> >>>> />
> >>>>
> >>>> The zone's bounding box has an upper left corner at 0,0, and a
> lower
> >>>> right corner at 100,100, and the smaller region outlined by
> @points
> >>>> includes the lower half of that square, plus a thin region
> running up
> >>>> the right-hand side (the chimney).
> >>>>
> >>>>> However, when using a bounding rectangle, it may
> >>>>> be more pragmatically useful to outline only the main part of the
> >>>>> feature;
> >>>>> otherwise, a processor relying on the bounding box would
> basically end
> >>>>> up
> >>>>> showing a zone which occupies the whole surface, obviating
> the value of
> >>>>> the
> >>>>> zone as a method of directing attention to a specific part of the
> >>>>> surface.
> >>>>
> >>>> In this case I would simply encode another <zone> element. I would
> >>>> have the "entire-building" zone and also another
> >>>> "building-without-chimney" zone to represent the specific part
> of the
> >>>> surface.
> >>>>
> >>>> Put it this way: if you (the encoder) genuinely want to draw
> attention
> >>>> to a "specific part" of a zone, then you should just be
> creating a new
> >>>> zone for that specific part. You can have as many zones as you
> want,
> >>>> after all.
> >>>>
> >>>> Con
> >>>
> >>> --
> >>> Martin Holmes
> >>> University of Victoria Humanities Computing and Media Centre
> >>> ([log in to unmask] <mailto:[log in to unmask]>)
> >>> Half-Baked Software, Inc.
> >>> ([log in to unmask]
> <mailto:[log in to unmask]>)
> >>> [log in to unmask] <mailto:[log in to unmask]>
> >>>
> >>
> >>
> >>
> >
> > --
> > Martin Holmes
> > University of Victoria Humanities Computing and Media Centre
> > ([log in to unmask] <mailto:[log in to unmask]>)
> > Half-Baked Software, Inc.
> > ([log in to unmask]
> <mailto:[log in to unmask]>)
> > [log in to unmask] <mailto:[log in to unmask]>
> >
>
>
>
> --
> *~*~*~*~*~*~*~*~*~*~*
> Dot Porter (MA, MSLS) Metadata Manager (on leave)
> Digital Humanities Observatory (RIA), Regus House, 28-32 Upper
> Pembroke Street, Dublin 2, Ireland
> -- A Project of the Royal Irish Academy --
> Phone: +353 1 234 2444 Fax: +353 1 234 2400
> http://dho.ie Email: [log in to unmask]
> <mailto:[log in to unmask]>
> *~*~*~*~*~*~*~*~*~*~*
>
>
>
>
> --
> Doug Reside, Associate Director
> Maryland Institute for Technology in the Humanities (MITH)
> University of Maryland
> b0131 McKeldin Library
> College Park, MD 20742
> (301) 405-5897
>
>
|
