[tei-council] updated facsimile odd

[Conal Tuohy]

On Thu, 2007-08-09 at 08:36 +0100, Lou Burnard wrote:
> Conal Tuohy wrote:
> > 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"/>
> >
> >   
> -1
> 
> 
> As previously noted, this usage of @height and @width on graphic is a 
> major difference in the way these attributes are currently defined.

Sorry ... I haven't really understood this, but I've gone back and
re-read your earlier email and the guidelines, and I think I have it
clearer now. 

At the very least I think that the documentation for
data.outputMeasurement and for graphic need to be clarified. For
instance where it says that they are for "specifying the size of an
object that is intended for display on the web", it should probably make
it clear at that point that the size specified is the desired size of
the display, not the size of the object itself. Currently, the sentence
is ambiguous on that point.

It's worth pointing out that the dimensions of graphics are potentially
valuable in other contexts than "display on the web".

As you said earlier, the schema and documentation is vague in places,
and hence it's not really clear what you can do with graphic's @height,
@width, and @scale attributes in practice. At present there isn't a lot
of actual usage which encoders can refer to, either.

The nub of the problem, IMHO, is that the value space of @width and
@height (defined by data.outputMeasurement) is based on CSS units which
include quite different measurements systems: pixels (i.e. measurement
in "device space"), real-world distance units such as mm and pt, and
also percentages (which incidentally pretty much renders @scale
redundant anyway). 

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? 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? 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? 

Con

-- 
Conal Tuohy
New Zealand Electronic Text Centre
www.nzetc.org