[Evolution] Bug#406208: PDF files sent as 7bit are corrupted by
yavor at doganov.org
Tue Jan 9 15:05:06 UTC 2007
This is in no way a bug in Camel -- its behaviour is absolutely
standard and normal. Some PDF files (and possibly other types as
well) are being sent as 7bit, if the result from the stream filter
returns that as a "best" encoding. For example, all documents
generated by XSane (regardless of whether the option "Save PDF zlib
compressed" is enabled or not), and nearly all documents generated by
However, when the e-mail gets processed by Microsoft Exhange or Lotus
Domino, and the recipient opens the attachment, it is a blank page.
Maybe \n gets replaced with \r\n or perhaps it is doing something
similarly evil; I don't know.
I'm pretty much sure that the problem is with exactly these servers,
as the it occurs only to our customers who have Exchange or Domino.
(We use Evolution + Exim4 and all other recipients receive the
attachments w/o problem). So far I've been overcoming the issue by
sending PDF files to such recepients with Mutt (which sends them as
"quoted-printable"), but my colleagues can't use it so I had to think
of another solution.
The attached (possibly crippled) patch solves the problem and I've
been testing it for more than 2 weeks without any ill effects. I'll
perfectly understand if it is rejected by the maintainers or upstream;
just thought that it's good to report this issue.
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-686
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 725 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-evolution-maintainers/attachments/20070109/aec8d711/camel_pdf_encoding.obj
More information about the Pkg-evolution-maintainers