[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