[reportlab-users] [PATCH] Optional use of A85 encoding

Yoann Roman yroman-reportlab at altalang.com
Thu Apr 1 16:01:21 EDT 2010

This is a follow-up to the following thread:

Please find attached a patch that optionally disables the use of A85
encoding. By default, the option is set so that RL behaves exactly as
it does now. However, when the use of A85 encoding is disabled by
setting rl_config.useA85 to 0, streams aren't passed through that
encoding throughout the code. This resolves the issue I was having with
PDFs not being "binary enough" to trigger Outlook's base64 encoding,
resulting in mangled PDFs by misbehaving MTAs.

I ran the full tests prior to the patch and compared the results with
those after the patch was applied with A85 encoding still enabled. I
didn't see any differences, but I can't claim I did an exhaustive
comparison since a lot of the tests include instance IDs or random text

I also ran the full tests with A85 encoding disabled, and they all
passed. I then checked that all 3 documentation PDFs opened correctly
in Acrobat 9, looked "identical" to the pre-patch versions, and didn't
contain any A85 filter references.

One area I'm not certain about is image caching. I never got it to kick
off, even with rl_config.defaultImageCaching set to 1. Looking at the
code, I see that gets copied to Canvas's imageCaching attribute, but
that attribute never gets used. Is the caching code still used? Is it
covered by the tests? To be save, when A85 encoding is disabled, I
opt'ed to output cached files unencoded and with a .bin extension.

Any chance this could be included in trunk relatively quickly?


Yoann Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: optional-A85.diff
Type: application/octet-stream
Size: 10870 bytes
Desc: not available
Url : <http://two.pairlist.net/pipermail/reportlab-users/attachments/20100401/e2d20512/attachment.obj>

More information about the reportlab-users mailing list