Values for att.placement

[adunning]

Your expanded list of values in att.placement is very helpful: this was one of the things I found particularly unclear when I was starting out with TEI.

One thing I don’t see there is an equivalent to EpiDoc’s ‘overstrike’, indicating that something has been written or carved over whatever was there before (which may or may not be decipherable). I assume that ‘inline’ is not referring to this, which I would take as indicating, for example, that a character had been squeezed between two others. I'm not sure what this should be called; 'superimposed' is one example in the Guidelines that isn't specific to a particular medium.

It could also be helpful to have a 'centre' or 'textblock' value (though there might be a better solution that I am missing here). For instance, if one is using this list to roughly record the position of an annotation on a page, what would one do if it was placed somewhere in the middle of the page (e.g. on a page with relatively little text, such as a title page or verso)?

I also wonder about the definition of 'margin' as 'in the outer margin', whereas the Guidelines give it as 'in the margin (left, right, or both)'. The TEI Simple additions pinpoint the ambiguity precisely, but on the other hand I can see them leading to inconsistency, with some people using 'margin-left' and 'margin-right' and others 'margin' – and then what if you wanted to say that something was in the inner margin?

[adunning]

Further to this, I wonder if 'centre'/'textblock' could somehow be merged with 'block', which caused some confusion in #9 (before seeing that issue, I did not understand the intended use for it, since the current description sounds like something that belongs in @rendition).

[adunning]

Additionally (sorry about all these messages), I assume that 'top-center' and 'bottom-center' should read '-centre' to match @rendition.

[sebastianrahtz]

i have added overstrike to @place list

[sebastianrahtz]

point taken about centre vs center - now consistent

[sebastianrahtz]

hard to decide about the margin confusion. what I have done in the interests of clarity is remove plain 'margin' and only allowed margin-left and margin-right. sad to drop outer and inner, but seems easier this way.

[adunning]

To be fair, I can think of a use case for having 'margin-outer' and 'margin-inner' as well: if one wanted to record sidenotes that always appeared in the outer margin, chances are that in rendering this one would want them to appear consistently in either the left or right margin of a webpage, and not be flipping back and forth.

[martinmueller39]

Does this get us into levels of granularity that go beyond TEI Simple? 'margin-left' and 'margin-right' should cover the vast majority of cases. A use case in which readers' marginalia are recorded by their placement could presumably be dealt with by special rendition values.

MM
Martin Mueller
Professor emeritus of English and Classics
Northwestern University

From: Andrew Dunning <notifications@github.commailto:notifications@github.com>
Reply-To: TEIC/TEI-Simple <reply@reply.github.commailto:reply@reply.github.com>
Date: Sunday, April 19, 2015 at 08:28
To: TEIC/TEI-Simple <TEI-Simple@noreply.github.commailto:TEI-Simple@noreply.github.com>
Subject: Re: [TEI-Simple] Values for att.placement (#12)

To be fair, I can think of a use case for having 'margin-outer' and 'margin-inner' as well: if one wanted to record sidenotes that always appeared in the outer margin, chances are that in rendering this one would want them to appear consistently in either the left or right margin of a webpage, and not be flipping back and forth.

Reply to this email directly or view it on GitHubhttps://github.com//issues/12#issuecomment-94271288.

[adunning]

By 'sidenotes' I meant the printed running headings commonly found in books before the twentieth century. There are simply some typesetters and scribes who understand the margins as left and right, and others who approach them as inner and outer, with rather different results.

[sebastianrahtz]

I can jump either way on this. anyone else want to vote?

[adunning]

There is a good case both ways: it really boils down to whether people need to have the option to think in terms of page spreads rather than individual pages. To give a practical example, if one was doing something like transcribing the running headings in the margins of a book from the Rolls Series, one would want to be able to have these always render in the same place on a continuous-scroll webpage. If one transcribed the headings on p. 210 with something like <label place="margin-left"/> and those on p. 211 with <label place="margin-right"/>, I imagine this would be slightly more awkward than necessary to accomplish, and with simpler books such as this more difficult to encode. If this assumption is correct, I would advocate for separate 'margin-outer' (with plain 'margin' mapping to this, following your earlier redefinition) and 'margin-inner' values. But if you can think of an easy way to get around this in XSLT, it might not be necessary.

[martindholmes]

I don't think the decision should really be driven by rendering concerns, should it?

Is there a standard way in Simple to specify whether a page is a recto or a verso? If so, then combining that with margin left and margin right should allow any processor to infer inner and outer, presumably; and the encoding would still remain descriptive of the source rather than driven by rendering.

[sebastianrahtz]

"Is there a standard way in Simple to specify whether a page is a recto or a verso" - an interesting idea. The short answer is no. Should there be?

I incline at present towards Andrew's view that right/left and inner/outer pairs mean different things to different people, and we probably need both

[martinmueller39]

I'm glad you're saying this because I had been thinking along similar lines. If it is known whether the page is recto or verso things are simpler.

As for the TCP texts, if there are two elements with the same REF value, it is a safe assumption that the first element describes the left page of a double page image and the second the right. If there is only one PB element all bets are off. There are quite a few such cases.

From: Martin Holmes <notifications@github.commailto:notifications@github.com>
Reply-To: TEIC/TEI-Simple <reply@reply.github.commailto:reply@reply.github.com>
Date: Sunday, April 19, 2015 at 5:17 PM
To: TEIC/TEI-Simple <TEI-Simple@noreply.github.commailto:TEI-Simple@noreply.github.com>
Cc: Martin Mueller <martinmueller@northwestern.edumailto:martinmueller@northwestern.edu>
Subject: Re: [TEI-Simple] Values for att.placement (#12)

I don't think the decision should really be driven by rendering concerns, should it?

Is there a standard way in Simple to specify whether a page is a recto or a verso? If so, then combining that with margin left and margin right should allow any processor to infer inner and outer, presumably; and the encoding would still remain descriptive of the source rather than driven by rendering.

Reply to this email directly or view it on GitHubhttps://github.com//issues/12#issuecomment-94319245.

[adunning]

It isn't only a rendering issue: I imagine that the reason why the general 'margin' value exists in the first place is that positioning to the left or right is irrelevant for some books, especially if only one margin is used, which in the vast majority of cases is the outer. The point I was originally trying to make is that the proposed redefinition in TEI Simple makes sense, but I do not think that that label makes its intended function clear. If one were transcribing the book I cited above, it's both faster and more useful to specify that all the running headers are in the outer margin rather than worrying about switching this attribute on every page; indeed one would gain nothing by going to this trouble.

If one is working on a book that uses both margins for different purposes (e.g. one I looked at recently that used the inner margin for cross-references, and the outer for footnotes), marking things as inner/outer or left/right according to the logic of the original designer can double as a useful means of categorization (meaning e.g. that you could do a simple find/replace after basic encoding to add more attributes).

[martinmueller39]

This is a very helpful email, Andrew. I pick up on a) your point that in the "vast majority" of cases the margin is the outer margin and b) your discovery of a real example of a text where the inter and outer margins are used for different purposes. Which reminds me of two-column bibles, where a "central margin" (if there can be such a thing) is used for cross-references.

TEI Simple started out as an 80/20 project. If we stick to an 80/20 or even 90/10 philosophy we should just say 'margin' and leave more granular terms to customization in those rare cases where it is needed. There is always this or that to be said in favour of adding a choice. Each choice adds a little in expressivity at the cost of a small loss in simplicity. It's hard to know where to draw the line

From: Andrew Dunning <notifications@github.commailto:notifications@github.com>
Reply-To: TEIC/TEI-Simple <reply@reply.github.commailto:reply@reply.github.com>
Date: Sunday, April 19, 2015 at 9:47 PM
To: TEIC/TEI-Simple <TEI-Simple@noreply.github.commailto:TEI-Simple@noreply.github.com>
Cc: Martin Mueller <martinmueller@northwestern.edumailto:martinmueller@northwestern.edu>
Subject: Re: [TEI-Simple] Values for att.placement (#12)

It isn't only a rendering issue: I imagine that the reason why the general 'margin' value exists in the first place is that positioning to the left or right is irrelevant for some books, especially if only one margin is used, which in the vast majority of cases is the outer. The point I was originally trying to make is that the proposed redefinition in TEI Simple makes sense, but I do not think that that label makes its intended function clear. If one were transcribing the book I cited above, it's both faster and more useful to specify that all the running headers are in the outer margin rather than worrying about switching this attribute on every page; indeed one would gain nothing by going to this trouble.

If one is working on a book that uses both margins for different purposes (e.g. one I looked at recently that used the inner margin for cross-references, and the outer for footnotes), marking things as inner/outer or left/right according to the logic of the original designer can double as a useful means of categorization (meaning e.g. that you could do a simple find/replace after basic encoding to add more attributes).

Reply to this email directly or view it on GitHubhttps://github.com//issues/12#issuecomment-94343945.