Re: Why does doc packages need to contain gzipped files?
#include <hallo.h>
* Martin Wuertele [Sun, Jun 25 2006, 12:30:31PM]:
> * Eduard Bloch <edi@gmx.de> [2006-06-25 12:06]:
>
> > #include <hallo.h>
> > * Martin Wuertele [Sun, Jun 25 2006, 11:05:54AM]:
> >
> > > > then it is incorrect?" "If Debian does not use RedHat Kickstart then it
> > > > is broken?"
> > >
> > > Do you have some arguements beside the rant? firefox definitely should
> > > handle .txt.gz and other gzipped plaintext documentation. I'm not
> >
> > Should: maybe, depends on users and webmasters preferences.
> > Must: not.
> > And what has this to do with local use (TOPIC)?
>
> The complain was that e.g. firefox does not handle gzipped documents
As said... stay on topic or change the subject. This discussion is not
just about using a lone program (Firefox) which is usualy used in
client/server scenarios but about any program.
> would solve the PDF problem. My second point is that firefox and co
> should at least handle gzip compressed plaintext and one-file-html
> documents and in my experience (at least firefox from backports) does so
> without flaws.
Having a feature is one thing, deciding where to apply it is another
one. It should orient on user wish or webmasters wish and not just
follow the stupid "if that is type foo with .gz extension then I want to
gunzip it and reconsider the type then" scheme. Of course this behaviour
is most often the desired one but it should only happen when explicitely
requested by the webmaster. And there are AFAIK means to declare such
flags in HTTP answers. And the user should have the choice of
interpretation kind when opening a such .gz compressed file, which is
usualy not offered by Firefox on offline documents.
The whole thing about compressed files is just too inconsistent to make
any statements covering all use of compression or all programs. Instead,
the applications should offer a preprocessing option along with the file
type view options where the user can decide what to do with the data...
interpret it as gzipped stream of uncompress and pass to the final
viewer.
But all that is out of scope here. The question is: should we compress
files in the doc package or not? I don't like it unless the majority of
available viewers does support transparent decompression (by
transparent I mean something not bothering the user with the problems
mentioned above in the daily use cases) especially when the
documentaiton is being read often enough to become PITA because of
decompression requirement.
> > > On my portable I have ~4.6K gzipped files in /usr/share/doc and only 39
> > > of them are pdfs, 4 are html files.
> >
> > TOPIC? That is not about all the obligatory docs (which shall be
> > compressed since rarely used) but contents of -doc packages.
>
> Still I personally prefere -doc packages that consist of plaintext
> documentation to remain compressed.
Why? Manpages - ok, info files - ok, .ps files... maybe ok, gv does
manage that. But PDF? TXT? (and don't say lessopen, $user has to figure
out how to install it first), XML? ...
And again, before you answer with the wrong stuff in mind: I talk about
DOCUMENTATION packages.
Eduard.
Reply to: