Genii Weblog
Rich Text 101 - Text
Mon 22 Sep 2003, 01:58 AM
Tweetby Ben Langhinrichs
While many other things can be found in a rich text field besides text, such as tables, doclinks, images and more, a great deal of rich text is just that, text. In my previous article on paragraphs, I mentioned that even in the properties box listed as "Text", most of the properties are actually paragraph properties. In fact, only the very first tab is actually related to text properties.
There are some important differences between paragraph attributes and text attributes. Text attributes are available for any run of text, so that the string "The brown fox jumped over the haystack" is actually three separate runs of text with different text attributes. Paragraph attributes must be applied to an entire paragraph, so you can never have two sets of different paragraph attributes on the same line. This is why when two fields must appear on the same line but should have different hide-when formulas (paragraph attribute), the solution is to put each in its own table cell. Every table cell starts with a new paragraph.
Font Faces
Any text shown on a form must appear in some font face. For text and number and date and keyword fields, this font face is determined on the form, which is also rich text as described in my paragraph article. For rich text, this font face is determined by default by the form, but may change at will within the rich text. A sentence, a phrase, a word or even single letter can be in a different font face, such as Comic Sans MS. As I will mention below, the fact that a font face is defined for a rich text run does not always mean it can be displayed by the person reading the rich text. For this reason, there are four default font faces, Default Sans Serif, Default Serif, Default MultiLingual and Default Monospace. (For those who used Notes in earlier versions, these used to be called Helv, Roman, Typewriter and Courier). Text set to be displayed in one of these four fonts will actually be displayed in the font that is defined as default for that type. The default fonts can be set through File - Preferences - User Preferences under the Default Fonts button.
$Fonts and the Case of the Messed Up Font Faces
Long time users of Lotus Notes can usually recall many cases of font faces that changed mysteriously. Often, all fonts other than the default four were all converted to monospace with little explanation. Sometimes, one rich text field was appended to another with catastrophic results to the font faces of either the new or old rich text. While some of these problems have been resolved in R5 and ND6, it is still possible to see this happen when a rich text item is copied as an item, for example.
The reason for all of these problems is the $Fonts field. In the hazy mist of time, it was decided that font faces should not be referenced directly in rich text. Rather, each of the default four font faces could be referred to by a number between zero and four (there is one left over that is not used), and each new font that was used would be added to the $Fonts item, which contains a font table. Thus, the first new font would cause a $Fonts item to be added, and the face number would be five. The second would be appended to the $Fonts item and the face number would be a six. This way, even if the two new fonts were used liberally throughout one or more rich text fields, each reference would only contain the face number.
While this was efficient, it caused immediate problems. Imagine that a form (Form A) is created using Comic Sans MS as its first new font. (Remember that forms are rich text as well.) The face number would then be five. Now, imagine that a second form (Form B) has no special font faces, so it has no $Fonts item. Finally, imagine that a document is created using the second form and a special font, let's say Verdana, is used in the rich text. Since that is the first special font, a $Fonts item is created on the document, with a face number of five. What happens when the document with the $Fonts item is displayed using not Form B, but rather Form A. On Form A, the face number five means Comics Sans MS, but in the $Fonts item that was carried with the document, the face number five means Verdana.
What should happen in these cases is that the font tables get merged and all font face numbers get updated (which is what the Midas Rich Text LSX does), but what often happened in previous release was that one $Fonts item overwrote the other, and the font face was misidentified. In the similar current case where the rich text is copied as an item without the $Fonts being copied as well, the font face numbers aren't recognized at all, and are often treated as monospace. In yet another variation, a well meaning developer copies the $Fonts item with the rich text, neglecting the fact that there might already be a $Fonts item, and thus all the original font associations are broken. Yikes!
Fortunately, you can avoid most of these problems in ND6 by using the AppendRTItem, which seems to do a fairly good job of merging the font tables and updating the fonts. Of course, if you still have trouble, you can fall back on using Midas in almost any version and get the same merging and fixup.
Text Attributes
While the font face and point size may be loosely described as "text attributes", what is meant in this case are the attributes such as Bold, Italics, Underline, SuperScript, SubScript, Strikethrough, Shadow, Emboss and Extrude. These text attributes can be combined (even to the point of silliness), except for the Shadow, Emboss and Extrude, which are mutually exclusive. It is worth noting that these last three attributes are also only displayed in the Notes client. There is no matching text attribute in standard HTML, although there are some close equivalences in CSS. In general, it is not wise to use text attributes too extensively, as they tend to be wearing on the eyes. On the other hand, these attributes can be printed, while text colors are often lost on the printed page.
Text Colors
In earlier releases of Notes, there were only sixteen colors available for text. These colors have constant names which are used with the NotesRichTextStyle class in Notes. Additional colors were available from a color pallette. In R5, RGB colors were added as well, so now text can be almost any color available through RGB colors. It should be cautioned that these colors are often lost in the translation to MIME when mail is sent through the internet, so when the rich text is intended for that use, it may make more sense to add emphasis through text attributes.
A great advantage of the use of RGB colors is that there is no need to match the pallette used in Notes with that used on the web, as was necessary in R4 to get color fidelity.
Point Size
Not much to be said here, except that it should be noted that not all fonts allow all point sizes. This is especially worth noting for the default fonts. If my Default Sans Serif font is Arial, I may set the point size to 4pt to make a very small line of text, but if the reader's Default Sans Serif doesn't display anything smaller than 8pt, the text won't look small the way I intended. It is a good rule of thumb not to use anything but standard font sizes, usually 8, 10, 12, 14, 18, with the default four font faces. (Obviously, if you can be quite sure of the font used in your company, you can disregard this rule)
Pass-Thru HTML
An additional attribute of rich text is the Pass-Thru HTML attribute, available only through the Text menu. This can be used to mark raw HTML code that should be passed to the browser, but it should be avoided for mixed Notes client/web browser applications, as the HTML appears as is to the Notes client. It should also be noted that this menu item is greyed out if there is not a Designer client on the workstation.
Be careful when using the Pass-Thru HTML, as it tends to mask returns. If you just want one line to have the attribute, and want a return to follow, make sure the last character of the line does not have the attribute. On the other hand, if you want to avoid a return after the marked line, make sure the attribute extends to the very end of the line, and possible to the first character of the next.
Highlighter
This is an underutilized feature added in R5 that allows you to highlight text the way a textbook is highlighted, by turning on the Text - Highlighter - Use Pink Highlighter (or Yellow or Blue) and drawing the mouse over the desired text. One advantage to this form of highlighting is that it does not effect any of the regular text attributes. One disadvantage is that it is hard to control and not obvious how to clear the highlight attribute once it is in place.
Just so you know, the way to clear the highlighter is to leave the Highlighter menu item checked and then hold down the Shift key. Going backward over the highlighted text will erase the highlight. [Note: It has been pointed out by Jan Van Puyvelde that the Shift key does not need to be held down. Just going backward will erase the highlight. I am not sure whether this was always the case, but it highlights the fact that I don't even know for sure how to undo this properly]
A disadvantage of the highlighter is that Domino will not translate it to HTML, since there is not native HTML method for highlighting. There is a CSS property that could display this, but it is not used by Domino in R5 or ND6. For the moment, this feature should not be used for web applications, mixed applications or where the rich text is to be mailed outside of the Notes environment.
Permanent Pen
This is a great feature added in R5 that seems to be widely used in some organizations and completely unknown in others. The way it works is that you can turn on a combination of text attributes, text color, point size and font face, and then use the menu item Permanent Pen - Set Permanent Pen Style. From that point on, and this is a workstation dependent feature, when you click on the smart icon that looks like a pen point, or use the Permanent Pen - Use Permanent Pen Style menu item, your typing will follow the saved style. The best use for this is when editing a document, since you can easily identify your changes and edits. Among groups that use this frequently, it is common for each member to pick his or her own color and style, after which just a glance at a revised document can tell any member who has edited and what changes were made.
Language tagging
This text feature was added in ND6, and allows you to tag text as belong to a specific language. Thus, a phrase which was appropriate in Spanish but which did not translate well to French could be replaced by a different phrase which made sense in French. This is a powerful feature, but be careful, as it is hard to read the multiple phrases and make sure all get updated simultaneously.
Bi-directional text
Some languages, such as Hebrew, are read from right to left rather than left to right. This is only slightly visible, as the text is usually aligned right rather than left, but the font face is the only sure way to tell, as there is no text property exposed for bi-directional text. For example, Time New Roman (Hebrew) is right to left, but that is only obvious if you know it ahead of time.
Conclusion
Rich text can appear as little more than plain text, but can also be immensely rich and complex. While overuse of these features is not likely to be pleasant, it is also worth remembering that features such as Permanent Pen and Highlighting, as well as Language Tagging, are all ways to use rich text as part of your application and part of your feature set. Too little use of font faces, colors and text attributes can leave your text harder to read and harder to decipher. Judicious use of attributes can guide the reader to important points. Rich text is a resource to be used wisely, not under or overutilized.
Related Articles
A number of the articles in the Rich Text 101 series contain information closely related to this topic. Take a look at any of these articles to learn more about the text in rich text:
Copyright © 2003 Genii Software Ltd.
What has been said:
51.1. Henry Kaye (09/22/2003 06:51 AM)
Extremely valuable and (like all Ben's stuff) well written. There's a lot more to bidrectional than he touched on, but if you're not involved in that area, be happy!
51.2. Ben Langhinrichs (09/22/2003 06:58 AM)
I was thinking of you, Henry, when I wrote this. There is more to bidirectional text, as as as more to mutli-byte characters sets such as Korean and all, and I will probably update this when I can figure out how to say what I need to say more clearly. Thanks for the post.
51.3. Jan Van Puyvelde (09/22/2003 07:30 AM)
Small correction about "Highlighter": the shift key is not needed; just drag right to left.
51.4. Ben Langhinrichs (09/22/2003 09:26 AM)
Thanks. I corrected it in the article.
51.5. Khader (11/22/2005 03:55 AM)
Hi Ben,
I have a problem with replication in Lotus Notes. My Lotus Notes version is 6.5
I write a replication formula so that it does not make the changes to the profile documents, while replicating from server to local or vice versa.
I give the formula as "select form != "ProfileDocument"
But, the profile documents also gets replicated.
What should i do so that the profile documents, does not gets replicated ?
Please do let me know if you have any solution to this problem.
Thanks
Khader.
51.6. Neha (12/05/2007 04:35 AM)
Hi Ben ,
I have a rich text field which when displayed in web removes the formating which was done using Notes interface.
Is it possible to maintain the formatting in web , If yes how and what are the limitations.
it is displayed through a computed field and is just in read mode.
please respond as soon as possible
Thanks
Neha