[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re[2]: [docbook-apps] Syntax coloring of programlisting
||*()*|| [\..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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]