Is there a way to set the text format when sending content via the email alert node - flowgear

When sending the contents of a text file via the Email Alert it converts the text to UCS-2 Little Endian from UTF-8. Is there a way to force the text format so as to make sure the package is the same as the file generated?
I have tried generating the file in Binary and turning off HTML Body. Do I need to use a formatter maybe?

Related

PDF content is not enough to reconstruct the PDF?

I open a pdf file "test.pdf" with Vim and copy its content to another text buffer that I save as "copy.pdf". I don't understand why "copy.pdf" is different, can be opened as a pdf (the title shows) but the page is empty.
The same happens when I read the file in Javascript with FileReader.readAsBinaryString and rewrite it to disk, so it is not related to how I copy in Vim.
Even more strange, the Finder says that the copy is actually 30KB bigger.
Where are the hidden bytes?
Usually when I see this sort of behavior and resulting blank pages, it is the result of using a program or process that is treating the binary information of a PDF as text in some form or another - for example, doing CR/LF conversion, tab to space conversion or interpreting the data as UTF-8 instead of binary. Doing any sort of transformation will ruin the binary streams within a PDF and will cause the offset bytes in the cross-reference table to become incorrect, causing the PDF to be unreadable.
Perhaps your process of writing back to disk doing CR/LF conversion or otherwise treating your binary blob as non-binary?

Downloaded octet-stream then encoding as pdf; can't get line endings worked out

Tools that I'm using for this:
Chrome
Notepad++
Sublime Text 3
Fiddler
WinMerge
Adobe Acrobat Reader X
Synopsis
I have downloaded a pdf twice, once through Chrome as an experimental control; once again through a raw /GET request via Fiddler which returns me an octet-stream. To this point, I can save the octet-stream as pdf and I can get the proper page count and some of the page headers and numbers, but very little of the body content is loading. When I open my file in Adobe Reader X, I get an error that it
Cannot extract the embedded font 'LFIDTH+ArialMT'. Some characters may not display or print correctly
and I cannot work through why it can be extracted from the 'true' pdf but cannot from the one I am saving.
Details
As for my manual pull of the file, I have provided
Accept: application/pdf, application/x-pdf, application/x-gzpdf, application/x-bzpdf
The server sent me back an aplication/octet-stream with an attachment Disposition.
So to recap:
Valid Foo.pdf sitting on my hard drive
HTTP Response with an octet-stream version of same file, in UTF-8 encoding (I assume)
Here is what I know:
I pulled the Message Body of the response from the server and dropped it to file. I then ran a WinMerge comparison of it against the contents of the pdf and every line mismatched on line endings. I re-encoded the EOLs for Unix and the diff shrank to ~1k lines out of 160k. A close inspection of the mismatch indicates that the valid pdf maintains what looks like a NUL 00 character in places whereas my octet-stream contains literal spaces. Also, the "true" pdf is reporting EOL: LF 1252 Mixed through WinMerge. My "raw" pdf is reporting 1252 Unix When I homogenize the 'true' pdf to 1252 Unix, I get the same issue as I explained in the 'raw' one.
Is there anything I can do to get this mess of an octet-stream straightened out?
Note that the pdf that was downloaded through Chrome is historic. I have it on my machine, but I downloaded it "sometime in the past" and the request headers used when processing that /GET are no longer available. Attempting to download through the browser "now" results in an error, but an explicit GET request against the resource through Fiddler is returning the pdf as an octet-stream.
Well now....
In Fiddler Session,
Right click HTTP Response with the application/octet-stream body | Save | Response | Response Body
If Content-Disposition: attachment;filename has been set on the response, the File Save Dialog will be prepopulated with filename
Easy after you know it's there.

How to detect characters with unknown encoding (like Textmate)?

Textmate does not allow open a file with characters in unknown encoding. For example, when a wrong encoding is selected, the Open button is disabled:
When a proper encoding is selected, the Open button is enabled:
Is there a c or Objective-C library for reporting characters encoded outside current encoding?
create .tm_properties file in your home dir, then put this code in it:
[ attr.file.unknown-encoding ]
encoding=gbk
this will set default encoding to gbk when Textmate 2 don't know file encoding.
also you can put this .tm_properties file in project root to use this setting within project only.
The usual approach is to load the text assuming a certain default encoding (like UTF-8/16 or latin 1). If there's a BOM at the start of the text then this is very good indication that the text is some form of Unicode. The BOM also helps to find what transformation format is used (UTF-8 etc.).
If loading the text still fails then it's time to ask the user for a hint (charset selection), because it's difficult to guess what the used encoding is.

Want to send email with multicoloured text

I using vb.net code to send emails. There is no problem in sending plain text emails but I want to use some formating (bold, coloured text et.) I am writing my message body in a richtextbox but do not know how to do the formatting.
Also I want to insert picture. Please help regarding that too.
Thank you very much.
You basically need to make a html file with css for the elements you want to be colored. This you add to your email as an attachment with mime-type set to text/html.
For images you add these as base64 encoded attachments and use their Content-ID as CID: reference in your html code.
I wrote a little more about this in my answer to this thread:
Send email includes image like Outlook does?

How to change value of a textbox in a pdf

I have to make several certificates with the same design but different names. So I've tried to make an uncompressed pdf file with a place holder text and tried to change it with a text editor. For some reason it didn't work. I could only see a single letter of the replaced text.
When I try the same thing with an eps file, it works but since eps doesn't keep (AFAIK) page orientation, there is a chance that it something will be different with different names.
Does anyone know why this didn't work or how to change a text box in a pdf file (with sed)?
(I created the master pdf with Illustrator CS4)
Thank you
In general, editing PDFs in a text editor is a Bad Idea. PDFs depend on the byte offsets of various objects to not move.
If you KNOW your editor won't change the EOL bytes (or what it thinks are eol bytes), and you DO NOT change the length of the text entry's object as a whole, you're okay.
For example:
1 0 obj
<</Type/Annotation/Subtype/Widget/V(PlaceHolder Value)/T(Field Title)...>>
endobj
If your new value is longer than "placeholder value", you're screwed.
Most PDFs contain quite a bit of compressed binary data. Some of that data WILL be misinterpreted as EOL characters. Changing them will:
a: break your compressed stream
b: possibly change the byte offsets of the rest of the PDF.
When I hack on PDF files, I always use a hex editor.
Bottom Line: Don't mess with PDFs as a text stream. Mess with them as PDF files, using a PDF library. There's sure to be one capable of altering form field values in your language of choice.
You can also look into FDF and XFDF to see if they'll suit you better. Both file formats store field/value pairs and a reference to the form to use with those pairs. FDF uses PDF's syntax, while XFDF is an XML grammar. You can serve the [X]FDF to your end user and they will see the filled-in form.
WARNING: Unless the form is Reader Enabled (requires Acrobat (pro?)), they won't be able to save the version of the form they get after opening the [X]FDF, only view/print it. Of course they can save the [X]FDF, but many users might balk at this Strange New Format.