[oXygen-user] Pretty Print <lb/> in Oxygen

George Bina
Tue Oct 28 07:56:41 CDT 2014


Thanks Andreas! This shows that "lb" handling is a lot more complex :).

Ute, is the use of xml:space enough for you to control this? To automate 
formatting you can normalize the element that contains the <lb/> 
occurrences on one line and then replace " <lb/>" with a new line 
followed by <lb/> using the find/replace in files and then you may also 
use indent/unindent selection (tab / Shoft+Tab) to indent that as you want.

Best Regards,
George
--
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com

On 28/10/14 11:53, Andreas Wagner wrote:
> 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
>
>
>
>
>
> _______________________________________________
> oXygen-user mailing list
> 
> http://www.oxygenxml.com/mailman/listinfo/oxygen-user
>


More information about the oXygen-user mailing list