Ben Langhinrichs

Photograph of Ben Langhinrichs
E-mail address - Ben Langhinrichs

Recent posts

Fri 27 Apr 2018

Our digital selves

Wed 18 Apr 2018

The long strange trip with Midas

Wed 4 Apr 2018

Pondering pre-anonymization and GDPR

July, 2009
   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.

Mon 13 Jul 2009, 04:01 PM
There are some annoying limits in Lotus Notes, although fewer than there used to be, but it is hard to beat Microsoft Word 2007 (and because it uses Word, Microsoft Outlook 2007), for incomprehensible and annoying limits, which seem to crop up without errors or warning.  For example, look at Gabriella's post about iFidelity on the iPhone.  Those nice colored bars work in Internet Explorer, Firefox, Safari, on the iPhone, in Lotus Notes, in Outlook 2003, in Gmail - heck, just about anywhere rational.  Where doesn't it work?  That's right, in Outlook 2007 or Word 2007.  Instead, you get this really stupid looking result (below)

Stupid Outlook 2007 appearance

But the question is, why?  Why does it work everywhere else, but not in Outlook/Word 2007?  What's worse is, you can go in and resize the graphics (in a reply or forward),  and it appears to allow the change, but then silently reverts to this size, with no indication of why.  You can drag the image border to make it bigger, but it snaps back when saved.  But why?  The answer seems incredible, but perhaps the properties box below will give you the hints you need:

Picture attributes in Outlook 2007

The answer is simple, once you look closely.  The size of the graphic (shown in inches, much as Notes would) is 0.01" by 0.01", although is is really a 1 pixel by 1 pixel graphic.  That is pretty typical on the web.  The height is shown 0.69", and even though you can adjust that to much larger, it snaps back to 0.69" when saved.  The big clue is the percentage, which is shown as 6600%.  You math geeks will probably immediately recognize that this is somehow related to a rounded 65536.  That's right, the graphic can't be resized larger than 6600 percent (6553, really, but it displays this way) of its original size, meaning there is a size limit based on a two byte unsigned word, divided for some reason by ten.

And you thought only Notes had these archaic and arbitrary limits.  Sure, 6600% sounds like a lot to expand a graphic, but given the frequency with which small gifs are used for tiled background and the like, this is a completely unacceptable limit for real HTML emails or documents.

Copyright © 2009 Genii Software Ltd.


Mon 13 Jul 2009, 01:49 PM
In the 1960's, Phil Spector developed a sound production technique which became known as the "wall of sound" in which a whole bunch of different guitarists played the same parts, and the whole thing was recorded in an echo chamber.  (Sounds a bit like the blogosphere, now that I think of it.)  When looking at how Microsoft Outlook and Gmail interact, it is hard not to think of that dense, echoing quality, as each takes the approach that its way is right, and no amount of HTML thrown at a problem is too much.

To see a bit of this in action, I'll take my recent post, Collaboration: From Notes to Outlook to Gmail to Notes, in which I focused only on the beginning and end of the cycle, and instead show a tiny bit of the middle, where Microsoft Outlook and Gmail crash together, bestowing honor on neither.

The snippet I'll concentrate on is one created in Notes using iFidelity, but it is pretty standard HTML, if perhaps a bit wordy.

<span style="font-size: 14pt; font-family: sans-serif; "><strong>Spam</strong></span>
<span style="font-size: 14pt; color: rgb(0,0,255); font-family: sans-serif; "><strong>Geek</strong></span>
<span style="font-size: 14pt; font-family: sans-serif; "><strong> for Domino - SMTP Log</strong></span>

While these could have been simplified, standards and guidelines are followed.

Now, what happens when Microsoft Outlook receives this message and forwards it?

<strong><b><font size=4 face=Arial><span style='font-size: 14.0pt;font-family:Arial'>Spam</span></font></b></strong>
<strong><b><font size=4 color=blue face=Arial><span style='font-size:14.0pt;font-family:Arial; color:blue'>Geek</span></font></b></strong>
<strong><b><font size=4 face=Arial><span style='font-size:14.0pt;font-family:Arial'>for Domino - SMTP Log</span></font></b></strong>

Outlook doesn't approve of the styles or the <strong> tag, even though both are recommended practice, but rather than replacing them, it simply adds a <b> tag and a font tag which duplicate the information (after arbitrarily changing the "sans-serif" font to "Arial" and using a size of 4, which is a deprecated way of referring to the font size).  Queue the duplicate guitars, please.

Now, how does Gmail process this message and forward it again?

<b><b><font size="4" face="Arial"><span style="font-size: 14pt; font-family: Arial;">Spam</span></font></b></b>
<b><b><font color="blue" size="4" face="Arial"><span style="font-size: 14pt; font-family: Arial; color: blue;">Geek</span></font></b></b>
<b><b><font size="4" face="Arial"><span style="font-size: 14pt; font-family: Arial;">for Domino - SMTP Log</span></font></b></b>

You might think that Gmail would be wary of email from Outlook, which is, whether we like it or not, the leading business email system of our time.  Since Gmail doesn't seem to like the <strong> tag either, and since this dense layered approach is extremely common and well known with Outlook mail, you might think it would notice that there was already a <b> tag, but it doesn't.  Instead, Gmail creates a nested <b> tag, which is flat out wrong.

Of course, in this instance, Outlook is more to blame since it doubled the attributes in the first place, but at least it created "correct" HTML, albeit with an overdeveloped sense of backward compatibility, since the code would work even in browsers that didn't use CSS.  Gmail is less to blame in this instance, but did create "incorrect" HTML.

For those still interested, going the other way around is a bit better, but only because iFidelity happens to more closely mirror what Gmail expects.  The original HTML:

<span style="font-size: 14pt; font-family: sans-serif; "><strong>Spam</strong></span>
<span style="font-size: 14pt; color: rgb(0,0,255); font-family: sans-serif; "><strong>Geek</strong></span>
<span style="font-size: 14pt; font-family: sans-serif; "><strong> for Domino - SMTP Log</strong></span>

is modified when forwarded by Gmail to:

<span style="font-size: 14pt; font-family: sans-serif;"><b>Spam</b></span>
<span style="font-size: 14pt; color: rgb(0, 0, 255); font-family: sans-serif;"><b>Geek</b></span>
<span style="font-size: 14pt; font-family: sans-serif;"><b> for Domino - SMTP Log</b></span>

with the only real change being a switch from <strong> to <b>.

Now, this is modified by Outlook to be:

<b><font size=4 face=Arial><span style='font-size:14.0pt;font-family:Arial;font-weight:bold'>Spam</span></font></b>
<b><font size=4 color=blue face=Arial><span style='font-size:14.0pt;font-family:Arial;color:blue;font-weight:bold'>Geek</span></font></b>
<b><font size=4 face=Arial><span style='font-size:14.0pt;font-family:Arial;font-weight:bold'>for Domino - SMTP Log</span></font></b>

which duplicates everything and has an extra space added before the "Geek" part, but is otherwise correct.  It is a tiny bit more justifiable putting the font-weight:bold in than it was putting the <b> in when there was already a <strong>, but the decision to weigh down every email with all the duplicate stuff, along with the absolutely massive header stuff Outlook adds, is certainly not helping the congestion in the world's email systems, and all of it leads to more processing work for each subsequent email processor.  

Not to mention, the echoes and noise are giving me a headache.

Copyright © 2009 Genii Software Ltd.


Mon 13 Jul 2009, 11:54 AM
Just to be clear, I am simply trying to learn about this topic, and do not currently have any iFidelity magic to make it better.  I am not even (entirely) certain that what Lotus iNotes is doing is wrong, or whether it is simply a design decision with some unfortunate ramifications.  I mentioned in one of my iFidelity posts that the:
Dojo editor seems to strip out some colors (including the "Geek" in SpamGeek), so now I have to see if I can find a work around for Dojo bugs
It turns out I was incorrect, and that it has nothing to do with Dojo (as far as I can tell), and is a problem back in 8.0, and possibly earlier (although I have not verified yet).

The issue is with MIME emails (ones with HTML) that are displayed in Lotus iNotes.  These are different than rich text emails displayed in iNotes, because in general, you might think that iNotes could simply display the HTML part and let the browser handle it.  Unfortunately, there are valid reasons for the HTML to be manipulated, especially if there are images stored in the message.  In a MIME email, an image may be referred to by URL if it is available on the Internet, or by CID (content-id) if it is stored in the message.  Since the browser would not know how to find the content-id referenced image, the HTML must be modified.  Similarly, sometimes the HTML is modified to ensure that the content doesn't sneak out of the iNotes frame, as in this LinkedIn message with a sprite:

<h3 style="background:url( 0 -60px no-repeat; padding: 5px 0 5px 25px; color:#666; margin-bottom: 0; font-weight:normal; font-size: 13px">CONNECTIONS</h3>

which gets stripped to 


But notice what got stripped out is not just the background image, but the (text) color, font-size, font-weight and margins.  Still, perhaps IBM's preprocessor takes a better safe than sorry attitude when there are any background graphics or that sort of thing.  Not smart, but possible.  What it doesn't explain is the following:

<font size="4" face="sans-serif"><strong>Spam
<font color="#0000ff" size="4" face="sans-serif"><strong>Geek
</font><font size="4" face="sans-serif"><strong> 
for Domino - SMTP Log

which looks like this:  Spam Geek for Domino - SMTP Log

gets stripped to:

<font size="4" face="sans-serif"><strong>Spam
<font size="4" face="sans-serif"><strong> 
for Domino - SMTP Log

which looks like this: Spam Geek for Domino - SMTP Log

I can't figure out what rule the preprocessor thinks it is following, and there are many similar cases where either the style or font attributes are stripped out.  Since I can't figure out the rules (yet), I have not been able to come up with really solid answers (yet), although I have discovered some ways to make it more likely that Lotus iNotes won't strip out styles and colors when it shouldn't.

Copyright © 2009 Genii Software Ltd.