Re[2]: [docbook-apps] Syntax coloring of programlisting

[techtonik <techtonik at tut dot by>]

||*()*||    [\..konnichi wa, ogenki desu ka, Frans../]

FE> So.. the scenario looks like this: tons of programlistingS are sprinkled
FE> across the XML document, and they are to be read, and then transformed 
FE> (somehow) to colored syntax in at least XHTML, and then be sewn back in with 
FE> the rest of the output.

FE> Colorer have a helper program, linking against its library, which takes input
FE> and then spits out an html file; assuming we can trim away unnecessary 
FE> html/head/body tags from the output, or that Colorer implemented a suitable 
FE> output(and perhaps XSL-FO) -- how would it get back in into the document?

FE> One possibility is to break out every programlisting into a separate 
FE> file(cumbersome), have a Makefile keep a syntax output file up-to-date for 
FE> every programlisting file, and then have XIncludes pull those output files 
FE> into the document. This would work for static setups, HTML output, and be 
FE> ugly. Fine grained control, play well with web setups, or be swift, is 
FE> abscent. 

FE> The problem is of making a binary(Colorer) play well with XML. That's the 
FE> advantage of writing it in XSLT; it's integrated by definition, and plays 
FE> perfectly with any combinations, the drawback on the other hand, is of 
FE> writing it, and making sure it does what it exists for well.

I can't say if it is possible to rewrite it in XSLT. To me the only man who
can answer this question is Igor Russkih, author of Colorer. I think
the proper place to ask him would be colorer-talks@lists.sourceforge.net

FE> I still think that writing an XSLT 2.0 template which does reasonable 
FE> highlightning of a programming language(in my case C++) is over comeable. 
FE> Once a regexp which spots multiline comments/strings is developed, it should 
FE> be pretty straight forward.. The advantage would be the swift integration, 
FE> and a dependency dropped. 

The problem as I can see it to make XSLT rules process logic, stored
in external files. XSLT template defines rules by which source
document must be transformed to get output document. That means,
that logic must be transformed into XSLT template first for every
language that must be highlighted. I don't know if it is possible to
do it from Colorer's HRC files.

It seems to me that another problem with programlisting is that it
contains escaped symbols, and template should operate on non-escaped
content.

FE> However, it would nevertheless be of more interest to use Colorer. Let's say 
FE> it outputs XHTML without html, head, and body tags, and that it also can 
FE> output XSL-FO; how does the programlisting content get in and out in the 
FE> transformation process? 

It can be an extension function for Java or C XSLT processor (probably XSLT 2.0
provides that feature). Or it can be multipass solution, when special template
on first pass chunks programlisting's contents and replaces them
with entities generated from id's. Chunk can be named as
programlisting34879.input.langtype. Also this template chunks index file, where
all these entities will be defined like:

<!ENTITY programlisting34879 SYSTEM
'./programlistings/programlisting34879.output'>

After that on the second stage some batch file uses Colorer or any
other highlightning engine to convert
programlisting34879.input.langtype into
programlisting34879.output and on the third pass you include
index file with entities into your XML from the first pass and parse it
like DocBook (assuming, that programlisting34879.output contains xhtml
tags you need to use xsl:copy-of while processing entity contents).

I'd like to hear critique about this theory since I don't have enough
experience to prove XSLT stuff will work. The thing I know works 100%
is to generate html from docbook with <code class="programlisting"/>
sections. Then refine these sections with the help of simple PHP
script together with some colorer engine. That way PHP Manual is built.

-- 
                   //Old Rusty Cans Killers [ORCK]:
                   //technically yours, techtonik