Hi all, * George Bina dixit [2014-10-28 00:02]:
Syd was talking about the Text editing mode. We treat space preserve versus mixed content versus element only content but the semantics of lb is somehow special... For example, if we have:
<p>test<lb/>new line</p>
Then oXygen will consider this as mixed content and it will not add new whitespace where there is none, that means it will never add whitespace immediately before or after <lb/> in this case. This
<p>test <lb/>new line</p>
is not equivalent to the original is you apply a space normalization algorithm on the text content of the p element but in this case the semantics of <lb/> itself implies a whitespace so theoretically they are equivalent.
I would like to reaffirm the non-equivalence of the two examples and add a use case. In fact, <lb/> is even more special: It is member of the att.breaking group, so an additional attribute @break specifies whether or not an instance of <lb/> implies whitespace or not. You cannot by the mere presence of the <lb/> element decide whether or not whitespace should be present or not. In our texts we have lots of word breaks across lines (some of which are marked with a hyphenation dash and some of which are not), so we use <lb/> and <lb break="no"/> - and the latter comes in two flavours again: <lb break="no" rendition="#hyphen"/> and <lb break="no" rendition="#noHyphen"/>. Adding whitespace around the non-breaking <lb/>s would in fact corrupt our documents, making tokenizations algorithms that are aware of the "non-breakingness" of those <lb/>s fail. In our author mode css, we try to display these various cases this way: lb{ display:inline; -oxy-display-tags:none; } lb:before{ content:"\A("attr(n)") ‣ "; font-size:0.6em; white-space: pre-line; } lb[rendition="#hyphen"]:before{ content:"¬\A("attr(n)") ‣ "; font-size:0.6em; white-space: pre-line; } lb[rendition="#noHyphen"]:before{ content:"[¬]\A("attr(n)") ‣ "; font-size:0.6em; white-space: pre-line; } (And then there is some stuff to prevent those "manually added" linebreaks (\A) in the :before selectors in the case of the first line of a paragraph/heading etc. But this doesn't work 100%... The point is, we have a second "style" css which eliminates the linebreaks and renders the text according to the dimensions of the current window: @import url("standard.css"); lb[rendition="#hyphen"]:before{ content:""; } lb[rendition="#noHyphen"]:before{ content:""; } In the case of non-breaking <lb/> this reconstructs the hyphenated/broken words correctly. (And in the case of breaking <lb/> we have whitespace around the <lb/> in our xml sources anyway. But for this whole setup it is crucial that oXygen does not mess with whitespace around <lb/>s. Our sources, after manual formatting, look like this: <lb n="01" />OFFICIUM, ac munus Theologi <lb n="02" />tam latè patet, ut nullum argumen<lb break="no" rendition="#hyphen" n="03" />tum, nulla disputatio, nullus locus <lb n="04" />alienus videatur à theologica profes<lb break="no" rendition="#noHyphen" n="05" />sione, et instituto. <lb n="06" />... (Unfortunately, it keeps getting messed up, but I think this is due to our XML database (eXist) storing the file internaly as an xml tree and forgetting all the layout and serializing it according to less sophisticated rules when opening it in Oxygen. However, this concerns only the linebreaks in our xml files, not the <lb/> elements and the whitespace around them, so it does not affect our ability to offer the same rendering options to a viewer via xslt...) Bottom line: Please don't mess with whitespace around <lb/> elements (or if you do, offer an option to disable this). There are use cases explicitly provided for by the <lb/> element and its attributes where the exact placement of whitespace is crucial. Cheers, Andreas -- Dr. Andreas Wagner Project "The School of Salamanca" Academy of Sciences and Literature, Mainz and Institute of Philosophy Goethe University Frankfurt http://salamanca.adwmainz.de IGF HP 25 / R 2.455 Grüneburgplatz 1 60629 Frankfurt am Main Tel. +49 (0)69/798-32774 Fax +49 (0)69/798-32794