Values for att.placement about tei-simple HOT 18 OPEN

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

from tei-simple.

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

from tei-simple.

i have added overstrike to @place list

from tei-simple.

point taken about centre vs center - now consistent

from tei-simple.

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.

from tei-simple.

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.

from tei-simple.

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 <[email protected]mailto:[email protected]>
Reply-To: TEIC/TEI-Simple <[email protected]mailto:[email protected]>
Date: Sunday, April 19, 2015 at 08:28
To: TEIC/TEI-Simple <[email protected]mailto:[email protected]>
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.

from tei-simple.

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.

from tei-simple.

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

from tei-simple.

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.

from tei-simple.

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.

from tei-simple.

"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

from tei-simple.

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 <[email protected]mailto:[email protected]>
Reply-To: TEIC/TEI-Simple <[email protected]mailto:[email protected]>
Date: Sunday, April 19, 2015 at 5:17 PM
To: TEIC/TEI-Simple <[email protected]mailto:[email protected]>
Cc: Martin Mueller <[email protected]mailto:[email protected]>
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.

from tei-simple.

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

from tei-simple.

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 <[email protected]mailto:[email protected]>
Reply-To: TEIC/TEI-Simple <[email protected]mailto:[email protected]>
Date: Sunday, April 19, 2015 at 9:47 PM
To: TEIC/TEI-Simple <[email protected]mailto:[email protected]>
Cc: Martin Mueller <[email protected]mailto:[email protected]>
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.

from tei-simple.

If all page breaks have been marked properly including those for blank leaves then presumably odd numbered pbs will be rectos and even ones versos. But I wouldn't like to rely on it.

Sent from my Samsung Galaxy Tab®|PRO

-------- Original message --------
From: Sebastian Rahtz
Date:04/19/2015 23:24 (GMT+00:00)
To: TEIC/TEI-Simple
Subject: Re: [TEI-Simple] Values for att.placement (#12)

"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

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

from tei-simple.

Coming in late. Just a few points.
(1) Sequence of PBs is a poor guide to recto/verso. Text reading sequence does not necessarily follow straightforwardly page to page. Many, many pages are 'turned' backwards. Many textual objects spread across pages. Etc.
(2) The left/right and inner/outer distinctions are chiefly important when different SERIES of notes are placed differently. I.e., the significant point to capture is the note series, not necessarily its actual placement. To that extent, @place does double duty, and has some semantic (structural) function as well as a physically descriptive one. This semantic function could probably better be handled by @type, but in many cases it is not -- the encoder allowing the implicit semantics of the source to remain implicit in the distinction in the @place values. We actually reify this use/abuse by using values "marg" and "marg1" "marg2" etc., meaning 'note series in the margin, series 1'. Properly speaking, these should be tagged as place="marg" type="1" / place="marg" type="2" etc. By series I mean the sort of thing used by the standard critical edition of the Vulgate, or indeed many critical editions, e.g. series 1 is bibliographic, series 2 contains references to the Fathers, series 3 contains variant readings from MSS. etc. The more note-ridden editions of the Geneva Bible are particularly prone to this sort of thing (it uses three or four distinct, simultaneous series of marginal notes. Sometimes these distinctions are captured by numbering styles (a b c, 1 2 3, * ** etc.), sometimes by placement (inner/outer, left/right), sometimes by type face (roman, italic), sometimes by a combination.
(3) That said, we do not in general distinctinguish inner/outer or left/right -- not because books usually stick to one side (they don't), but because the distinction usually has no structural significance.
(4) Our other @place values for note are foot, inline, divend (at end of current div), parend (at end of current paragraph), and sometimes inter (interlinear).
(5) We don't distinguish 'shoulder' notes or 'inset' notes from marginal notes, nor do we distinguish true marginal notes from those that, needing more room, spread right across the page (very common, especially in my good friend Richard Baxter. See e.g. his Saints' Everlasting Rest.)

from tei-simple.

My take-away from this meticulous and clarifying comment is that for the purposes of TEI Simple we might as well stick to just "margin" and follow Paul's advice on type attributes. My hunch is that a human needs to look at the books where that is helpful or necessary, but there aren't that many, and they can with tolerable accuracy identified by their current encoding.

Paul's email shows that there are groups of texts that would benefit from some revisions or refinements in their encoding. That's not in scope for TEI Simple, but if the discussion of TEI Simple leads to discoveries of this kind that is a useful side effect. There will be people who care enough about the Geneva Bible to get it right, whether within or beyond the boundaries of Simple.

From: Paul Schaffner <[email protected]mailto:[email protected]>
Reply-To: TEIC/TEI-Simple <[email protected]mailto:[email protected]>
Date: Monday, April 20, 2015 at 8:17 AM
To: TEIC/TEI-Simple <[email protected]mailto:[email protected]>
Cc: Martin Mueller <[email protected]mailto:[email protected]>
Subject: Re: [TEI-Simple] Values for att.placement (#12)

Coming in late. Just a few points.
(1) Sequence of PBs is a poor guide to recto/verso. Text reading sequence does not necessarily follow straightforwardly page to page. Many, many pages are 'turned' backwards. Many textual objects spread across pages. Etc.
(2) The left/right and inner/outer distinctions are chiefly important when different SERIES of notes are placed differently. I.e., the significant point to capture is the note series, not necessarily its actual placement. To that extent, @placehttps://github.com/place does double duty, and has some semantic (structural) function as well as a physically descriptive one. This semantic function could probably better be handled by @typehttps://github.com/type, but in many cases it is not -- the encoder allowing the implicit semantics of the source to remain implicit in the distinction in the @placehttps://github.com/place values. We actually reify this use/abuse by using values "marg" and "marg1" "marg2" etc., meaning 'note series in the margin, series 1'. Properly speaking, these should be tagged as place="marg" type="1" / place="marg" type="2" etc. By series I mean the so rt of th ing used by the standard critical edition of the Vulgate, or indeed many critical editions, e.g. series 1 is bibliographic, series 2 contains references to the Fathers, series 3 contains variant readings from MSS. etc. The more note-ridden editions of the Geneva Bible are particularly prone to this sort of thing (it uses three or four distinct, simultaneous series of marginal notes. Sometimes these distinctions are captured by numbering styles (a b c, 1 2 3, * ** etc.), sometimes by placement (inner/outer, left/right), sometimes by type face (roman, italic), sometimes by a combination.
(3) That said, we do not in general distinctinguish inner/outer or left/right -- not because books usually stick to one side (they don't), but because the distinction usually has no structural significance.
(4) Our other @placehttps://github.com/place values for note are foot, inline, divend (at end of current div), parend (at end of current paragraph), and sometimes inter (interlinear).
(5) We don't distinguish 'shoulder' notes or 'inset' notes from marginal notes, nor do we distinguish true marginal notes from those that, needing more room, spread right across the page (very common, especially in my good friend Richard Baxter. See e.g. his Saints' Everlasting Rest.)

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

from tei-simple.