Re: [bug-enscript] Question on "-2" column fill behaviour..

[Tim Retout]

On 19 September 2012 04:19, uhmgawa <address@hidden> wrote:

I can't say I've exactly

evaluated the internal structure of enscript vs. a2ps but baring some
internal fiasco it would be most advantageous to pool effort within
a single codebase.

Well, I'll give my point of view.

There are two binaries in GNU Enscript:  'enscript' and 'states'.  The latter is an awk-like tool that can process highlighting files.  The former is mostly a wrapper around 'states', except it also handles generation of postscript output.  Note that 'states' handles all other output formats itself, currently.

I don't like how 'states' needs to be invoked as a binary by the 'enscript' wrapper.  It's caused security issues in the past - and half of the codebase is probably complex option passing/parsing.  I just don't like working with Enscript's code.

Enscript's strengths are:

- highlighting uses a real parser (not just keyword matching)

- language support can be added without rebuilding Enscript, and a bunch of syntax files have already been written.

- it has support for output formats beyond PostScript (unlike a2ps).

However, GNU source-highlight is a strong competitor on all these points.  That program now uses external language definitions since version 2.0 - and from the docs, there's support for stateful matches (which ought to be enough to build good highlighting):

http://www.gnu.org/software/src-highlite/source-highlight.html#State_002fEnvironment-Definitions

Source-highlight does not support PostScript output, but it does support 10 others, so it seems quite flexible.  Also, it's written in C++, which might be an issue.

Rather than getting a2ps to invoke a highlighting binary, I would prefer that one of these tools ('states' or 'source-highlight') gets turned into a library, so that the highlighting can be used by multiple wrapper programs.  Then we focus syntax highlighting efforts in one place, and make use of it in a2ps, enscript, and wherever else.

Oh wait, version 3.0 of source-highlight apparently provides a C++ library.  Great!  It should be feasible to wrap it for calling from C.  Then figure out how to plumb it into a2ps, and you've combined the more flexible PostScript generation with better highlighting.

There might be loose ends like supporting RTF output somewhere, but that's a much smaller problem.

-- 
Tim Retout <address@hidden>