I have a person form that contains a richtext in which I need the user to insert his photo. The photo should be visible if someone opens the document via the notes client.The same data is displayed in XML using the ?readviewentries.
In case I UIDOC.INSERT THE PHOTO in the Notes document the URL Notes generates is something like
…nsf/0/d9c524d4c0feefbcc125737f0071ef64/PhotoL/0.8A?OpenElement&FieldElemFormat=gif
Where does that 0.8A come from. is there a way to get to that value via script or formula?
In case I ATTACH THE PHOTO I can use
…nsf/0/d9c524d4c0feefbcc125737f0071ef64/$FILE/whoglelogo125x40.gif
but I can not display that file in the Notes client.
I want to avoid that I need to have the same image twice in the document to serve both the notes client and the browser.
Thanks in advance,
Luc
Subject: Show a picture in the Notes client AND be able to show the same picture via an URL in the browser
It is a total nuisance that I have spent a lot of time dealing with. There are four basic approaches, with limitations on all of them.
-
Use imported images, but calculate the offset of the graphic and use that. This works well, except that there is no simple native way to retrieve the offset. I do it this way with our CoexEdit product and it works well, but there should be a simpler way to get the offset.
-
Reference the attachment in the rich text for Notes with a MIME storage link. Again, this works, but only if you either have a product that will create the MIME storage link in the midst of your rich text (e.g., our Midas Rich Text LSX), or have a rich text field that is just there for the image, in which case you can use native LotusScript to create the MIME parts (see NotesMIMEEntity class). The biggest limitation is that if you edit the document from Notes, the reference is converted to a regular rich text image, which then breaks the connection between Notes and web.
-
Save the rich text as MIME, then reference the MIME part directly. This is probably your best bet, although I hate to recommend it. If you just check the checkmark on the second tab of your rich text field, the contents will be saved as HTML and MIME. That includes images, so if you know how many images you have, you can use a format such as
Now, when you look at the document properties for the Body field, you will see that it is saved as MIME in separate parts, and the image is the third part:
Therefore, since we start with part 0, we can directly reference the image without knowing an offset by using:
http://server/MyDb.nsf/viewid/docid/Body/M2?OpenElement
which will continue working even if additional text is added. You still need to know which image is which, and there is some fidelity loss when going from rich text to MIME, but since you already have fidelity loss when going from rich text to HTML, that may be OK.
- Storage links. This is the mechanism IBM actually designed to solve the dilemma of specifying an image that can be displayed in both places, but it is not well implemented. If you change the database setting shown below to “Display images after loading”, the images are actually stored as attachments which can be referenced from both places. Unfortunately, they are not stored as graphic file attachments, which would make sense, but as compound rich text fields, which is horrible and buggy.
Nonetheless, if you choose to go this way, the URL for the image is something like
http://server/MyDb.nsf/viewid/docid/$file/attname/attname.gif?OpenElement
which seems easy enough. The only problem is, the attachment name is always an internally generated one rather that the image name, so you have to find it first, and you can’t create the files manually from the web, but need to create them from Notes. Sigh!
Subject: Show a picture in the Notes client AND be able to show the same picture via an URL in the browser
What about combining a file attachment and pass-through HTML for Notes display (leaving the option to render pass-through HTML in Notes enabled)?
_att := @AttachmentNames;
“<img alt="" src="/” + @WebDbName + “/” + @Text(@DocumentUniqueID) + “/$FILE/” + _att[1] + “">”
Does work (in 7.0, I didn’t test it in 6.5), at leas if there is only one attachment.