[tei-council] facsimile diagram
Daniel O'Donnell
daniel.odonnell at uleth.ca
Wed Aug 8 20:08:26 EDT 2007
On Fri, 2007-08-03 at 19:00 +1200, Conal Tuohy wrote:
> On Fri, 2007-08-03 at 07:26 +0100, James Cummings wrote:
> > Conal Tuohy wrote:
> > > It's true I didn't mean to imply that a graphic could act as a zone - I
> > > don't think people should in general be linking bits of text to those
> > > graphics.
> >
> > So really people should only be linking to and from zones generally.
>
> yes
OK now I'm confused: in Lou's ODD we have the following possibilities:
facsimile/graphic
facsimile/surface/graphic
facsimile/surface/graphic|zone
facsimile/surface/graphic|zone/graphic
And we have examples of @facs pointing to free-floating URLs and
graphics and zones.
But if I understand this aright, we should actually have zones
everywhere as the target for @facs. I.e. if I have a single facsimile
100px*100px image for f.1r of some manuscript and I want pb to point at
the whole thing, I should be doing this?
<teiHeader></teiHeader>
<facsimile>
<graphic xml:id="fol1r"/>
<zone xml:id="fol1r-wholething" box="0 0 100 100"/>
</facsimile>
<text>
<pb facs="#fol1r-wholething"/>
<p>floo flow flū</p>
</text>
If zones are the preferred targets of @facs, and if they express a
region of the graphic, then should it not be the case that they are
children of graphic after all, then?
Sorry if I'm misunderstanding this or there is a version control issue
going on.
>
> > > Within the same <surface/> as the stamp's <zone/>, there would be some
> > > <graphic/> elements, and if those graphics had @coords which overlapped
> > > the @coords of the stamp's zone, then those graphics would actually
> > > depict the stamp itself. Any of those associated graphics might be used
> > > to present a view of that zone. Obviously a graphic whose coords
> > > entirely enclosed the coords of the zone would be best (because it will
> > > show the full stamp), and a graphic whose resolution is higher will be
> > > better (if zooming), etc.
> >
> > Ok, and if those graphic/@coords are relative to the surface, how do we on the
> > surface indicate what unit of measurement they are using? Surely a surface may
> > be measured in all sorts of units (millimetres, inches, metres,
> > kilometres,etc.)?
>
> Well, it's not really needed in order to align the graphics and the
> zones (all that's needed is that the units are consistent). But for
> documentary purposes, perhaps a surface's dimensions could be given
> using a <dimensions> element?
>
> > How do I know that one graphic is higher resolution than the
> > other? i.e. they both cover the same area of the surface "0 0 100 100" but one
> > was taken with a hi-res camera, and one was taken quite awhile ago with some
> > low-res camera. How is that resolution indicated?
>
> The 2 graphics may use @height and @width to indicate their intrinsic
> dimensions. The hi-res image should be higher and wider, despite having
> the same @coords as the equivalent lo-res image. The resolution of a
> graphic could be calculated by dividing the @width by the width as
> specified in the @coords (which says how much of the surface the graphic
> covers).
>
> But to be honest, rereading the documentation for @height, @width and
> @scale, I'm not entirely sure that I understand how @height and @width
> are supposed to work together with @scale.
> http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-graphic.html
>
> If I have an image which is 200px wide, I would expect to mark it up as
> a graphic with @width="200px", but what do I do with @scale? And what is
> the "desired display size" anyway? If I give @scale="2", I'd be saying
> that I wanted the image to be displayed as 400 pixels wide, which sounds
> like an odd thing to want to do.
>
> I'd be interested in seeing any examples of the use of @scale.
>
> As an alternative to calculations involving graphic/@height, etc,
> presentation software could choose among graphics on the basis of
> metadata encoded in a linked <surrogates> element. Could that be a
> useful approach?
>
> Con
>
>
>
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
--
Daniel Paul O'Donnell, PhD
Department Chair and Associate Professor of English
Director, Digital Medievalist Project http://www.digitalmedievalist.org/
Chair, Text Encoding Initiative http://www.tei-c.org/
Department of English
University of Lethbridge
Lethbridge AB T1K 3M4
Vox +1 403 329-2377
Fax +1 403 382-7191
Email: daniel.odonnell at uleth.ca
WWW: http://people.uleth.ca/~daniel.odonnell/
More information about the tei-council
mailing list