Since a lot of my workflow is Emacs-based, I'm trying to migrate to using Gnus at the office. Most people here use Outlook and with it rely on the Microsoft-style top-quoting in replies.
I've set things up quite nicely with markdown automatically converted to HTML when I post etc. The problem is that I end with the text version of the quoted messages in the reply thread instead of the original HTML email. This is not really appreciated by the other participants in the thread.
My question is: Is there a way in which I can preserve the original HTML in the reply-chain when replying using top-posting style?
I've been looking at various ways of doing it myself, but there is actually a lot of work doing it right, as it involves parsing the original HTML and inserting my message in the right place, etc. So I was hoping that someone else might have done this already.
After a long time, this question has remained unanswered so I concluded that no one has had the need to do this.
So, I resorted to solve it myself. My solution involves taking the message that is written, passing it through muse in order to format it as HTML, then passing this generated HTML together with the original HTML source of the original mail and send it to an external application that I wrote that parses the HTML and merges them into a new HTML document. This HTML is them returned and is then inserted into the email buffer before being submitted.
There was quite a lot of hackery needed in order to make sure that attachments are handled correctly, but in the end it all worked out well.
The code is available at: https://github.com/lokedhs/gnus-outlook-style
Related
The automated outlook emails using pywin32 and plain HTML were great till people started using it for forwarding and reply, Once you forward all the HTML formats are getting stripped and the borders of the table suddenly disappears. The way around is to go to your outlook settings and disable the option "Reduce message size by removing format information not necessary for the message".
The question is how to format the email so that it wont be lost when forwarded and make the format information necessary for the message ?
I have found out a work around though, It is observed that outlook is stripping of those styles which are defined in style block, If the styles are defined embedded in tags its escaping the stripping. As of now I have taken this approach
I am developing a web app that sends out emails. Currently, all emails have a HTML part.
Questions:
Is it important to include a text part also?
Do you include both?
Is just removing all the tags from the HTML message and adding a few line breaks good enough to create a text part from the HTML part?
Thanks, Kevin
Is it Important to include a text part also? It's a best practice to provide a plain text version of the email. However, in my opinion and in this day and age, I would guess that it is not such a big deal to leave it out. However, if you know more about your recipients' email clients (eg: if you're sending the emails in a corporate environment and everyone uses a particular email client), then you can determine how necessary it really is.
Do you include both? The .net framework (which I use) provides an AlternateView class (MSDN) that allows you to easily specify copies of an email in different formats. It makes things very easy to include a plain text version of the email. Perhaps you can find something similar in apache/php.
Is just removing all the tags from the HTML message and adding a few line breaks good enough to create a text part from the HTML part? Technically, yes but be VERY CAREFUL here. A complex HTML layout that has been converted to plain text will look absolutely terrible if all you do is remove HTML tags and pile the content together. It really depends on your content and how much you can do to manipulate said content. Also, take a look at Campaign Monitor'ssuggestions for formatting plain text emails.
One final word of advice for you HTML emails to test, test, and then test some more. When you're finished testing, test again. HTML emails will render differently in different email clients and, if some of your recipients are using Microsoft Word 2007/2010 then you can forget about web standards. I urge you to take a look at Campaign Monitor's Guide to CSS support in email.
I think this might be a simple question but I cannot seem to figure it out.
I have a workflow which simply sends a mail. In the content of the mail I
have a hyperlink going back to our SAP CRM system. I pass some parameters to this hyperlink.
The workflow works fine and the email is sent, however, the hyperlink goes onto the second line of the mail and becomes in active. If I copy the entire hyperlink and paste it in a browser it works.
The issue is I don't want users to copy and paste, I simply want them to click on the hyperlink.
Here is a screen print of what I am talking about
http://img402.imageshack.us/img402/9471/38348167.png
And here is a screen print of the actual email that is sent:
http://img210.imageshack.us/img210/6424/14370746.png
I tried going into transaction PFTC (Task Maintain) I entered my task and opened it up. I went to the tab description
and hit the edit button and I changed the tag column to continuous text but that didnt work, and then I tried extended line
and that too didn't make a difference.
Here is a screen shot of that:
http://img341.imageshack.us/img341/6254/37776438.png
My question is, is there any way to get the hyperlink on one line or even to have it be clickable on 2 lines?
Thanks so much.
From what I can see, that's a limitation of SAPconnect when sending plain-text emails. You could reconfigure the system to send HTML mails, but this would affect EVERY outgoing mail and should be handled extremely cautious. I'd suggest you write a small class to assemble and send the HTML mail and call it from the step. I'd use the BCS for sending the mail - it has an excellent online documentation and comes with several demo programs (BCS_EXAMPLE_*). You could assemble the HTML body using ABAP, although this usually yields rather messy code. Cleaner ways of ding this would be to either put all of the input data into a structure and use a simple transformation or dynamic documents (see for example report DD_ADD_LINK).
I have a great concern in deploying the TinyMCE editor on a website. Looking at the code parsed by the editor it does a great job, and I leave the HTML button off the toolbar configuration so users can not inject their own source.
However, from what I read in the TinyMCE docs, it claims to degrade nicely to a regular textarea should javascript be disabled on a users browser... and therein lies my concern. If it does revert to a normal textarea, then the user is then able to easily inject their own HTML, and this leaves me with a security concern.
I just pass through data created with TinyMCE, and it is used within another page created by my script, so it poses no security risk to my server. The security concern arises over what malicious data may be passed to another user viewing the generated page.
I know many of you will tell me to just use regexes, or parse this data, but that itself could be a nightmare, as I would be trying to either...
a.) Use regexes to try and clean up the HTML without breaking the generated page,
and it is better to parse the data for that anyway.
b.) Reparsing data that has already been parsed by the RTF editor, which also
would probably end up breaking the generated page.
Anyone with any previous experience with this type of scenario, I would really appreciate a 'heads-up' as to any other risks that using an RTF editor for user data could entail.
I would really like to provide this as a user option, but not if the risks outweigh giving the user using the RTF a chance to take a wack at another user viewing the page that is generated by the script.
My gut feeling is to steer a wide berth around use of the RTF at this point.
Thanks for any direction you can give me with your own experiences.
You cannot have client-side security on the web. You simply can't trust the browser, because it's easy for a malicious user to substitute a replacement browser that does whatever he wants.
If you accept HTML from users (using TinyMCE or through any other method) and display it to other users, you must sanitize or validate the HTML in some way on the server. If you're using Perl, the leading package seems to be HTML::Scrubber (along with various other modules that help you plug it in to various frameworks). I haven't had occasion to try it myself.
The TinyMCE Security page mentions some ways to make it harder for people to submit arbitrary HTML, but you still need server-side checks.
Regex is generally not considered good for parsing HTML
RegEx match open tags except XHTML self-contained tags but I have noted the "perl" tag :)
My advice when taking markup from users is to always parse it through something that can accept mal-formed HTML and return well formed HTML. These parses generally produce something that can be queried and updated with some form of XPath.
In Python there is a module called BeautifulSoup, Ruby has Nokogiri and in ASP.NET there is a project called HtmlAgilityPack that all do this sort of thing. I'm not sure what library perl has, but I'm sure there would be something.
I am using the SIMPLE RSS reading example found at http://theappleblog.com/2008/08/04/tutorial-build-a-simple-rss-reader-for-iphone/
It uses parseXML to load the RSS feeds.
Here is the problem I am having. For the following RSS feed example, I am having trouble getting it to load the feed. Comes up with an error that it cannot connect. However on my Mac RSS Reader it works fine, so I know the link is good.
Any ideas on why it cannot load this particular feed but it can load others fine?
http://www.okstate.com/rss.dbml?db_oem_id=200&media=news
Thanks.
I've just released an open source RSS/Atom Parser for iPhone and hopefully it might be of some use.
I'd love to hear your thoughts on it too!
In my experience, HTML markup causes an RSS parser to fail in most cases. I've experienced a problem like this with a lot of parser classes I've come across (in search of the ultimate one, which I didn't find)
My guess is that entities such as
's
are responsible for your crash. That was usually the case with my crashes. This also lead to my decision to create a 'proxy server' to pre-parse the XML before sending it to the iPhone (which gives me the advantage of caching, scaling, and some other stuff). I do believe there are solid solutions out there, but is always difficult writing a parser for so many RSS implementations.
P.S: W3C validates this feed as 'valid', so it really is 'our' problem..
Your problem could lie with:
Unicode characters (i.e. I see some o's with two dots above them in the feed)
The code you have doesn't respect CDATA sections correctly
To find out which is the case, save the feed file to your local disk and load it via your code to make sure the error happens.
Do a binary search on the file to find out if a particular RSS entry is causing the problem (i.e. remove all but the first rss entry and see if the problem exists. If it does, then the problem is there, if it doesn't put half the rss entries back in the file and repeat)
I've been experiencing a similar issue. I haven't yet pinned down the answer, but I've noticed that RSS 2 tends to parse more successfully than the rest.
There are many RSS feeds that contain invalid XML, usually because they were hacked together on the server side using HTML templates by somebody who didn't understand XML. I've seen improperly escaped (or non-escaped) HTML post contents, missing close tags, badly nested tags, and so on.
If you want to be able to parse arbitrary feeds, you have to clean up bad XML. The usual way is to use the "htmlTidy" library, which is included in the OS. This can clean up XML as well as HTML.
This example you're following uses NSXMLParser -- I have no idea why. It's a lower-level API and it doesn't support tidying. I would suggest using NSXMLDocument instead. There's a flag in that API that will tell it to use tidy when parsing the XML. This API also returns you the XML as a handy tree of elements that's easy to work with.