Bug 590933

Summary:	Code highlighting breaks on a hard return inside an attribute and with an ellipsis in a Java programlisting
Product:	[Community] Publican	Reporter:	Ruediger Landmann <rlandman+disabled>
Component:	publican	Assignee:	Jeff Fearn 🐞 <jfearn>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	1.6	CC:	bclare, jfearn, mmcallis, publican-list, rlandman
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	2.0	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-08-05 04:14:42 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Ruediger Landmann 2010-05-11 02:01:59 UTC

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"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd 
                                         http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd"
   version="2.0">

* an ellipsis inside a Java programlisting, for example:

   {
      rResponse.setContentType("text/html");
      PortletRequestDispatcher prd = getPortletContext().getRequestDispatcher("/jsp/edit.jsp");
      prd.include(rRequest, rResponse);
   }
...</programlisting>

and with an ellipsis in a Java programlisting

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

How reproducible:
100%

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-11 03:23:22 UTC

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 04:36:45 UTC

Fix verified in 1.6.2.t169 -- neither of these scenarios stops a build any longer.

Comment 3 Ruediger Landmann 2010-06-09 10:57:49 UTC

*** Bug 602008 has been marked as a duplicate of this bug. ***

Comment 4 Ruediger Landmann 2010-06-10 05:09:04 UTC

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:

<programlistingco>
    <areaspec>
	<area id="index1" coords="2 45"/>
	<area id="index2" coords="3 45"/>
    </areaspec>
    <programlisting language="XML" role="XML"><xi:include parse="text" href="extras/collection_mapping/default107.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
    <calloutlist>
	<callout arearefs="index1">
	    <para>
		<literal>column_name</literal> (required): the name of the column holding the
		collection index values.
	    </para>
	</callout>
	<callout arearefs="index1">
	    <para>
		<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.
	    </para>
	</callout>
    </calloutlist>
</programlistingco>


And this is the content of: extras/collection_mapping/default107.xml

<list-index 
        column="column_name"
        base="0|1|..."/>

which fails. Changing that to:

<list-index column="column_name"
        base="0|1|..."/>

allows it to build

Comment 5 Jeff Fearn 🐞 2010-06-10 06:37:53 UTC

(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-11 00:57:50 UTC

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 04:56:42 UTC

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