groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] Compression support for files?


From: Steffen Nurpmeso
Subject: Re: [Groff] Compression support for files?
Date: Thu, 17 Jul 2014 14:46:10 +0200
User-agent: s-nail v14.7.4-3-g32d76ea

Hello Werner,

Werner LEMBERG <address@hidden> wrote:
 |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.

ok i'm thinking about this some more, like looking a bit more onto
RESOURCE_FONT related code and dealing with the fseek(3)s on PS
files in troff/input.cpp, followed by a public domain commit.
I wonder how much work it would be to completely turn over the
searchpath related standard I/O to a class method based one --
then it would be easily possible to link against compression
libraries via pretty simple searchpath.cc private classes.
I think adding some flags to the searchpath functions would also
make sense, in order to selectively enable this extension and make
it available for only troff/input.cpp:source() as a starter.

(P.S.: i have a kerTeX package laying around, shall i ever have
the time to fix our cut-in-half old TeX thing.)

--steffen



reply via email to

[Prev in Thread] Current Thread [Next in Thread]