It appears that I can store bitmap files in D3NT by setting a Q pointer
to a directory:

PICS
01 Q
02
03 NT_BIN:C:\PICS

then I can copy to a D3 File (TEMP) where it is stored in binary:

:COPY PICS T.BMP
TOTEMP

CT TEMP T.BMP

001 CC
002 45813
003 1

Then I copy it back out and the image is entact! So I can store BMP's
inside D3 and back it up, and restore. Great!

Now I want to read the item in D3, do Base64 encoding, then stuff that
in an XML document then send it off to somewhere else. Everything works
except the bitmap.

I did a search and it was suggested to not use READ but to use C
functions, which I did, but the resulting image after reading and
writing does not appear properly (the image is close but it is shifted
in the bottom). I am assuming it may be because of CHAR(255) characters
in the BMP?

Is there a way around this or am I spinning my wheels? I would like to
stay inside D3 if possible.

Thanks for any help.

Steve

Leave it encoded in Base64 and you won't have corruption problems. If it's
not encoded already, encode it before you store it in D3.

Glen

"steves" <srs (AT) perfectionsoftware (DOT) com> wrote

You know that a signature captured as a bitmap has
absolutely no legal standing, right?

There are products out there that capture signatures,
including biometric data (pen speed & pressure) then
encrypt the signature, using the document being signed
as a key, so that the signature can only be decrypted
and displayed when that same (unchanged) document is
used as the decryption key, thus assuring that the
signature was applied to the document in question.

And, the encrypted signature is available as an ASCII
string, so no binary worries, and easy to pass between
web pages and ActiveX controls, for example.

--
frosty

That is cool! I haven't looked at this area for a while, and like the
idea of the document being the decrption key - don't suppose you have
any pointers, or should I just google ...

Ross Ferris wrote:
I'm developing for the ClipGem from Topaz Systems (dot com.)

A good google is "eSign law," BTW.

--
frosty

When you read a binary item into D3 the special characters that
conflict with the the file system get converted to something safer.
When you export they are re-converted.

If you input and go through the conversion, then encode that with
Base64, you are encoding the converted values, so you aren't getting
xFF, you are getting something more like x00270F or something like that
(memory escapes me on the actual values). Of course if you decode that
Base64 into a file that you think is an image it's not going to work
well at all.

Base64 is pure text. I suggest you do one of the following:
1) Import as binary, export as binary, then encode to Bas64 after
export and prior to sending somewhere else.
2) Encode to Base64 then import as text where no conversions will take
place. From here you can embed the image in email or otherwise process
it directly from D3.

I know you want to process everything in D3 but you're not going to
convert the D3 version of binary into Base64 without some pain. It'll
be much easier and a near immediate solution to just use external
tools.