On Mon, 2012-12-10 at 17:31 +0000, Sebastian Rahtz wrote:
> On 10 Dec 2012, at 17:06, Louis-Dominique Dubeau <[log in to unmask]> wrote:
> > I think it is cleaner, but I've noticed that in the bargain we've gained
> > quotes. If I use the test I initially created (before I decided that
> > maybe my understanding was confused) and diff the before and after, I
> > see:
> > $ diff old/test1-fmt.html test1-fmt.html
> > 23c23
> > < <div class="p">Blah <span class="quote_inline">bluh</span>.</div>
> > ---
> >> <p>Blah <span class="quote">‘bluh’</span>.</p>
> I take your point; its not the whole story, though. Quotes sometimes
> were being added and sometimes not. I can't decide whether to
> add them or not, to be honest. Do I:
> a) do nothing. in which case the default <q>hello</q> will show nothing visible at all
(You mention <q> but the example above was generated using <quote>. So I
talk about <quote> below.)
That's what used to happen in the simple case of <q><quote></quote></p>
but I guess that's a bug. It so happens that this bug agreed with my own
purposes. I waffled between quotes added by the stylesheet and quotes in
the source until I encountered something like:
<p>In his treatise, he said: <cit><quote>"Whole paragraph from some
original source." "2nd paragraph in the original
source."</quote><bibl> ... </bibl></cit></p>
As noted in the text of the example, this is a case where someone was
quoting whole paragraphs. The paragraph are not represented as
paragraphs but are marked by pairs of quotes. I decided that quotes
should be encoded in the source. Sure, I could use @rend or some other
means to treat this case differently but I prefer to have quotes treated
uniformly: capture them all.
> b) add quotes in the CSS
> c) examine the header and try and work out if the user has said whether or not they have added quotes themselves
That might be part of a solution.
> d) some other algorithm
Make it customizable through parameters? I'm absolutely certain that
whatever you settle on will not work for everyone.
> > However, the
> > upshot for someone who's been working with the previous release of TEI
> > is a new release that breaks what used to work.
> true. but I suspect it was inconsistent before..
Just to be clear, I'm not saying the change should not be made. If there
was inconsistency, then the inconsistency should be fixed.
> > The way <p> is now handled works for my use, but looking at just about
> > any philosophy book I can pull off my shelves, I see lists and quotes
> > which look to me to be embedded in paragraphs. This I infer by the lack
> > of indentation at the start of the block of text appearing just after
> > the quote or list. So it does seem that somewhere down the road someone
> > is going to be unhappy with interrupted paragraphs.
> that depends on the rendering, doesn't it. subsequent generated paragraphs
> should then have some "no indent" info added.
> oh dear.
Yes, "no indent" plus probably other parameters. The first thing that
came to mind was paragraph numbering. Additional paragraphs created to
encode fragments of what was originally one TEI paragraph should not get
numbers. I thought maybe I'd check how TEI currently does it but it
seems the latest version of the xhtml2 code no longer checks whether the
numberParagraphs parameter is set.
But there are other scenarios beside numbering. If I have a special
paragraph that I want to treat in a special way and give it
xml:id="SPECIAL" and that paragraph happens to have lists or block
quotes in it, a simple CSS selector based on id won't work. There are
certainly ways to get around it.
Back when I worked in the paper->electronic conversion business, data
entry was done using a tagging system designed in-house, which included
something like a "paragraph continuation". There were good reasons
(reasons that were good back then) to have such an entity, but how I
hated the complications that this abomination caused during data
processing. When I think about paragraphs being broken into pieces to
accommodate lists and quotes, I flack back to those paragraph
continuations, not in a good way.
> > Reflecting out loud now (so to speak), I'm inclined to think now that
> > boiling down block elements to div --- as mentioned by other list
> > members --- would be the method least likely to create issues down the
> > road.
> I foresee dangers along any road. Oh lord, maybe I have
> to make the choice between methods a new parameter,
> and you get to choose.
Maybe. I see how some people would prefer to have an output that
reflects the structure of TEI input more closely so that they can think
in terms of the original document structure for styling purposes. I can
also see how someone would prefer an output that uses HTML more