Hello Steffen!
> It effectively adds compression support for (practically) *all*
> files that groff uses during a run.
Similar to others on the list I'm not really enthused about this
feature. Your idea of wrapping all possible file access methods into
a single class (`file_case') seems like a good idea, but compression
per se is a minor issue IMHO and not really important, given that
groff input files are small normally, and man pages and the like can
be handled the Unix way, this is, by external compression and
decompression programs.
*However*, if you really like to play around file issues: A sorely
needed feature is integration of the kpathsea library into groff!
Regarding file access and directory structure, TeX and groff are
almost the same, so it would be a *great* idea to use what already
exists. IMHO, it would be silly to reinvent the wheel, given that
kpathsea is very mature and should already cover all aspects of
groff's file and directory access out of the box. In particular, it
would allow to have not a single `download' file for grops but a
series of such files, and it shouldn't be too hard to implement
cumulative reading.
Given that groff has such a small footprint, I could even imagine that
groff gets distributed within TeXLive, greatly increasing its
availability on non-Unix systems...
Werner
PS: Please use tabs in C++ or C source code files! You have changed
that to spaces, unnecessarily increasing the diff file size. And
stay within 80 characters per line if possible.
