Ben Langhinrichs

Photograph of Ben Langhinrichs

IBM Champion logo

E-mail address - Ben Langhinrichs







Recent posts

Wed 14 Nov 2018

Short agents



Tue 2 Oct 2018

No cookies for you



Fri 28 Sep 2018

We need more than baby steps


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


Sun 20 Jul 2003, 11:10 PM
Rich Text 101 logo

Like so many other rich text structures, images have become more complex and powerful in recent releases.  Up until R4, all images fell into two categories.  Either they were "standard" images, such as the doclink icon or the default file attachment icon, or they were stored in a proprietary Notes bitmap format.  Whether the original image was a GIF file, or a JPEG file, or even a Windows bitmap file, all were converted into the ubiquitous Notes bitmap format.

While this has now changed, there were very good reasons for the decision.  Notes was a multi-OS product long before the world wide web sprang up, and it was not just the server that was multi-OS.  With clients ranging from OS/2 to AIX to Windows 3.1 to Windows NT, there was need for a graphical format that would be displayed appropriately, if not always equally, across all these OS platforms.  Since this was before the GIF and JPEG formats became standards, the proprietary Notes bitmap format was simply Lotus being ahead of the curve and creating its own standard.

After the advent of the web and more "standard" standards, Lotus released R5 with the addition of "native storage" for JPEG and GIF files.  These formats could now be stored as part of the composite data records and presented in their original format.  This had two large benefits.  The first was that the images suffered no loss from the conversions back and forth through the Notes bitmap format.  The second was that the compression technology used in these two formats was superior to the compression used in Notes bitmaps, so the images were smaller, sometimes tremendously smaller.

Current Image Formats
So where are we now?  There are now at least six different categories for images: 
  1. Standard icons for doclinks, file attachments and such
  2. Notes bitmaps (yes, they are still used, especially when cutting and pasting screen prints or importing from Windows bitmap files);
  3. GIF and JPEG native files stored in the rich text
  4. Image resources stored as separate design elements and shown inside the rich text.  These are usually JPEG and GIF files as well, although it is possible to make Notes bitmap image resources if you really try.
  5. Storage links, which are references to files stored elsewhere, such as through and attachment or a URL.  These are dynamically loaded at run time, and are usually created by importing HTML files, but can also be created by API programs such as Midas.
  6. MIME images, which are stored as MIME parts and imported to rich text at run time when displayed.  These aren't exactly rich text images, but since you can't tell the difference easily, we'll mention them here.


Now, why does it matter that we have all of these different types of images?  They all just look like images.  What difference does it make to me you?  The answers depend on what you are doing with the images, and whether they will be used on the web, and whether they may ever be changed.  Also, there are some subtle issues of how accessible your images need to be.

First, what if you want to use that image on the web?  If it is in the Notes bitmap format, the Domino engine will have to convert it to either GIF or JPEG format, which may entail some loss of fidelity.  (In other words, it may look like crap, pardon my English)  If it is in MIME format, or even storage link format, one of the weird oddities about the Domino engine comes into play, as it will first be converted to rich text and then converted back from rich text, even though it was in a web accessible format to start with.  Therefore, you really don't want that to happen.  The best answer is to ensure that you import (not copy and paste) from GIF and JPEG files in the first place.  On the web, they will be displayed in their native format, and in Notes, they will also be displayed in their native format.

Second, what if you want to change this image later, but you have used it several times in your rich text (a special image which is at the beginning of each section of a lesson, for example)?  In R4 days, you would have had to manually edit each document and change the image by re-importing the new one and deleting the old one by hand.  (OK, if you had Midas, you could have done it programmatically, but still, every document would have to be modified).  In R5 and Notes 6, you can simply make the image an image resource, and change the resource without editing the document.  No documents are modified, but the rich text changes nonetheless.

Third, what if you don't know what the image will be yet, because it comes from a URL, such as a stock chart presented as a GIF which is generated on the fly.  That image can't be in native stored format, or in an image resource, or even in Notes bitmap format, as it should be retrieved at the moment the user opens the rich text.  In that case, a storage link is most appropriate, as the URL is resolved when the user opens the document, so it may even be a different image for different users who open the document different days.

Finally, the question of accessibility is not obvious, but it does play a part.  Since Notes does not currently allow you to set alt text, which is necessary for accessibility, on an image resource, you would have to manage those images as one of the other formats.  With any luck, IBM will allow alt text to be set on image resources (perhaps a "default" alt text which could be overridden) in Notes 7.

Tip for using images more dynamically
The biggest drawback to the use of images in standard rich text, as opposed to forms, is that the images are not usually either available or modifiable.  For these reasons, it is often a good idea to use image resources.  If you do not have designer access to the database, but do have designer access to a generally available database, you can put the image resources in the available database and reference them from the locked down database.  Just make sure that any users have access to the available database!

Tip for making images appear based on conditions
It is a common mistake to add multiple images to rich text and use hide-when formulas to show them based on a set of conditions.  A far better approach is to make each an image resource and then add the image resource as a computed value and add your conditions there.  This saves space and complexity for the form or document.

Feature which doesn't translate to the web from the Notes client
An image in the Notes client can have a "caption", which appears either over or under or centered on the image.  This can be very powerful and convenient, but be aware that when translated to the web, these captions disappear completely.

Feature which doesn't translate to the Notes client from the web
The size of an image on the web can be specified in pixels, but in the Notes client, the only sizing available is through a percentage of the original size, which is just about useless unless you are visually measuring (it's about "that" big, holding your thumb and forefinger together).

Re-size images outside of Notes
If you have an image and want to show a thumbnail, or simply want to re-size the image, it may be tempting to simply use the Notes client to change the sizes, but this is a very crude method.  If the image quality matters at all, make another version of the image re-sized in an external graphics program and use that as well.  With thumbnails, this is even more important, as you not only lose quality, but you don't save any space.  The only possible exception to this tip is when the image is an image resource, and it may be better just to show the smaller size, but be prepared for pretty lousy quality on any but the very simplest re-sized graphic.

Copyright © 2003 Genii Software Ltd.

Tags: