Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 590933 - Code highlighting breaks on a hard return inside an attribute and with an ellipsis in a Java programlisting
Code highlighting breaks on a hard return inside an attribute and with an ell...
Product: Publican
Classification: Community
Component: publican (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Jeff Fearn
Fedora Extras Quality Assurance
: 602008 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2010-05-10 22:01 EDT by Ruediger Landmann
Modified: 2010-11-23 23:19 EST (History)
5 users (show)

See Also:
Fixed In Version: 2.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-08-05 00:14:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
CPAN 58326 None None None Never

  None (edit)
Description Ruediger Landmann 2010-05-10 22:01:59 EDT
Description of problem:
Code highlighting breaks under the following conditions:
* a hard return inside an attribute in an XML programlisting, for example:

<portlet-app xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd"

* an ellipsis inside a Java programlisting, for example:

      PortletRequestDispatcher prd = getPortletContext().getRequestDispatcher("/jsp/edit.jsp");
      prd.include(rRequest, rResponse);

and with an ellipsis in a Java programlisting

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Include either of the above conditions in a book
2. run publican build
Actual results:
Build fails during code highlighting

Expected results:
Build succeeds and code highlighted.
Comment 1 Jeff Fearn 2010-05-10 23:23:22 EDT
keyword tags with line wraps were causing problems. Added code to detect line wraps and split tags where required.
Comment 2 Ruediger Landmann 2010-05-11 00:36:45 EDT
Fix verified in 1.6.2.t169 -- neither of these scenarios stops a build any longer.
Comment 3 Ruediger Landmann 2010-06-09 06:57:49 EDT
*** Bug 602008 has been marked as a duplicate of this bug. ***
Comment 4 Ruediger Landmann 2010-06-10 01:09:04 EDT
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>
	<callout arearefs="index1">
		<literal>column_name</literal> (required): the name of the column holding the
		collection index values.
	<callout arearefs="index1">
		<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:

<list-index column="column_name"

allows it to build
Comment 5 Jeff Fearn 2010-06-10 02:37:53 EDT
(In reply to comment #4)
> And this is the content of: extras/collection_mapping/default107.xml
> <list-index 
>         column="column_name"
>         base="0|1|..."/>

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
Comment 6 Jeff Fearn 2010-06-10 20:57:50 EDT
I've opened a bug for Kate, still looking in to why the XSLT process dies on the new line.
Comment 7 Jeff Fearn 2010-06-11 00:56:42 EDT
Ah ha!

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

Note You need to log in before you can comment on or make changes to this bug.