Re: PDF's as base64 vs. Q/P encoded attachments

[Toby Speight <Toby.Speight@streapadair.freeserve.co.uk>]

Graham> Graham Todd <URL:mailto:gtodd@yorku.ca>

0> In <URL:news:x67lo12n1p.fsf@ninga.ellerbeck.org>, Graham wrote:

Graham> So Gnus now tries to encode PDF's I create as Q/P (I'm pretty sure
Graham> it didn't do this before).  The problem is that receiving PDF's as
Graham> Q/P seems to break the MIME handling of the Windows version of
Graham> Netscape Mail somehow so that Windows users that I correspond with
Graham> couldn't read the attached PDF files in Acrobat. Acrobat gave an
Graham> error message saying the files were broken. As an aside I can
Graham> detach and read PDF's sent as Q/P content to myself using the Unix
Graham> (linux & freebsd) versions of Acrobat and Netscape just fine.

I wonder if PDF is sensitive to newline-mangling?  AIUI, PDF is based
on Postscript, which should be okay, but it's possible that some
application/* types need newlines preserving as "=0A=\n".  A pain!

Could you check this hypothesis?  Compose a mail on a Unix platform,
with two attachments - one q-p encoded normally, and one with newlines
explicitly kept, as above (use query-replace or something, after
MIME-encoding).  Then try reading both on a Windows platform.


Graham> I did something like this to fix it:
Graham>   (push '("application/pdf" base64)
Graham>         mm-content-transfer-encoding-alist)
Graham> so that PDF's are always encoded base64.

Seems a sensible workaround, but if there's a true bug, it would be
nice to nail it.

BTW - Lars, did you remember to include '=' with the non-ASCII
characters for the purposes of estimating q-p size?