Red Hat Bugzilla – Bug 590933
Code highlighting breaks on a hard return inside an attribute and with an ellipsis in a Java programlisting
Last modified: 2010-11-23 23:19:59 EST
Description of problem:
Code highlighting breaks under the following conditions:
* a hard return inside an attribute in an XML programlisting, for example:
* an ellipsis inside a Java programlisting, for example:
PortletRequestDispatcher prd = getPortletContext().getRequestDispatcher("/jsp/edit.jsp");
and with an ellipsis in a Java programlisting
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Include either of the above conditions in a book
2. run publican build
Build fails during code highlighting
Build succeeds and code highlighted.
keyword tags with line wraps were causing problems. Added code to detect line wraps and split tags where required.
Fix verified in 1.6.2.t169 -- neither of these scenarios stops a build any longer.
*** Bug 602008 has been marked as a duplicate of this bug. ***
This is still failing on 1.99.t90 when the xi:included code includes a hard return between the name of the element and the first attribute on that element.
This is the code:
<area id="index1" coords="2 45"/>
<area id="index2" coords="3 45"/>
<programlisting language="XML" role="XML"><xi:include parse="text" href="extras/collection_mapping/default107.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
<literal>column_name</literal> (required): the name of the column holding the
collection index values.
<literal>base</literal> (optional - defaults to <literal>0</literal>): the value
of the index column that corresponds to the first element of the list or array.
And this is the content of: extras/collection_mapping/default107.xml
which fails. Changing that to:
allows it to build
(In reply to comment #4)
> And this is the content of: extras/collection_mapping/default107.xml
The problem is being triggered by the white space after list-index, removing it avoids this trigger.
This trailing white space is causing Syntax-Highlight-Engine-Kate to have a tag open across two lines, this triggers what I believe is a bug in the XSL parser.
There are newer versions of Kate upstream, so I will look to see if one of them fixes the white space issue, if not I'll open a bug upstream.
I'm also not sure why having an opening/closing tag pair across two lines causes the XSL parser to die. I'll see if I can debug that.
FWIW I checked in a work around for this particular trigger in to the 1.6. branch; there are no doubt many other triggers though so I'd like to pursue a better solution.
Worked around in build: 1.6.3-0.t104
I've opened a bug for Kate, still looking in to why the XSLT process dies on the new line.
The real problem here was that because we have to process the call outs line by line to insert the image nodes in the correct place, tags that cross line boundaries are "broken" as far as the parser can tell, since it only sees one line at a time.
I modified the highlighting XSL to split tags when they cross lines, so the call out code never gets multi-line tags, and thus it won't blow up. This should be more robust.
While I was in there I added support for LineColumn coords, since we only supported Line number. I did make it ignore the column if it's less than the actual line length though. Currently the column defaults to the greater of 45 or the width of the widest line + 4.
Fixed in build: 1.6.3-0.t113