Re: [Groff] Compression support for files?

[Steffen Nurpmeso]

Werner LEMBERG <address@hidden> wrote:
 |May I suggest to discuss your future changes on this list in advance?
 |This helps everyone in understanding your plans, and probably saves
 |you from needless coding.

I will cleanup my local commits and make the decompressor-search
an optional flag to searchpath; it is not needless coding.

 |> The original intent of Matthew Dillon i think was to be able to
 |> blindly use the `.so' request and make it work regardless of wether
 |> whatever file is compressed or not.
 |
 |Why would you ever want this?  TeX doesn't have this either, and up to
 |now I've never seen a request for adding this.

I'm not using TeX -- why do you refer to it?
And i don't know why there never was a request; i guess many
people try out something in a situation and either it works for
them or it doesn't and then they either find some workaround or
quit right away.  How many people do you think have the will and
even more the time to dig into such a no-go?  I didn't.

 |> Moreover, some files you simply don't need that often; a Unicode
 |> font in the format that groff(1) understands can well be over 40
 |> megabytes, which can be boiled down to less than the half of that.
 |
 |Here I agree: groff font files are extremely verbose.  But compression
 |is not the right solution, I think: you should rather implement a
 |better font format.  And for the grops front-end, support for modern,
 |compact font formats like CFF or TFF should be implemented.

Yes, TTF fonts, transparently, would be so nice; i'm not the right
person for that as i would start from scratch there; however, if
i use xz(1) i still can gain 50% space saving on a TTF font that
i possibly use once a week or even less often.  And i like to have
a choice; having a choice is the essence of freedom (i say that
even though i think (a) the sapiens sapiens isn't capable of
dealing with that (b) it'll end all too soon).

--steffen