Genii Weblog


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


Mon 13 Oct 2003, 11:01 PM
Now, as anyone fluent in two or more languages can tell you (not that I am, but I used to be reasonably good in Spanish, so I at least aspire to join those ranks), something is lost in translation when text in one language is translated to another.  Even in English (as in the UK) and English (as in American), there are many phrases or expressions which do not translate.  For example, a fellow Penumbra Group member from the UK recently used the phrase "push the boat out", which left us here on our side of the pond scratching our heads.  It lost something in translation (incidentally that phrase means "to celebrate by treating one's acquaintances to a drinking session" according to Brewer's Dictionary of Phrase & Fable).
 
In the often fiery collision between the Notes client and the Web browser, there are many bits lots in translation.  Tabbed tables were a great addition to the Notes client for R5, but look cheesy at best as rendered by Domino R5 (they are better rendered by Domino 6).  Nested tables are used frequently in web browsers for positioning, but do not translate well to the Notes client due to different assumptions, such as the minimum .25 inch width for a table row in the Notes client.  In general, translation from rich text to HTML is better than the other way around, as long as the content is meant to be viewed live on-line with a Domino server in place.  HTML to rich text works only if there is no reliance on CSS, and if the HTML is fairly simple.  This works well when reading simple MIME/HTML mail, but falls woefully short when reading more sophisticated newsletters or web content.
 
So, as usual, I have been working to build a better mousetrap.  Midas 3.20 (which exports HTML from rich text very well, if I do say so myself) imports HTML fairly well, actually taking CSS into account in many ways, and generally working to understand the intent of the HTML.  Still, some bits are very difficult to translate.  Below is an example.
 
In CSS, you can add a border and background around a set of text delimited by a <div>text</div> block.  This looks a bit like:
 
<div align="center" style="{ color : Navy; background : Silver; border-width : thin; border-color : Black; padding-left : 5; border-style : groove; font-weight : bold; }">COEX! Links User's Guide</DIV>
 
and renders like:
 
 
COEX! Links User's Guide
(although it is usually handled by a class rather than a style parameter).  The question is, how should this be handled when imported by the Notes client.  You could simulate it with a table, but that would raise other stylistic issues if you use CSS for tables in the Notes client.  So, in Notes 6, a border attribute was added to the text properties, so that you can add similar borders to paragraphs in Notes.  Pretty cool too, but there are a few issues.  Many of the same border attributes are available as are for a table, such as groove edges and colored borders, etc., but not all the same as in CSS.  In CSS, each border, the top, bottom, left and right, can have a different style and color and width.  In the Notes client, there is but one color and style, although there can be different widths.  More importantly, and this is the biggest loss, there can not be a background color for the div.  This is a major loss, as can be seen by the example:
 
<div align="center" style="{ color : Yellow; background : Black; border-width : thin; border-color : Yellow; padding-left : 5; border-style : groove; font-weight : bold; }">COEX! Links User's Guide</DIV>
 
which renders as:
 
 
COEX! Links User's Guide
 
which would look more like:
 
 
COEX! Links User's Guide
 
if rendered using the other attributes without the background.  Ironically, if rendered by Domino, this would look like
 
 
COEX! Links User's Guide
 
which is better than the rendering using the CSS in this one case, albeit with no colors, no bold, no borders.
 
So, when it comes down to it, which should Midas handle?  Should it render all the attributes it can, which is the basic approach in Midas 3.20, in which case the first table looks like that below?
 
 
COEX! Links User's Guide
 
or should it be even smarter and recognize when the contrast between the background which it can't render and the text color it can is important, so that Yellow or White on Black would be rendered differently?  Argghh!
 
The Domino approach has been wimpy, in my not so humble opinion.  The Notes client implements layers and borders on paragraph and such in a clear nod to HTML and CSS, but the Domino rendering engine doesn't render them all.  Layers are implemented, but the borders are completely ignored, even though they were clearly built to have a direct translation between the two features.  What's up with that?  Going the other way, the same loss is found, with the CSS borders ignored when imported to rich text.
 
Now, I understand when English doesn't have 37 different words for snow, as the Eskimo supposedly do, so there will be loss in translation between the Eskimo for "that special wet slushy snow which is perfect for throwing at your sister so that it drips down the back of her shirt" and the English "wet snow".  What I don't understand is when HTML/CSS has a simple way of describing borders for paragraphs which uses almost exactly the same terminology as the rich text way of describing borders for paragraphs, because the rich text way was a direct copy, yet the HTML/CSS doesn't translate.  If the Spanish word is "papa" and there is an English word called "papa", wouldn't you use it?  Wouldn't you at least use "dad"?  Why would you use "unknown man"?
 
Anyway, to draw my own line in the sand (or whatever analogy you want), Midas does its best to translate better.  Every once in a while, as with the yellow on white background, the effect may be worse, but while it is one thing to lose a little in translation, I don't really believe we should lose a lot.

Copyright © 2003 Genii Software Ltd.