Scott Lawton <scott_bulkmail@productarchitect.com> writes:
Page number markup:
No complaints. I'll be looking into a transform that will place the numbers in the margin, but that is a secondary concern.
I didn't see an explicit way to mark the original page numbers. Perhaps as a marginal note?
<note place="margin">27</note> --
Page numbers are put in the `pb' pagebreak element. <pb n="27" /> ,----[ TEI Manual: 6.9.3 Milestone Tags ] | - <pb> marks the boundary between one page of a text and the next | in a standard reference system. | | `ed' (edition) indicates the edition or version in which the page | break is located at this point | | - <lb> marks the start of a new (typographic) line in some edition | or version of a text. | | `ed' (edition) indicates the edition or version in which the line | break is located at this point | | - <cb> marks the boundary between one column of a text and the next | in a standard reference system. | | `ed' (edition) indicates the edition or version in which the column | break is located at this point `---- There is no need for a `place' attribute, you can use rend="margin" instead. But this is confusing because this it's saying that the page breaks in the original edition were in the margin. And if so, which margin, left or right? Presentational markup should be used to indicate how the original was marked up. Instructions for how something should be displayed should be done using CSS or XSLT. I'm using a EETS edition of The Merlin as a development text because it has a running analysis in the left margin, footnotes, and indicates the page breaks in the original manuscript. So in the electronic edition I need to indicate two different sets of page breaks, one for the original manuscript and another for the page breaks in the EETS edition. This can easily be done using the edition `ed' attribute. <pb ed="ms" n="27" /> <pb ed="EETS" n="53" /> Learning TEI is like learning Emacs or Unix like systems. It's a gradual process of incremental epiphanies. TEI is a large and complex spec and takes some time to digest. More than once over the past couple of years I have quickly looked up something in TEI and thought that it was silly and then came up with my own alternate solution. However, most of the time, after putting my hack into practice I found it didn't work as I expect and finally understood why TEI had had done things the way they had. I've come to respect TEI more and more as a mature body of experience which I am trusting more and more. If something seems stupid or awkward I now try to stop and step back and assume that there is a good chance I don't understand the design before trying to cobble to together my own solution. Detractors of XML on this list have brought up the fact that the TEI manual is 1400 pages long as a negative. Why? This shows that TEI is well documented. As a general rule, the more documentation that is available for a spec the more mature and useful the standard and the easier it is to learn and implement. I remember a sig file from someone back in the early 90's that went something like, "documentation is a sign of failure". This is somewhat true for simple end-user applications, but it certainly isn't true for things like computer languages and markup languages. b/ -- Brad Collins <brad@chenla.org>, Bangkok, Thailand