0

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 conversion was working fine for all the sample but few days back we came across sample file with notesbitmap tag, after reading few forums it was mentioned that

"For the problem images in your DXL export, do they result in a element in the output, or a ? If the latter, I believe they are actually image references instead of actual images; the notesbitmap data is not a gif, but contains a binary header and URL in a Notes-specific format."

But where can i find the URL in notes specific because when i decode the second data it gives me garbage result instead of url.

I also tried setting the ConvertNotesBitmapToGif .net property to true before conversion.

Please find the below link for sample DXL: http://www.page-monitor.com/Downloads/Exported2.xml

Details:

xP8gAAEAAQAAAAgAAAAAAAAAAAAAAAAAU1RHNjI2NTeVACYAAAAAAAAAAAAAAAAAAAAAAAAA0wF/ AAAAAAAAAAAAAAAAAA==

is the header info i.e image name

and filedata below at the bottom should give the URL (as per the Lotus notes forum)

Any help will really be appreciated!!

Thanks and Regards Haseena

JesusFreke
  • 19,784
  • 5
  • 65
  • 68
Haseena Parkar
  • 939
  • 2
  • 12
  • 28

3 Answers3

1

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 ....

leyrer
  • 1,444
  • 7
  • 9
  • Yes you are correct the first encoded data gives me file name but by decoding $FILE data to base64 and writing it to gif file does not gives be an images i think here the format differs:(, then we opened the file in raw mode, we got an idea that first 72 bytes (i.e looking for GIF keyword) are header so excluding that if i extract the data i was able to get the image. But now the problem i have few other files where exlcuding 72 bytes does not work http://www.page-monitor.com/Downloads/ExportedOutputech.xml – Haseena Parkar Aug 22 '12 at 07:32
0

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.

zfr
  • 339
  • 4
  • 11
0

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