[reportlab-users] When it is safe to use PDFZCompress in reportlab code

Marius Gedminas reportlab-users@reportlab.com
Thu, 23 May 2002 19:18:16 +0200

On Thu, May 23, 2002 at 03:02:59PM +0100, Robin Becker wrote:
> Well I guess you could have a quick go with the compression forced on
> locall. If it works then think about how to turn it on/off.

It Works For Me$^{TM}$.

> I'm not the
> expert here. In the 1.3 spec  I see only flate/lzw and no mention of Z
> (or is that lzw?). PDFZCompress stuff appears to be using zlib and I
> thought that zlib wasn't lzw? IE gzip != compress in uniz terms.

I am now looking at PDF 1.4 specification.  It says (table 5.3 "Standard
filters" on page 42) that FlateDecode is available since PDF 1.2
("Decompresses data encoded using the zlib/deflate compression method,
reproducing the original text or binary data").

BTW documents generated by passing pageCompression=1 (which is the
default BTW) use PDFZCompress + PDFBase85Encode.

And according to utils.py, reportlab should be able to cope with zlib being
unavailable, so I can't just unconditionally use PDFZCompress.

I think I'll add setCompression method to PDFDocument, similair to the
one in PDFPage/PDFFormXObject.  Canvas.setPageCompression will set
PDFDocument's compression, and font objects will check it.

Is that OK?  (I still want my TTF support merged with ReportLab, so I'd
like to know the opinion of the maintainers.)

Marius Gedminas
Apologies for taking up the bandwidth with the apology.  Anything else I
can apologise for ...... er no can't think of anything, sorry about that.
                Andy Hunt (Member of British Olympic Apology Squad)