The original file has LF as its line endings, but the attached file has CR + LF. Am I missing something when creating the attachment?
The original PDF have LF and the received file have that changed to CR+LF ?
How strange… I would zip it before attached it and then sent the zip, but the question is still interesting.
You’re going to have to be more specific. What line endings? In the PDF file itself? The text contained within?
Not the text, the PDF itself.
The original is on the right.
How both were created? There lies the difference.
The data from the original (right) was used to create an attachment which was added to a message & emailed then saved from Outlook. Both are on the same computer, and the original was sent from a Web App.
I can open the attached file but see an empty document.
Have you tried zipping the file? Make a bug report and find some other way to send emails (Chilkat, MBS, php).
Dang. I was waiting for you to tell me what I was missing being the guru on email. I guess I’ll go the zip route.
Thanks @Beatrix_Willius
For completeness (and so I can throw my hat into the ring with debugging) what is the code you’re using to make the attachment, add it, and send it? Does the data come from something on disk or in memory? The more you can provide (heck a sample project wouldn’t hurt), the better I can try to recreate your results.
Also, does Microsoft / Outlook offer some kind of “View Raw Message” feature like Gmail does? CR + LF is how Windows likes its line endings and it wouldn’t shock me to discover Outlook was making that change.
Interesting.
Is the resulting PDF unreadable? PDF can be expressed as 7-bit ASCII, and changing the line endings on such a PDF would have no effect on it whatsoever. Of course PDF also comes in a binary format which wouldn’t survive this kind of alteration.
When you send emails via MBS Plugin, we automatically encode the attachments with Base64 for maximum compatibility.
We can also do 8bit encoding, but then some mail servers make trouble.
So best is to do base64 and Content-Transfer-Encoding: base64 in the attachment header.
I read this as “I have a custom code to create an attachment and compose an email message”
The “email format” (IMF) is defined by the RFC 5322. Not sure if you are trying to use AI to create your code, but one key factor of this format is that the internal EOL is defined as CRLF. A bad code for attaching a file as a PDF COULD “translate” LF to CRLF in a moment BEFORE encoding the binary content to base64 MIME attachment.
Just a guess. But makes sense.
1 Like