Bernd K?mmerlen wrote: > the new "split"-behaviour for DocBook-files in XXE 2.6 is a little bit > awkward when it comes to programlisting and literallayout elements.
It is certainly akward because this is not the intended behavior. One of the goals of XXE V2.6 is to be less awkward, not more awkward. > With the way that docb.splitOrInsertNewLine is currently implemented, it > is not possible to insert a newline into a programlisting or > literallayout element, instead the element is split (which is probably > not what the user wants in this case). It is currently possible to insert newlines into a programlisting or literallayout element, we do that all the time here at XMLmind. The problem comes from the fact that your users insert programlisting or literallayout elements *inside* paras, which even if allowed by the DTD, is a bad habit. If instead, they inserted programlisting or literallayout elements before or after paras, you wouldn't have noticed any problem. > I adapted this macro a bit to allow insertion of newlines into these > elements, maybe you could consider to include this in a future release? > I am also currently not sure if any other elements should be treated > like this. > > Here's the changed macro: > > <command name="docb.splitOrInsertNewLine"> > <macro trace="false"> > <choice> > <sequence> > <command name="selectNode" > parameter="ancestorOrSelf[implicitElement] programlisting > literallayout" /> > <command name="insertControlChar" parameter="\n" /> > </sequence> > <sequence> > <command name="selectNode" > parameter="ancestorOrSelf[implicitElement] simpara para" /> > <command name="split" /> > </sequence> > > <command name="insertControlChar" parameter="\n" /> > </choice> > </macro> > </command> We'll of course fix this problem in next release.
