[tei-council] updated facsimile odd

[Daniel O'Donnell]

On Fri, 2007-08-10 at 10:17 +1200, Conal Tuohy wrote:

<longsnip/>

> So it would be valid against the schema to say that a graphic was
> supposed to be rendered as "100px" width, or at "100%" width, but what
> would that mean in practice? 

in CSS terms, 100% means "100% of the width of the image" and has
nothing to do with the real world object.

> If the image is 100px wide, that would mean
> rendering it 100px wide. However, the real-world dimensions of that will
> vary depending on the resolution of the rendering device: on a computer
> monitor that might be a few cm across, whereas on a laser printer it
> would be more like a few mm. I think it's clear that the measurement
> units used here should not make assumptions about the resolution of the
> end-user's display device. That should be a matter for presentation
> software.
> 
> It seems to me that our earlier discussion of the semantics of @rend is
> parallel: does the value of @rend indicate how the text should be
> rendered for display, or how it WAS rendered in the original? We agreed
> that it was the latter. But with graphic, we have a situation more like
> the former, don't we? 

Yes and no--both to your premise and what is desirable. THE most
desirable situation would be that real world dimensions are correlated
to graphic dimensions so that a reference to the graphic could be
converted to a reference to the real world object. But that's beyond
what we're doing here.

In our more limited P5 world, the reference is still to the original
graphic rather than the rendition device. So 100 230 450 453 refers to a
point on the original graphic file rather than my output. Technically it
is a moot point, I suspect, since if I'm using Lynx or a screedocumentn
reader I can't reference the point anyway, and if I'm using a cell phone
on some huge graphic I'll find the point by scrolling. But the reference
is to the input image rather than the output. If my cellphone does some
kind of compression routine in order to get large images on the screen,
the output coorindates will need to be translated.

> Wouldn't it be better to provide "real-world"
> measurements as the dimensons of graphics, and allow presentation
> software to scale the graphics appropriately for different output
> devices? Perhaps a better way would be to give <graphic> 2 distinct sets
> of measurements, such as @width and @height given in pixels, and also a
> <dimensions> child (or <height> and <width> children), as has been
> proposed for <surface>, given in real-world units? 

I think this is getting beyond what we need for P5: what is wrong with
saying the box coordinates ref a point in the input graphic as a minimal
feature? If the user needs more, there is METS, as I am always reminded.

> 
> Con
> 
-- 
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/