Version: 1.7.2 (using KDE KDE 3.3.2) Installed from: SuSE RPMs OS: Linux After generating a PDF with OOs export function and sending it via kmail, I am not able to open the Attachment with acroread. if I compare the original and the sent version, kmail seems to convert <cr><nl> to <nl>: Original: thomas@thomas:~> od -ba upload.pdf | more 0000000 045 120 104 106 055 061 056 064 015 012 045 344 366 334 337 015 % P D F - 1 . 4 cr nl % d v \ _ cr 0000020 012 061 040 060 040 157 142 152 015 012 074 074 040 057 114 145 nl 1 sp 0 sp o b j cr nl < < sp / L e ... Sent Version: thomas@thomas:~> od -ba uploada.pdf | more 0000000 045 120 104 106 055 061 056 064 012 045 344 366 334 337 012 061 % P D F - 1 . 4 nl % d v \ _ nl 1 0000020 040 060 040 157 142 152 012 074 074 040 057 114 145 156 147 164 sp 0 sp o b j nl < < sp / L e n g t ... It does not matter whether I use quoted printable or base64 as encoding. I would like to know for what reason ever the file is not transferred as it is? Thomas
this seems not to happen for all PDFs, but when kmail chooses "quoted printable" automatically (instead of base64)
> It does not matter whether I use quoted printable or base64 as encoding. > I would like to know for what reason ever the file is not transferred as > it is? Can you give some more information? In the message should be something like this: Content-Type: application/pdf; name="wls-performance-hp-ux.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="wls-performance-hp-ux.pdf" Please open the message in the source view (simply hit "V" when the message is selected) and post the appropriate lines (and please avoid pasting lines starting with a double dash and Boundary, which can mangle the message). TIA
************************************************* with Base64: ************************************************* Content-Type: application/pdf; name="upload.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="upload.pdf" JVBERi0xLjQKJeT23N8KMSAwIG9iago8PCAvTGVuZ3RoIDIgMCBSCj4+CnN0cmVhbQowIHcKcSAw IDAuMSA1OTUuMyA4NDEuOSByZSBXKiBuCnEgMCAwIDAgcmcKQlQKNTYuNyA3NzYuOSBUZCAvRjEg ************************************************* ************************************************* with Quoted Printable: ************************************************* Content-Type: application/pdf; name="upload.pdf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="upload.pdf" %PDF-1.4 %=E4=F6=DC=DF ************************************************* regards Thomas
Sometimes, PDF files are detected as "text", even though the MIME type is application/*. I've seen Subversion do that too. KMail should never quoted-printable attach anything that is not text/*
*** Bug 100634 has been marked as a duplicate of this bug. ***
Gee .. <cr><ln> --> <ln> Does automatic windows --> unix text conversion happen when a file is copied from a FAT32 to a unix file system partition? Should it? Option? Of course, a simple file copy is not doing this, Kmail is. My vote would be not to touch the file. A VIEWING program must play with this stuff. But, of course, a PDF file is not a straight up windows text file, is it? Anyway, the obvious workaround is to copy the files to a linux file system and include them from there?
In my case it does not matter whether the file comes from a Windows Share or is locally created (here /tmp) Thomas
Yup. Just tested this. I had noticed size-reduced copies but in this case, size was the same. Still got and error from acroread. An ERROR. Correspondents have received attachments which they complain were blank. SO how might one reliably send pdf files until this is fixed?
It has nothing to do with the filesystem or CRLF -> LF conversion. It's the simple fact that a non text/* file was attached as quoted-printable. That's wrong and not allowed.
> That's wrong and not allowed. But I have no chance to tell kMail: "this is no text you stupid software" ;-) See Comment #4
*** This bug has been marked as a duplicate of 95733 ***