[tei-council] updated facsimile odd
Conal.Tuohy at vuw.ac.nz
Thu Aug 9 02:49:51 EDT 2007
I want to stress that the units used in @coords (in my draft) and in @box (if I understand Lou's draft correctly) are not pixels, or at least are not necessarily pixels.
The coordinate system used is defined by the encoder to be whatever suits them. Now of course, those numbers will correspond to something in reality. The units might be cm, mm, furlongs, or any real-world unit of distance. Or the units might be 1.3235mm in length. For some purposes, the actual real-world dimensions of those units is not relevant. For aligning areas within a coordinate space, it's only necessary the measurements of those areas are made in terms of the units which that coordinate space uses. i.e. what's important for alignment is only proportions, or ratios between sets of coordinates. Ultimately, for presentation, these measurements will be converted into regions of a real bitmapped image, and to do this, but the use case of text/image alignment just does not require that real units be specified.
On the other hand, other use cases may require measurements in real-world units, and to my mind the way to do this is to use <height> and <width> as children of <surface>. Or have <dimensions> as a child of <surface>, and have height and width within that. That would give conservators real-world figures.
Finally, since measurements are actually being made in a common coordinate space, the high- and low- resolution images in your example would actually have the same @box value. The difference in resolution could be made apparent by encoding @width and @height on the graphic (i.e. the high res image might be <graphic url="high.png" width="1000px" height="2000px"/> while the lo res image would be <graphic url="low.png" width="100px" height="100px"/>
From: Daniel O'Donnell [mailto:daniel.odonnell at uleth.ca]
Sent: Thu 09/08/07 11:41
To: Sebastian Rahtz
Cc: Christian Wittern; TEI Council; James.Cummings at oucs.ox.ac.uk; Conal Tuohy
Subject: Re: [tei-council] updated facsimile odd
On Fri, 2007-08-03 at 09:13 +0100, Sebastian Rahtz wrote:
> Christian Wittern wrote:
> > As I understand it you link to the surface coordinates and then go and
> > see which graphic covers the area you are interested in. That seems
> > to be the whole point of this indirection.
> umm. expand on "the surface coordinates" for me. if they are unitless
> and unbounded,
> they cannot mean anything.
I think myself subject to clarification that we should be calling a
spade a spade here: everything in the ODD and its description suggests
to me that we are counting pixels. If we were doing anything else surely
we'd need some kind of translation table and discussion of how real
world measurements get converted to locations on the image?
I think real world object coordinates would be brilliant to have.
Conservators would love them too, I bet, since they would be image
independent (you'd just need to add new reference coordinates to your
lookup table). But we are simply not talking about that or any other
measurement as far as I can see.
The hi/lo res issue is an important one: if I have
surface/graphic at id="hi1"|graphic at id="lo1" then the references for the
bottom right corners of the box (at least) will be different in each;
and if we are not starting in 0,0, then botheth sets will be different.
Should we perhaps somehow indicate a reference image in those cases?
This would allow the images to be aligned, since one would be expressed
in terms of the other. Of course, then surtheface is starting to look
like app; but that's neither here nor there ;)
> > My understanding is that they will be exactly the same, since the
> > coords are expressed relative to the <surface>.
> relative is good, but you must either have units, or proportions of a
> bounding box. just units
> won't cut it.
> > As I understand it, the pointing goes through the indirection of the
> > surface: You express the location of <l> in terms of the <surface>
> > coords, using the same reference system as is used for the zones. You
> > will then discover from these coords in which of the zones (in this
> > case all three) your <l> is located.
> we really really need worked examples of this to understand it....
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
More information about the tei-council