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

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.