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

[Yoann Roman]

This is a follow-up to the following thread:
http://two.pairlist.net/pipermail/reportlab-users/2009-May/008239.html

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 
blocks.

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?

Thanks,

-- 
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>