[reportlab-users] RE: Emailing Corrupting reportlab PDFs
Fri, 28 May 2004 09:10:21 +0200 (MEST)
I have a feeling of deja vu with regard to this thread -- about 12 months b=
ack? But I've never experienced this problem and can't find the references.
I think the solution suggested then was to put "something" in the file that=
would force Outlook and other encoders that look at content rather than fi=
le extension to see the file as binary. =
I would guess a comment line with something obviously non-ascii at the star=
t of the file wouldn't harm anything, would eliminate the problem for those=
who are experiencing it and could (should?) be hardcoded into ReportLab (s=
+++++++++++++++ Original message :
From: "Michael Porter" <email@example.com>
Date: Thu, 27 May 2004 13:16:53 +0100
Subject: [reportlab-users] RE: Emailing Corrupting reportlab PDFs follow up
I've done some investigation into this and it seems that Outlook is really
to blame here...
When you send a PDF attachment from Outlook with the default settings it
encodes the PDF as quoted-printable but doesn't explicitly encode the CRLF
(with a =3D0D=3D0A sequence). The receiving client will then presumably ass=
that the line ending characters are unimportant and use those native to the
platform (which will result in a corrupt PDF on Unix or Macs).
So the problem is that Outlook is regarding the PDF as text rather than
binary. Outlook appears to ignore the mime-type/file extension when deciding
on what encoding to use but instead tries to guess from the file content.
Presumably the "random" element comes in because some PDFs look more
"binary" than others.
A workaround is to zip up the PDF or set Options|Mail
Format|Settings|Message Format to UUEncode.
The the real solution would be tell Outlook to always regard .PDF files as
binary (and hence use base64 encoding). Unfortunately I don't know how to do
this or even if it's possible. If anyone does, please let me know.