Ben Langhinrichs

Photograph of Ben Langhinrichs

IBM Champion logo

E-mail address - Ben Langhinrichs






August, 2014
SMTWTFS
     01 02
03 04 05 06 07 08 09
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31

Search the weblog





























Genii Weblog


Civility in critiquing the ideas of others is no vice. Rudeness in defending your own ideas is no virtue.


Tue 5 Aug 2014, 08:58 AM
If your company uses Notes/Domino for email, you have probably learned that in spite of years of customer complaints, emails sent from Notes are iffy at best. On a good day, all the information gets through. On a bad day, data is misformatted, missing or just plain messed up.
 
But it is just for such concerns that we at Genii Software tilt at the windmills of email fidelity and data integrity. Now, since the release of CoexLinks Fidelity 3.6, more and more companies are getting their windmills served up just the way they want them. (No point in tilting at something if you can't serve it for supper.) If you want a short technical explanation, see the bottom of this post. If you just want to try it for yourself, request an evaluation license.
 
In 2014, using IBM Notes 9.0.1 Social Edition, you send the following email:.

Original email in Notes 9.0.1 rich text
 
With native client rendering, it arrives in Gmail as:

Email as sent to Gmail after Notes 9.0.1 MIME rendering
 
With CoexLinks Fidelity rendering, it arrives in Gmail as:

Email as sent to Gmail after CoexLinks Fidelity MIME rendering
 
With native client rendering, it arrives in Outlook 2007/2010/2013 (no rendering changes in years!) as:

Email as sent to Outlookl after Notes 9.0.1 MIME rendering
 
With CoexLinks Fidelity rendering, it arrives in Outlook as:

Email as sent to Outlook after CoexLinks Fidelity MIME rendering
 
 
and it is not just the client rendering. What if you view the same email (still in rich text) via your Notes client or your iNotes client? Note that while the images work here, they will fail if mailed from here, unlike the images with CoexLinks Fidelity.
 
 
In IBM iNotes on Domino 9.0.1:

Email in rich text viewed through iNotes 9.0.1 with native rendering
 
In IBM iNotes on Domino 9.0.1 with CoexLinks Fidelity:

Email in rich text viewed through iNotes 9.0.1 with CoexLinks Fidelity rendering
 
 
A brief technical explanation of the specific areas which fail here:
 
1) Image resources in emails are converted to relative URLs by the client MIME rendering, which means they fail unless the email is read on the server where it was sent. The same issue means that the iNotes native rendering will work when viewed, but fail when sent. Real life scenarios: Note that while image resources are seldom added directly to emails, they are sent frequently when a document is forwarded. The images will look fine for the sender but be missing for the recipient. There is no easy way for the sender to know if images are inline or image resources. CoexLinks Fidelity solution: Image resources are brought inline before rendering. To avoid large sizes, the same image resource is only included in the MIME once even if it is displayed multiple times.
 
2) Table width. This problem surfaced due to a customer's confusion about why a table that was small and fixed in size was spreading across the entire width of an email. It turned out that a nicely constructed email newsletter had a table where the table was set to "Fit with margins", but every column was a fixed width. When that happens, the Notes/Domino rendering simply sees it as a variable width table. CoexLinks Fidelity solution: When all columns are fixed width, the table is treated as a fixed width table.
 
3) Non-uniform cell borders. Toward the end of the last millennium, a table in HTML either had borders or did not. After the introduction of CSS in 1996, tables in HTML with CSS could be on or off depending on the cell, something that had been true in Notes rich text for a long time already by then. Unfortunately, IBM has been slow to convert the non-uniform cell borders in Notes to non-uniform cell borders in HTML+CSS. To be fair, the Notes 9 client rendering does finally accomplish this, but the Domino 9 rendering does not. Thus, you can see the borders in the two samples above that were sent with Notes 9.0.1 rendering, but not in the iNotes rendering. Real life scenarios: Both newsletters and forms often use cell borders to make the appearance more sleek and professional. When these are sent or forwarded, the sender may not anticipate how the tables will look to the sender. CoexLinks Fidelity solution: CSS is used to match the non-uniform cell borders in Notes.
 
4) Table borders. Separate from cell borders, there is a table border which is often used for drop shadows but also for framing. Both Notes 9.0.1 and Domino 9.0.1 seem to ignore it in all their rendering engines. Real life scenarios: Newsletters, forms, and reports often use table borders, both for a professional look and, sometime, to separate out small tables. All is lost when these are rendered by Notes/Domino, no matter which rendering engine is used. CoexLinks Fidelity solution: Table borders are used, as well as inner and outer padding. As you can see in the Outlook example, not all email systems will recognize the inner and outer padding.
 
5) The color of green. In an odd quirk, the Notes client rendering confuses light green and dark green, so that both appear as dark green in emails. (I first reported this to IBM in 2007, fwiw.) This can lead to tables that don't look as they should, and occasionally to the perception of missing data as in this example. Real life scenarios: As two of the sixteen basic colors in Notes, both light and dark green are used more frequently than other colors. I have seen customer examples with the light green lettering on the dark green background which leads to this, which is why I added it to the demo. CoexLinks Fidelity solution: RGB colors are used to ensure consistency.
 

Copyright © 2014 Genii Software Ltd.