This is the mail archive of the docbook-apps@lists.oasis-open.org mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [docbook-apps] Syntax coloring of programlisting


On Monday 08 November 2004 18:31, techtonik wrote:
<snip>

> If you need Java or C solution - take a look
> onto http://colorer.sf.net. It is free library, plugins available for
> Eclipse and Far Manager. Colorer uses XML files to store infomation
> about dozens of file formats. I think it is rather complicated task
> for XSLT stylesheet. Though it is possible that colorer uses some
> similar techniques, since it's highlightning configuration is
> at least well-formed. =)

Colorer surely is competent. On the other hand is it too competent -- it is an 
API which text editors can be built from -- although that doesn't hurt, but 
in case it is necessary to duplicate/reimplement coloring functionality, it 
is not necessary to reach the same level as Colorer. But nevertheless, 
reaching the functionality which is necessary, in a way just as good as 
Colorer, is though, so using Colorer is by no doubt of interest. And it would 
be silly to reimplement too(if there not are _really_ good reasons).

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

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

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

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

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

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


Cheers,

		Frans








Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]