Re: Mysterious gzipped images

[Lars Magne Ingebrigtsen <larsi@gnus.org>]

Eli Zaretskii <eliz@gnu.org> writes:

> But having both "zlib" and "gzipped" in the name is redundant, I
> think.  How about zlib-decompress-region?

zlib supports both decompressing gzip-format data and the older format
which is just called "zlib".  It's a bit confusing.

So if we choose to offer decompressing the older format in the future,
then it would be called `zlib-decompress-zlibbed-region'.  Or
something.  >"?

And as Stefan said, there's possibly a "headerless gzip" format used for
streaming and pdfs, which would (possibly) need a different calling
sequence.

I'm not sure how much code would be shared between these functions, but
if the main loop is identical, then it would make sense to rename this
function to `zlib-decompress-region' and have the format be a third
parameter (`gzip', `zlib', `gzip-without-a-header')...

Hm...

----
windowBits can also be greater than 15 for optional gzip decoding. Add
32 to windowBits to enable zlib and gzip decoding with automatic header
detection, or add 16 to decode only the gzip format (the zlib format
will return a Z_DATA_ERROR). If a gzip stream is being decoded,
strm->adler is a crc32 instead of an adler32.
----

Oh, we can actually get automatic detection of the zlib and gzip format
by using a different magical constant.  If we did that, then it would
totally make sense to rename the function.

-- 
(domestic pets only, the antidote for overdose, milk.)
  No Gnus T-Shirt for sale: http://ingebrigtsen.no/no.php
  and http://lars.ingebrigtsen.no/2013/08/twenty-years-of-september.html