Lotus Notes DXL Notesbitmap to GIF

Question

I am converting lotus notes document library inline images to gif images using dxl logic of reading Filedata and converting it to base64 byte[] and creating a gif images. The co

Answer 1

Using DXL you can extract the 'filedata' for $File item containing the bitmap image. The filedata is Base64 encoded so it will need to be decoded to obtain the binary data.

The structure of the Bitmap data is as follows: 1. WORD - Number of Blocks 2. One or more WORDs for each block with the length of each block 3. WORD - TYPE_COMPOSITE Flag

Following the header are the CD Records for the bitmap. Typically the CD records are: - Graphic - Bitmap Header - One or more Bitmap Segments - Bitmap Color Table - Bitmap Pattern Table

What you can do is remove all bytes up to the TYPE_COMPOSITE flag (but keep the TYPE_COMPOSITE flag bytes) and write the binary data to a file.

Then using the AppendRTFile method of NotesRichTextItem you can import the image into a rich text item.

More detailed information on doing this and a sample agent to parse the binary data can be found on our website at: https://www.agecom.com.au/support/agecomkb.nsf/0/58cbf10f0ab723c9ca25803e006c7de8

Answer 2

From http://publib.boulder.ibm.com/infocenter/domhelp/v8r0/index.jsp?topic=%2Fcom.ibm.designer.domino.main.doc%2FH_NOTESBITMAP_ELEMENT_XML.html

notesbitmap element

Represents a proprietary Notes bitmap image. Images stored in an NSF file are comprised of base64 content, which is a series of CD (composite data) records representing a bitmap.

Therefore, if you run

xP8gAAEAAQAAAAgAAAAAAAAAAAAAAAAAU1RHNjI2NTeVACYAAAAAAAAAAAAAAAAAAAAAAAAA0wF/ AAAAAAAAAAAAAAAAAA==

though a base64 decoder, you get

`Äÿ ������������������STG62657�&�������������������Ó�������������

And you will find "STG62657" further down in the DXL

<item name="$FILE" summary="true" sign="true" seal="true">
<object>
<file hosttype="cdstorage" compression="none" flags="storedindoc" encoding="none" name="STG62657" size="2332">

Which you can decode ....

Answer 3

The first byte of the base64-encoded data (0xC4) refers to

#define SIG_CD_STORAGELINK      (196 | WORDRECORDLENGTH)

In your case it is a reference, but it also can be the image data itself. So it is always a good idea to check the data prefix.

The storage link format is like that:

#define STORAGE_LINK_TYPE_OBJECT        1
#define STORAGE_LINK_TYPE_NOTE          2
#define STORAGE_LINK_TYPE_URL_CONVERTED 3
#define STORAGE_LINK_TYPE_URL_MIME      4
#define STORAGE_LINK_TYPE_MIME_PART     5
#define STORAGE_LINK_TYPE_MIME_OBJECT   6

#define STORAGE_LINK_LOAD_DEFERRED  1
#define STORAGE_LINK_LOAD_ON_DEMAND 2

/*  Structure for externally stored objects */
typedef struct {
    WSIG Header;
    WORD StorageType;           /* Type of object (Object, Note, URL, etc.) */
    WORD LoadType;              /* How to load (deferred, on demand, etc.) */
    WORD Flags;                 /* Currently not used */
    WORD DataLength;            /* Length of data following */
    WORD Reserved[6];           /* Currently not used */
                                /* Storage data follows... */
} CDSTORAGELINK;

The image data may appear in the document "as is" (but base64-encoded) or compressed. By LZ1 compression, for example, the image data is organised to chunks. If for a particular chunk a compression saves space - it is compressed, if after a compression the resulting data size grown (it is a normal situation for already compressed data types like GIF) - the chunk is stored not compressed.

An occasional interchange of a compressed and uncompressed chunks may be confusing if you do not know the explained above: a correctly started data at some point turns into garbage.