I've designed an HTML email (with no css, using tables, etc) that essentially consists of one outer table that contains 3 inner tables. The email renders fine in Outlook 2003 but when the user forwards it, only the top table is preserved in the forward.
I've tested this in:
Outlook 2003 (11.8330.8341) SP3
Outlook 2003 (11.5608.5606)
Any idea what could be going on here? I don't really even know where to start. When I look at the HTML content of the forward, it is mangled beyond belief.
UPDATE:
There's a setting in MS Outlook 2003 under Tools > Options > Mail Format that says "Use microsoft office word 2003 to edit email messages". When the user does not have Outlook installed (and so the option is unchecked and grayed out) or when this is simply not checked, the forward appears correctly. However, checking this option brings up the composer in an instance of Word.
Word completely screws up the HTML - creating actual data loss, not just formatting problems.
UPDATE 2:
Found this question. Although the answer didn't help me, anyone on this question might want to check it out:
HTML E-mail Layouts Breaking When Forwarded - Make it Survive the Word 2003 HTML Editor
QUESTION:
What is happening here? Is there any information about certain HTML that Word will strip? I'm using only the most basic elements and styles I can find.
What is happening here?
Word stripped everything inside divs. I didn't do robust enough testing to determine whether or not this would be true of any div. I converted them to tables and everything now works.
Related
I've got a somewhat elaborate report I put together which looks great when I preview in VS or when I run it from the SSRS portal. Now I'm trying to email it on a routine basis to a dozen people (all internal resources to my company, for now). I'd really like it to display embedded in the email, vs. as an attachment - people don't open attachments, but they're 100x more likely to look at an inline graphic. Unfortunately Outlook (i.e. Word that does the underlying rendering) doesn't support all HTML tags and the report looks like garbage. Here's the report preview vs. what I get in MHTML. I've Googled far and wide, and haven't found a good workaround yet. I believe the most critical failure point is the use of background images in my tables.
I have to believe somebody has come before me and found some kind of workaround. Any advice is greatly appreciated!
Such things may happen because Outlook uses Word for rendering message bodies. You can read more about the supported and unsupported HTML elements, attributes, and cascading style sheets properties in the Word HTML and CSS Rendering Capabilities in Outlook article.
UPDATE - 2/26/2020
One of our clients just got this back from Microsoft:
Thank you for submitting this issue to the Outlook for iOS and Android team. After careful consideration, the product team is maintaining it's decision to disable HTML within Outlook Mobile deeplinks. While HTML within deeplinks was previously allowed, support for this scenario was never formally designed or introduced. Additionally, supporting HTML within deeplinks can introduce unintended consequences and potential security issues.
Though not officially supported, deeplinks that utilize plain-text will continue to work in Outlook for iOS and Android. Please note that this behavior may be modified at any time without notice.
Using the UIActivityViewController to share your HTML body also no longer works. It would appear that Microsoft has taken away our ability to generate any HTML bodies when composing an email in their system.
UPDATE - 2/6/2020
As responses show, it's gone from fixed to broken again. One of our large custom app clients that uses outlook exclusively has been pursuing a ticket with MS and this week finally got a response that multiple companies have reported on this issue and they are looking into a way to securely allow sharing of HTML bodies. In the interim for iOS apps we've been converting our code to use the UIActivityViewController and excluding almost all the activityTypes. This allows you to set the HTML body:
let items = [["Body" : emailBody]]
let acv = UIActivityViewController(activityItems: items,
applicationActivities: nil)
The two issues with this approach, is
a) If you try and set the subject or recipients, those are ignored. I've tried multiple different ways with no success. So in the case of our apps where for reporting purposes we collect the contact info before the email is sent, the user is required to again enter the contact info in the Outlook message composer.
b) It adds an extra step of requiring the user to select Outlook as the share item from the Initial UIActivityViewController. We've had to deal with reported "bugs" that are not bugs, just users not selecting Outlook.
UPDATE - 12/12/2019
The issue appears to have been fixed by Microsoft as my Outlook version remains 4.15.0 but when asked today to make screens shots for a ticket I submitted, the links are now being encoded correctly again. Please vote to close.
Original Question/Issue
I was previously using instructions based on this post. But it appears that with Outlook for iOS version 4.14.x and up (Outlook version tested as of this post 4.15.0) the encoded HTML body is being stripped of all of its encoded characters. Which is to say that something like:
<br>
Some Link
<br>
Becomes
braref=www.somelink.comSomeLink/abr
Hoping someone from the iOS Outlook team sees this post and can perhaps provide some guidance on how one might configure an HTML body to be passed through the ms-outlook://compose body parameter. Or if anyone else has figured it out. Please respond.
Thanks!
In v4.19.0 (latest version) "less than" and "greater than" signs (< >) are back but the html body is not rendered, so emails looks like this:
<html><body><p><strong>Hi</strong>, how are you</p></body></html>
We have seen this go from fixed to unfixed, etc. Some days it seems to work and other days it does not. Today it seems broken again.
I've been stuck with this problem for a little while now and I have no clue on how to solve it.
So basically, I'm working on an HTML page. In it, there's a list (UL).
It displays properly in every browser I want.
For some reason, I need to stock the HTML page in a database (Microsoft SQL Server 2008).
When I use it after, everything is displayed properly except for the fact that the dots next to the list items not being present.
It only happens AFTER being taken from SQL but the code generated is the same.
I tried on each browser and it does the same thing on all of those.
By the way, (this should be a big part of the problem) the HTML is rendered in an ASP.net page after being taken out of the database.
Does anybody have an idea of what could be the cause of this ?
Thanks alot !
If you are saving code to VARCHAR data type column you need to escape the escape characters that you might be passing in. Just like other people mentioned in comments, you need to verify that the code you are passing in, is properly stored and returned from SQL Server. Get the code from SQL Server and put into browser to verify that it is being stored correctly.
I finally figured the problem, I first thought it was due to ASP.net or the compatibility, but that wasn't the problem.
It was all due to how my page was organized. The lack of space in the 'divs' made the dots hidden in only a certain modes in IE... I changed the alignment of the text by accident and it solved everything
I have a number of reports that display dates in the UK format. I need to change these to display dates in the Japanese format. I've changed the LANGUAGE to be ja-jp and the report looks fine when I preview it in Visual Studio 2008. However, when I upload it to the server and come to view it the styling has gone and the date isn't formatting.
Is there anything obvious I'm missing or have overlooked?
I have found two solutions to this. The first involved moving the text box. I had a text box at the top of the report. When I changed its language to ja-jp then the appearance of the table beneath was affected. Moving the text box below the table prevented this from happening. It sounds a bit ridiculous but it worked.
The other involved editing the actual RDL file. Instead of specifying the language I edited the FORMAT tag within the STYLE tag
<Format>yyyy-MM-dd HH:m</Format>
I have been working on an emailing project for a client using Lotus. Since they want each associate to be able to send a nice looking email individually, we first opted for a solution where we would design an email template, send it to the people meant to use it, and have them send an email using this template, by forwarding / cleaning up the headers and filling out a personal message in a specified area of the table.
Easy enough to accomplish for Outlook users.
But with Lotus (I believe they are using a very old version, running on windows XP), every time you forward an email containing table, all borders of the table appears as thick white lines, even though border="0" has been specified. It's quite an issue since our email has a dark background. Email does look ok upon reception, when it was send from an html mailer form example.
Do you know any html code trick to work one's way around this filthy bug ?
Lotus 8.5 continues to have this problem. The original email looks nice/professional. However upon forwarding in Notes, the borders are very thick, the font is larger, and there are --you'll love this one-- thin blank lines between each original line.
Notes is a great workflow/database system, however their email client continues to be very problematic/substandard. My company is switching to Outlook for all 13,000 employees this year. This happened at a prior company I worked and as well. It's really a shame, because Notes has been truly a superior product to Outlook for medium to large size companies for for the 13 years I have worked with both (Notes has had very good capabilities for index/search, workflow, and global offices). The best combination seems to be Outlook email client and Notes backend.
1) Get the customer to upgrade to a recent version of Notes & Domino. The HTML rendering & handling in Notes significantly improved with version 8.
2) This seems to be a problem with the version 6.5 Notes client.