[tei-council] facsimile diagram

[Arianna Ciula]

Dear all,

I have tried to catch up with all the emails on the facsimile work, fist 
on Conal and Dot's original proposal and than on Lou's draft and I am 
sorry I wasn't able to contribute when needed.

To simplify things, I'll report first on the first draft (but only for 
those things that I think are still relevant for the new draft, since we 
don't want to waste time, I believe...) and then in my next email on the 
new draft revised by Lou.

########## General structure and preference for stand-off ###########

I do like the model Conal proposed (facsimile/text). Between the two 
examples of markup Conan quoted, I would prefer the second one or 
stand-off sample, since it looks cleaner to me. [this relates to some 
comments on the new draft to follow]

########## Avoid 'page' or make definitions more general ###########

SR> So please, don't tie us down to page breaks!

As said in Berlin I agree with this; however, the definition page breaks 
(or begin...better) could be may be expanded to include scenarios where 
we don't really have beginning of new pages as such, but new units (e.g. 
gravestone surfaces, membranes of rolls etc...).

In my mind the <surface> was something conceptual rather then physical, 
so I was also going to propose something more convoluted such as 'The 
<surface> element represents a conceptual unit (page, membrane etc.) of 
the source material that can have one or more physical realisations.', 
but then I saw the discussion on coordinates and realised that it may be 
better to highlight its physical character for practical reasons.

In general I would try to substitute 'page' with 'source unit' or 
similar.  [I have seen Lou has corrected this already in the new draft]

########### Relationship with <surrogates> ###########

CD>if graphic were added to the att.declaring class, it could use @decls 
to point to a bibl that describes it

Agree. We should include the explicit relationship between <surrogates> 
and the content of <surface> as Conan has explained it and ideally 
<graphic> should be added to the att.declaring class.

Arianna

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

-- 
Dr Arianna Ciula
Research Associate
Centre for Computing in the Humanities
King's College London
Strand
London WC2R 2LS (UK)
Tel: +44 (0)20 78481945
http://www.kcl.ac.uk/cch