What Is HTML?

What is the best text/html email formatting/beautifier tool in the west?

• Different mail clients have different conventions for formatting sent and replied-to mail, even for mail that only consists of written content (text) and replies (i.e., no images).  Apple's Mail.app and iOS Mail, Microsoft Outlook, Google Mail, Thunderbird, and so on will all produce somewhat different results in the encoding of the mail.  And other less popular clients will also have their conventions and bugs. I'm wondering what the best tool is out there that can take the raw input (whether it's the text portion or the HTML portion) of an email intended to be replied to, and reformat it so that it looks beautiful, especially on a mail client where the mail and replies are being composed in text mode.  There are many strange artifacts that come up when trying to mix these mail clients together.  Everyone has their own preferences and priorities about this and so I'm open to hearing feedback even if it the proposed solution doesn't match the priorities I've suggested or in some other way is out of the box (or maybe there are some other preferences people have on this).  This could be a filter or transformer that takes the original email and produces a text draft as a reply (bumping up the quote level by one) or it could be a filter on the outbound email that's already been drafted to beautify it.  (It could also rewrite the HTML portion too). I prefer the following (higher priority first): Format=flowed philosophy so that there's a difference between a mail client's end of line (typically 72 or 80) and the truly intended end of line or sentence.  This I believe is essential for the mail to show properly in an arbitrarily scaled view on the recipient's client.  And it's preferred to be able to compose an email with those temporary word wraps. Message still appears or looks threaded (as part of a conversation) in Google Mail.  Thus, also quote a reply as inline (nested >'s) instead of as an attachment. But if the engines that recognise a thread require that the format be basically the same in the quoted reply that may present a limitation and then simply having the appropriate references in the mail headers will help identify a thread to a good mail server/client.  But then at least I'd hope that subsequent replies after going through this filter could let a Google rendering of the thread keep redisplay of earlier information at a minimum. Same as above but for Mail.app and iOS (Mac) products. Unicode (or other popular encoding systems found in mail messages) characters are honoured and are quoted and included properly in the reply, potentially transferred to the most elegant format. Either an HTML or text MIME-part basis for the reformatting engine (for example the tool may only look at the text data to infer its answers or it may look at the HTML part to get more in-depth information).  And then it may output to flowed text or it may output to a (completely) reformatted HTML.  It seems that bringing HTML into the picture would be much harder.  But it could be included as an attachment even if the new email draft reply is in text. Ability to make sense out of a reply someone has written where they have inserted their response in the middle of someone else's reply (and distinguishing that from poorly wrapped text). Cleverly makes sense out of the headers and even store state around references to more accurately thread or even de-duplicate some information. Elegantly handle inline images, attachments, and so on. Potentially even have options to block or filter images that are external (as they can be used to track the user), or to fetch those external images and include them inline (as an alternative). Deeply nested power like traverse former attachments to consider that they may be the original forms of the earlier parts of the conversations, taking a deductive best-guess approach to most accurately reasoning about earlier messages and using that information to most sensibly construct an elegant representation of that. Other off-the-wall ideas like rendering to a LaTeX-produced inline PDF as a supplement or including some kind of scripting or advanced HTML support. Would perl's Text::Autoformat be of help here?  What about an existing engine like the mail formatting code that the open-source Thunderbird client uses?  Is there a proprietary solution out there?  Would Google ever provide information on how they implement their reformatting for inline display within Google Mail?  Is there some way to leverage backend infrastructure?  Can some isolated tools be stitched together or enhanced to provide a good solution? It seems that mail clients have gone to great efforts to make the emails still look readable and intelligible even though the mail comes from another client and there are hacks and workarounds.  It doesn't seem very easy to do but I'm wondering what's already out there.

• Answer:

  I don't think it exists. Moreover, I don't think it will ever exist as a commercial product due to insufficient demand. I don't know of a market who would pay over its lifetime at least $5 million to use this tool if I made it. What you can try is using tools like http://www.mailchimp.com and their templates system. As MailChimp has an API that accepts content, theoretically you should be able to do this. Newsletter email service providers (ESPs) and CRM systems have a vested interest in ensuring your HTML email is readable with every email client. I can't think of anyone else who does. Thinking through your list. 72-char line - Easy. I prefer to let my mail client reformat the mail and render it as it sees fit. Replied messages are never attachments, re-sending an attachment is a waste of space on my email server. I would implement this as a Gmail plugin, so none of the rest would matter. Not familiar with mail.app. Unicode is a non-issue if the programming language and API support Unicode. This is starting to sound like a system to generate responses by support staff who are responding to messages from customers that contain HTML content (IncrediMail comes to mind), which interferes with your own templates. Use a CRM or ticket system for that. It is not necessary to preserve the HTML stationary of the incoming message. Simply strip HTML. You are asking for a diff view for inline replies. Umm... That is possible but would be a challenge to implement. Gmail does it well enough for me. It would be outside the scope of a beautifier. This does not make sense. Gmail does it well enough for me. It would be outside the scope of a beautifier. This is a hard challenge. No. Wouldn't even want to think about that. Gmail does it well enough for me. It would be outside the scope of a beautifier. This does not make sense. The word "elegant" has no meaning in the context of a product specification. The real challenge with HTML email is this: http://www.campaignmonitor.com/css/ My approach would be much simpler. Strip HTML Include the original conversation's text as quoted content This is a core feature of many helpdesk ticketing and CRM systems. I can't think of a reason to have a need to preserve the HTML formatting of an incoming message when I reply to it. Gmail does it automatically, which is nice, but it's also not important to me. I answered your question because I was building something along these lines but for a different market and not involving email. I am not going to go into detail what exactly that is, because nothing like it exists today and I will continue to build it, but let's just say the challenge is even greater than parsing HTML email. My solution was to separate text and images from HTML and wrap then them into appropriate content.