[tei-council] facsimile draft (fwd)

[Lou Burnard]

Martin Holmes wrote:
>
> Reading about the @facs attribute, it seemed to me quite likely that 
> I'd want to point it at multiple items; for instance, where there are 
> images of the same surface at different resolutions, you'd want to 
> point to all of them:
>
> <pb facs="#p2_hi_res #p2_low_res">
> I can see that this could be accomplished by including both of the 
> relevant graphics inside one <surface> element, and pointing to the 
> xml:id of that element, but that might not always be appropriate or 
> possible. 

The idea is to make simple things simple, and not so simple things 
slightly less so. So if you want to point to alternative images, you 
have to wrap them in something i.e. a <surface>, and point to that.


> Can @facs point to multiple space-separated identifiers?
>
yes, but it then means something different -- the pb corresponds with 
the concatenation (not the alternation) of the two images pointed at.  
(Note that it is this rule which makes it possible to just have a bunch 
of <graphics> inside a single <facsimile> )

> I can see an objection to restricting both <surface> and <zone> to 
> rectangular areas through the @box attribute. Although my own Image 
> Markup Tool suffers the sad limitation that it can only deal in 
> rectangular areas, that's definitely a shortcoming and is often 
> pointed out as such, and I think there's a clear case to be made for 
> allowing the coordinate system for these areas to specify ellipses and 
> polygons.

Same logic as before, I'm afraid. Simple things are done simply. 
Non-rectangular zones are not simple to specify.  The recommendation is 
that if you dont want boxes, you need to define the shapes you do want 
in SVG and point to bits of that.

> For instance, a text paragraph might run across two columns on a page 
> surface, so that it constitutes an eight-sided shape, or an 
> illustration might be circular, and have text wrapping around it such 
> that a rectangular zone would end up including bits of text at the 
> corners. Objects in an image, even if they're rectangular in real 
> life, may end up as parallelograms or distorted rectangles due to 
> perspective effects. I wonder if it might be simpler, and more 
> flexible, to borrow from the XHTML image map attributes:
>
> <http://www.w3.org/TR/xhtml2/mod-csImgMap.html>
>
> specifically @shape and @coords, to allow more flexibility here? 
> @shape would allow circles and polygons (although not, oddly, 
> ellipses, which seems a pointless limitation).

Yes, we looked at this. My view is that the way that image maps do it in 
XHTML is not really very satisfactory as it doesn't scale up properly.
> Another possibility is to look at how SVG uses the <path> element. 
> @box is nice and simple, so I can see the appeal, especially given 
> that this is a new module, but I think people will want more options 
> here than a simple rectangle.

See above.
>
> I think this sentence is missing a closing parenthesis (presumably 
> after </gi>):
>
> "Since all <gi>zone</gi> elements use the same co-ordinate system 
> (that defined by their parent <gi>surface</gi>, there is no need to 
> demonstrate enclosure of one zone within another by means of nesting."
>
correctamundo.


> The example which includes this:
>
> <p>
>                                 <lb facs="#157rL1"/>
>                                 <c facs="#157rCapE">E</c>fter þær 
> hælender blah blah I cant <lb/> read this help they only taught me old 
> english in print form ....</p>
>
> is a bit confusing, coming out of nowhere -- I guess it's a genuine 
> sample but the deviation from OE text into ModE complaint, shorn of 
> its context, is a little puzzling, to me at least, and a more 
> straightforward example might be more helpful to the reader.
>

er sorry... that was an example of me being literal. The example in 
question is an OE ms page which Conal circulated to Council earlier, and 
which I started transcribing before realising that I couldnt do it!

> Finally, the document seems to have an extra </div> near the end, so 
> it's not quite well-formed. I think this is caused by commenting out 
> the opening <div id="surfzone"> and the heading "Surfaces and zones" 
> without commenting out its closing div tag.
>
correct again.... welcome to the engine room!


> Hope this is useful,

Yes, thanks very much. You didn't say "this is unworkable" which is what 
I was worrying you might!


>
> Martin
>
> Lou Burnard wrote:
>> Dear Martin
>>
>> I wonder if you have 5 minutes to take a look at a new section in 
>> P5?  Christian
>> Wittern suggested you would be a good person to review its 
>> feasibility (see below)
>>
>> Please send me any comments you have asap: the draft urgently needs  
>> more
>> reality checking before it's ready for prime time, and I'd really 
>> appreciate
>> your feedback
>>
>> best wishes
>>
>> Lou
>>
>>
>> ----- Forwarded message from Christian Wittern <cwittern at gmail.com> 
>> -----
>>
>> From: Christian Wittern <cwittern at gmail.com>
>> To: Lou Burnard <lou.burnard at computing-services.oxford.ac.uk>
>> Subject: Re: [tei-council] facsimile draft
>> Date: Tue, 07 Aug 2007 14:59:28 +0900
>>
>>
>> Lou Burnard wrote:
>>> As mentioned in the call, I've been working on trying to produce a 
>>> section about facsimile markup which could be plugged into the 
>>> current chapter on physical transcription, using as many as possible 
>>> of the ideas discussed here by Conal and others over the last few 
>>> weeks.
>>>
>>> Time is running out, and we need to get closure on this, so I hope 
>>> Conal and Dot will excuse me for steaming ahead on this without 
>>> consulting with them privately first. I've used the documents 
>>> circulated and followed (as far as I can) the discussion so far to 
>>> produce a straw-person kind of a draft which is now posted for your 
>>> (particularly their) urgent attention at 
>>> http://www.tei-c.org/Drafts/facs.odd
>>>
>> Thanks for getting it this far.  It seems pretty well worked through, 
>> at least as far as I can see by just reading through it. I wonder if 
>> it would be worthwhile to show this to Martin Holmes to see what he 
>> thinks -- if we get ever an implementation of this, he is among the 
>> likely implementers.
>>
>>
>>> I've deliberately restricted the scope of what this draft makes 
>>> possible to what I hope we can all agree on as a bare minimum of 
>>> functionality. It supports linking from text to image and image to 
>>> text with a minimum of fuss ; it also supports linking between text 
>>> and image fragments, but only provides one way to do it. It tries to 
>>> fit in with existing TEI idiom and practice.
>> I feel a bit uneasy about @facs doubling as a direct and indirect 
>> link -- are there other cases where we do something similar?
>>
>> One tiny piece of nit-picking:  in this list, you probably dont want 
>> the word "element" after facsimile?
>>
>> legal TEI document may thus comprise any of the following:-
>> <list>
>> <item>a TEI Header and a text</item>
>> <item>a TEI Header and a facsimile element</item>
>> <item>a TEI Header, a facsimile, and a text</item>
>> </list>
>>
>>
>>
>>> -- I've also made a wild guess about how to specify the datatype of 
>>> my @box attribute (formerly known as @coords -- I renamed it because 
>>> it is considerably more restricted than the synonymous XHTML attribute)
>>>
>> As Sebastian said, I would use the same type of arrangement for the 
>> coordinates as in HTML, SVG, CSS and who knows what, that is starting 
>> from the upper left corner.
>>
>> Christian
>>
>>
>