#include <hallo.h> * Martin Wuertele [Sun, Jun 25 2006, 12:30:31PM]: > * Eduard Bloch <[EMAIL PROTECTED]> [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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
