> (I'm not sure that I'm convinced CSS is the tool for the job of
> describing the layout of words and symbols on stone, but that is
> probably an argument for another venue.)
Why not? I concede that it's not going to handle the depth dimension,
but for the layout of any text on any surface it seems pretty much
perfect to me. In this discussion, we've seen an interesting catalogue
of idiosyncratic approaches to this, with a variety of project-specific
attribute values that are surely not portable; standardizing on CSS
would be a great improvement, in my view. CSS also gives you the ability
to be precise and specific about positioning, text size, etc. in a
variety of ways, to suit your purpose (inches, centimeters, ems, points,
pixels etc.). It's a well-maintained and well-tested standard in steady
development, with very wide support, and easy to learn. W
hy are we encouraging people to invent their own methods of encoding
this kind of thing, or vaguely suggesting things without endorsing them
properly:
"These Guidelines make no binding recommendations for the values of the
rend attribute; the characteristics of visual presentation vary too
much from text to text and the decision to record or ignore individual
characteristics varies too much from project to project. Some
potentially useful conventions are noted from time to time at
appropriate points in the Guidelines. "
when there's a perfectly good standard we could adopt?
The @rend example in the guidelines shows this:
<head rend="align(center) case(allcaps)">
which is no different (but less portable and user-friendly) than this:
<head rend="text-align: center; text-transform: uppercase;">
Cheers,
Martin
Gabriel Bodard wrote:
> We *do* care about all such typographic oddities in our source texts
> (ancient inscriptions and papyri), and although we don't generally work
> with printed texts we do come across odd words transposed onto adjacent
> lines, or curving up into the margin, etc.
>
> As other have said, however, the absolutely first priority is to encode
> the text in the order in which it is meant to be read, whether in verse
> or prose. (In fact our markup of either kind of text prioritizes
> typographic layout--each line begins with <lb/>--the only difference
> being that prose is contained in <p> or <ab> while verse is in <lg> and
> <l>.) Text that is written in another line (or a margin, etc.), we would
> probably tag as <add place="line-above">, or perhaps <hi rend="above">
> if we think this was not an addition but a space-saving tactic.
>
> (I'm not sure that I'm convinced CSS is the tool for the job of
> describing the layout of words and symbols on stone, but that is
> probably an argument for another venue.)
>
> G
>
> On 18/04/2010 17:28, Lou Burnard wrote:
>> I've just spent an hour or two reviewing our discussion of last month
>> about linebreaks and hyphenation. I made the rather dispiriting (or
>> maybe encouraging) discovery that we went through almost exactly the
>> same set of arguments on this list in March 2003, so I then started to
>> think about a different though possibly related problem.
>>
>> Here's a picture of a common phenomenon in early printed books as well
>> as some 19th century editions which try to emulate them:
>>
>> http://books.google.co.uk/books?id=FYg9AAAAcAAJ&pg=RA1-PA30&img=1&zoom=3&hl=en&sig=ACfU3U1F0WGmOxNS0-7naAGEeMnZ6QmZkg&ci=80%2C225%2C877%2C210&edge=0
>>
>> The word "praise" belongs logically at the end of the line following
>> that on which it actually appears.
>>
>> How do people who care about preserving the source typography encode
>> things like this in TEI? should the Guidelines provide guidance on the
>> topic?
>>
>> (The fact that this text is in verse perhaps complicates the issue --
>> for extra brownie points, comment on how you would deal with the same
>> phenomenon in prose)
>
--
Martin Holmes
University of Victoria Humanities Computing and Media Centre
([log in to unmask])
Half-Baked Software, Inc.
([log in to unmask])
[log in to unmask]
|
