Fifteen years ago, I started a campaign to convince IBM to at least fix the very easiest of rendering issues, the point size of text. I wrote about it on forums and brought it up with IBMers, but nobody seemed to care. It was part of my motivation for writing CoexEdit, which is now AppsFidelity. A memorable post from early 2005 is Selling a 9 year old on CoexEdit, and when CoexEdit was a Beacon Award finalist in January 2006, I thought maybe the point had been made.
Well, not quite. Not only was the point problem not fixed in version 9.0.1 or its many fixpacks, but it remained inconsistent. A couple examples. Pay attention to where the small sizes change.
Notes/Domino 9.0.1 MIME rendering (sending as email whether rendered by client or server)
Domino 9.0.1 HTTP rendering (viewing on web page)
There are other renderings as well, such as when the form saves the rich text field as MIME, when Domino Access Services renders the document to MIME. Sometime 9pt is <font size=1> and sometimes it is <font size=2>. While 10pt and 11pt appear about the same in all, sometimes the size is explicit, as in this from the rich text saved as MIME:
<font size=1 face="Times New Roman">Text in 6 pt</font>
<br><font size=1 face="Times New Roman">Text in 7 pt</font>
<br><font size=1 face="Times New Roman">Text in 8 pt</font>
<br><font size=1 face="Times New Roman">Text in 9 pt</font>
<br><font size=2 face="Times New Roman">Text in 10 pt</font>
<br><font size=2 face="Times New Roman">Text in 11 pt</font>
<br><font size=3 face="Times New Roman">Text in 12 pt</font>
<br><font size=3 face="Times New Roman">Text in 13 pt</font>
<br><font size=4 face="Times New Roman">Text in 14 pt</font>
<br><font size=4 face="Times New Roman">Text in 15 pt</font>
<br><font size=4 face="Times New Roman">Text in 16 pt</font>
<br><font size=4 face="Times New Roman">Text in 17 pt</font>
<br><font size=5 face="Times New Roman">Text in 18 pt</font>
<br><font size=5 face="Times New Roman">Text in 19 pt</font>
<br><font size=5 face="Times New Roman">Text in 20 pt</font>
and other times it is implicit such as this from the Domino HTTP:
<font size="1" face="Times New Roman">Text in 6 pt</font><br>
<font size="1" face="Times New Roman">Text in 7 pt</font><br>
<font size="2" face="Times New Roman">Text in 8 pt</font><br>
<font size="2" face="Times New Roman">Text in 9 pt</font><br>
<font face="Times New Roman">Text in 10 pt</font><br>
<font face="Times New Roman">Text in 11 pt</font><br>
<font size="4" face="Times New Roman">Text in 12 pt</font><br>
<font size="4" face="Times New Roman">Text in 13 pt</font><br>
<font size="5" face="Times New Roman">Text in 14 pt</font><br>
<font size="5" face="Times New Roman">Text in 15 pt</font><br>
<font size="5" face="Times New Roman">Text in 16 pt</font><br>
<font size="5" face="Times New Roman">Text in 17 pt</font><br>
<font size="6" face="Times New Roman">Text in 18 pt</font><br>
<font size="6" face="Times New Roman">Text in 19 pt</font><br>
<font size="6" face="Times New Roman">Text in 20 pt</font><br>
While that seems an innocent difference, remember that CSS will override a missing size differently than an explicit size, so you can have a magnified text page where the 10pt and 11pt are larger than the 14pt, 15pt, 16pt, and 17pt.
All of these issues ignore the extremely easy to implement CSS style that will use point sizes, as our products have done since late 2004.
But while IBM did not pay attention, HCL is aware of the issue and making some progress. If you look at the Notes client MIME rendering (email sent when location document specifies sending MIME), you will see:
Notes 10.0.1 MIME rendering (sending as email rendered by client)
Finally, CSS styling to get exact point sizes! This is implemented as well in places where the form saves the rich text field as MIME. It is not fixed when the Domino server renders the MIME, as in:
Domino 10.0.1 MIME rendering (sending as email rendered by server)
It is also not fixed in Domino 10.0.1 HTTP or Domino Access Services:
Domino 10.0.1 HTTP rendering (viewing on web page)
But HCL gets that this is an issue. They mentioned fixing rich text as a major bullet item in their AppDev roadmap at the Factory Tour, and this is one of many fixes necessary and (as far as I can tell) planned.
The point is consistency, accuracy, and fidelity. HCL gets it. Hopefully, soon we will all get there.
Copyright © 2019 Genii Software Ltd.
Tags: HCLLotus Notes #dominoforever