This is the mail archive of the
docbook-apps@lists.oasis-open.org
mailing list .
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