Drop a2ps or/and enscript from the book.

[Ag. Hatzimanikas]

Currently there are 3 applications in the book that are doing the same job.

A2ps is unmaintaned.

Since paps is working fairly well in all locales,there is no reason to keep a2ps or enscript in the book.

At least on of them (if both) should be removed.

[dnicholson@…]

Does paps provide the same feature set as a2ps and/or enscript? Are there any other modern tools that would fill this feature gap? Are these features worth caring about? I don't really use these kind of tools much, so I need more input from the community. Otherwise, I don't have any problems dropping both packages post-6.2.

[alexander@…]

paps doesn't do syntax highlighting when printing source code.

[Ag. Hatzimanikas]

Sory for the late reply Alexander. Priorities (you know 3 children,wife ...) especially the latter :).

I am afraid I have to reopen the ticket for at least one more try,feel free to close it again (as invalid?- by creating those "Drop tickets" I am trying to record -just record for now - eternal discussions in blfs-dev/trak,see above in (2)).

1. While Dan got an answer (even an oneliner) to his question,I will leave out the 'if both' statement and keep the 'one of them'.

I still believe that is a regression to keep them both.

2. And excuse me but you seem to condradict with yourself.

See #1993;In your statement in 08/05/06 20:41:29: you say. "Also, maybe it makes sense to drop both A2PS and Enscript packages as "dead upstream" after BLFS-6.2."

And by the way and excuse my ignorance. What exactly means the "syntax highlighting when printing source code".

That means (of top of my head thinking right now),a2ps or enscript has the abilitty to preserve the syntax (highlighting) of a source code when converts it from text to postrcript, and eventually in the printing paper with let's say some italic or bold font,so it looks the same (kinda) as in the original text? The question has nothing to do with the actual ticket,so feel free to ignore it.It make sence just to satisfy the substance of the LFS project (education).

[alexander@…]

Sorry for this contradiction and thanks for reopening. We need to investigate what exactly is lost if a2ps and enscript are removed from the book and the reader doesn't install packages beyond BLFS, e.g.:

"Mousepad from XFCE-4.4 beta will not be able to print, bug already filed, see ​http://bugzilla.xfce.org/show_bug.cgi?id=783"

KDE lists Enscript as an optional dependency, but I don't know how to trigger its use.

As for the syntax highlighting, try this:

LC_ALL=C a2ps -o test.ps --columns=1 -R -M A4 -E -g --ppd=level2 some-file.c

LC_ALL=C is needed to get the date correct.

[Ag. Hatzimanikas]

Thanks for the example Alexander and it works as you said. It seems this feature it can very usefull,especially to some book writers,so it's enough reason to keep a2ps in the Book (does it understands other than *.c -I can't find a reference in the manual). To be honest,I always used a2ps (especially with the fonts from Stathis Rouvas),before I jump to the UTF-8 ship (that made a2ps unusable for me).

So if I had to choose that will be a2ps.

Unfortunatelly I don't install the kde monster,so I can not test the enscript dependancy.

Is there any good kde user soul out there who can confirm that?

[Randy McMurchy]

Enscript is referenced by ImageMagick as a dependency.

Not sure exactly what it does, but it does look for the enscript binary during configure. Typically, this means that ImageMagick will use it to do some bizarre conversion.

Not sure if paps provides an equivalent binary. If it does not, then I suppose we need to leave enscript in the book as it still builds properly, and works as expected (see aalib discussions).

It would be nice if someone could provide input about he a2ps package so we can close this bug.

[bdubbs@…]

I use a2ps all the time. It sometimes is useful to print out code to annotate it and look at the flow. The highlighting is very useful. The fact that it is not maintained is not really relevant. We have had ed in LFS from the beginning and there has not been an update that we can use in 14 years. (I admit that there have been calls to remove it.)

Not being maintained is, IMO, insufficient by itself to remove a package. If it builds without an inordinate amount of effort and works, there is really no problem with keeping it in the book.

[Randy McMurchy]

With the recent input, we'll simply close the bug.

Something along these lines can always be opened later, if necessary.