Re: [Groff] Compression support for files?

[Steffen Nurpmeso]

Good morning,

(Ted Harding) <address@hidden> wrote:
 [.]
 |As far as Unix/Linux are concerned, their beauty, simplicitly
 |and reliability, and above all their flexibility, depend on
 |the fact that different aspects of a program's functionality
 |for a specific purpose are delegated to components of the
 |program's software suite: In the words of the Founding Fathers,
 |each compenent does one thing, and does it well!

It must be said though that today it seems the complexity is
enormous as is the program bloat.

 |But that is with reference to the specific purpose of the program,
 |which in the case of troff is the production of well-laid-out
 |pages -- a task which has many aspects.

Oh more than is understood.

 |But decompressing files stored in compressed format on disk is
 |not one of these aspects. If it is desirable, then let it be

So this is exactly what the patch is all about, snuggling in
a specialist in between the undigested input data and the further
refinement done by the typesetting system we use.

 |done by the operating system, independently of the program
 |(i.e. independently of troff). This must be possible, for a
 |suitable configuration of the operating system, if it is
 |desired and if suitable utility programs/routines are available
 |for the operating system.
 |
 |When a program needs a file, and transmits a call for it to
 |the operating system, and the operating system in turn finds
 |that it is a compressed file, then let the operating system
 |decompress it and pass it back undompressed to the program.

Plan9 is great design.  I really didn't know anything about it
before Christos Zoulas of NetBSD pointed me to it because of my
Unicode ambitions.  Of course there is a performance bottleneck
with all this data copying and the context switches.  I'm the one
who was happy once FreeBSD had zero-copy pipes.

 |Such tasks have nothing whatever to do with troff, and at many
 |points in the discussion is has appeared that making them part
 |of troff would introduce complications and potential diasters.

For now most of the patch simplifies the code.  This is desirable.
The fourth and last patch which adds the decompressor pipe hook
support, so if you want to, maybe; file extensions are a part of
computer reality however, so i think automatic path adjustments
are in this particular case ok, too, since we look into specific
and configured search paths, and when i specify `.so file.1' and
then troff also looks for `file.1.gz' and `file.1.bz2' shall there
be no `file.1', then i think no terrible things should happen in
practice.

And with just one more day of work, or two, GNU troff(1) could
also, optionally and easily, link against few of those dynamic
libraries which have taken over the role of specialists in todays
world, and use those instead of the external programs which
provide the command line interface of exactly those libraries.
I think it would be a fair deal to offer this functionality
optionally for those who use a restricted troff merely for manual
pages, for example.

--steffen