One of the extremely frustrating things about working with Notes rich text is that it contains so many great ideas abandoned at the end of twisty passages, waiting to be discovered and revived by an intrepid future developer, except that the intrepid future developers have all wandered off to do Ruby on Rails or Flex or whatever.
One of these great concepts, added and then never fully utilized, is the anchor link. I griped extensively about anchor links six years ago in Anchors aweigh
, and I have made futile attempts to interest IBM ever since. They are still in the product, still under-utilized, still missing the essential ability to add an anchor separate from the anchor link, and, hardly to my surprise, still rendered badly in MIME messages sent out by Notes 8.5, and still rendered badly in iNotes 8.5. (FYI: I added programmatic support in our Midas Rich Text LSX in Version 1.2, back when Notes 4.6 came out, assuming it would quickly become unnecessary. No such support is available even today in the Notes 8.5 native classes.)
While I can't believe I need to explain this, let me give a brief primer about the purpose of anchor links and how you might use them. You put an anchor somewhere (in HTML, this would look like <a name="Bottom"> or <a name="Chapter%207">). Then, other people can create a link to that spot in the text (in HTML, that might be <a href="#Bottom">Link to the Bottom</a> or, in the longer form, <a href="http://www.MyServer.com/mydb.nsf/0/A1C28F4D6CC5CB6B88256F15005676C7?OpenDocument#Chapter%207
">Chapter 7</a>). In the Notes client, you can't create the anchor separately (although see my post linked above for some clever ways to do this), but instead you create the anchor and then link to it immediately. Stupid rule, because it means you must have edit rights, and indeed edit, a document in order to create a link to a specific point, but that's the limitation.
Now, here's the clue that IBM missed. When you link to an anchor inside the same document, you stay in the same document. This radical idea allows you to do handy things such as a Table of Contents on a long document, or links to specific places in the document. So, when you email this document to somebody else, what do you not want them to do? You don't want them to try to get back to your mailbox and your document.
Yet, in both iNotes and in outbound emails generated by the Notes 8.5 client (or any client back to R5 days, when they just used to skip the links entirely), the link created tries to open the document back in your mailbox. What it does not do, and this is the really wonderful, sadistic touch, is keep the anchor in any form, but just skips it. So, here are the various things IBM has accomplished for you:
- you go to a different document, which you shouldn't;
- the link is copied as a Notes URL, which makes little sense to the web client, and none to iNotes, and can't be followed back; and
- you have no more access to the anchor, thus ensuring that you haven't a clue where you were even meant to go.
Needless to say, iFidelity does a better job than this. In iNotes and outbound rendering, it makes sure you go to the anchor in the same document. In inbound rendering, it turns your link back into a link inside the same document. There, IBM, one free clue. Enjoy!
Update: Interestingly, I discovered that iNotes 8.5 actually seems to have a random response to anchor links. Two different anchor links on the same page render differently, one as a long complex iNotes link that opens another copy of the same document, but not to the anchor, the other which is a Notes URL which does include the anchor, but doesn't go there when clicked. I have not yet figured out why one acts one way and the other a different way, but if I create several anchor links, about 50% do one and 50% do the other - both wrong, but at least different!
Copyright © 2009 Genii Software Ltd.
Tags: Lotus Notes iFidelity Midas Rich Text LSX