Mailing List Archive

ripole output stream offset
hello,
i've compiled ripmime under a windows cygwin environment.
ripmime works well (i've used it to export my mail from
an earthlink totalaccess2004 client by first composing a
message to which all eml files in a folder are attatched,
then saving the message to a file, then extracting).

i've also tried the included ripole support. i was only
able to output streams on a word2000 document using the
[--save-unknown-streams] switch, which output six streams,
the first of which closely resembles the jpg image inserted
using insert->picture->fromfile. the original picture has
71189 bytes, while the output stream has 71564 bytes. the
hexdumps below show the added bytes at the top of the ole
stream.

olestrm1 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F A0

00000000: 8C 17 01 00 44 00 64 00 00 00 00 00 00 00 00 00 D d
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 E0 2E 28 23 .(#
00000020: D0 02 D0 02 00 00 00 00 00 00 00 00 00 00 00 00
00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000040: 00 00 00 00 0F 00 04 F0 E6 00 00 00 B2 04 0A F0
00000050: 08 00 00 00 01 04 00 00 00 0A 00 00 43 00 0B F0 C
00000060: C2 00 00 00 04 41 01 00 00 00 05 C1 AA 00 00 00 A
00000070: 06 01 02 00 00 00 FF 01 00 00 08 00 43 00 3A 00 C :
00000080: 5C 00 44 00 6F 00 63 00 75 00 6D 00 65 00 6E 00 \ D o c u m e n
00000090: 74 00 73 00 20 00 61 00 6E 00 64 00 20 00 53 00 t s a n d S
000000A0: 65 00 74 00 74 00 69 00 6E 00 67 00 73 00 5C 00 e t t i n g s \
000000B0: 41 00 6C 00 6C 00 20 00 55 00 73 00 65 00 72 00 A l l U s e r
000000C0: 73 00 5C 00 44 00 6F 00 63 00 75 00 6D 00 65 00 s \ D o c u m e
000000D0: 6E 00 74 00 73 00 5C 00 4D 00 79 00 20 00 50 00 n t s \ M y P
000000E0: 69 00 63 00 74 00 75 00 72 00 65 00 73 00 5C 00 i c t u r e s \
000000F0: 53 00 61 00 6D 00 70 00 6C 00 65 00 20 00 50 00 S a m p l e P
00000100: 69 00 63 00 74 00 75 00 72 00 65 00 73 00 5C 00 i c t u r e s \
00000110: 53 00 75 00 6E 00 73 00 65 00 74 00 2E 00 6A 00 S u n s e t . j
00000120: 70 00 67 00 00 00 00 00 10 F0 04 00 00 00 00 00 p g
00000130: 00 80 52 00 07 F0 52 16 01 00 05 05 94 FF 79 2D R R y-
00000140: C7 75 9E 7A 2E 4C 02 FB 60 DE CB E1 FF 00 2E 16 u z.L ` .
00000150: 01 00 01 00 00 00 44 00 00 00 00 00 0E 01 A0 46 D F
00000160: 1D F0 26 16 01 00 94 FF 79 2D C7 75 9E 7A 2E 4C & y- u z.L
00000170: 02 FB 60 DE CB E1 FF FF D8 FF E0 00 10 4A 46 49 ` JFI
00000180: 46 00 01 02 01 00 60 00 60 00 00 FF ED 0D 18 50 F ` ` P
00000190: 68 6F 74 6F 73 68 6F 70 20 33 2E 30 00 38 42 49 hotoshop 3.0 8BI
000001A0: 4D 03 ED 0A 52 65 73 6F 6C 75 74 69 6F 6E 00 00 M Resolution
000001B0: 00 00 10 00 60 00 00 00 01 00 01 00 60 00 00 00 ` `
000001C0: 01 00 01 38 42 49 4D 04 0D 18 46 58 20 47 6C 6F 8BIM FX Glo
000001D0: 62 61 6C 20 4C 69 67 68 74 69 6E 67 20 41 6E 67 bal Lighting Ang
000001E0: 6C 65 00 00 00 00 04 00 00 00 78 38 42 49 4D 04 le x8BIM




sunset 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F A0

00000000: FF D8 FF E0 00 10 4A 46 49 46 00 01 02 01 00 60 JFIF `
00000010: 00 60 00 00 FF ED 0D 18 50 68 6F 74 6F 73 68 6F ` Photosho
00000020: 70 20 33 2E 30 00 38 42 49 4D 03 ED 0A 52 65 73 p 3.0 8BIM Res
00000030: 6F 6C 75 74 69 6F 6E 00 00 00 00 10 00 60 00 00 olution `
00000040: 00 01 00 01 00 60 00 00 00 01 00 01 38 42 49 4D ` 8BIM
00000050: 04 0D 18 46 58 20 47 6C 6F 62 61 6C 20 4C 69 67 FX Global Lig
00000060: 68 74 69 6E 67 20 41 6E 67 6C 65 00 00 00 00 04 hting Angle
00000070: 00 00 00 78 38 42 49 4D 04 19 12 46 58 20 47 6C x8BIM FX Gl
00000080: 6F 62 61 6C 20 41 6C 74 69 74 75 64 65 00 00 00 obal Altitude
00000090: 00 04 00 00 00 1E 38 42 49 4D 03 F3 0B 50 72 69 8BIM Pri
000000A0: 6E 74 20 46 6C 61 67 73 00 00 00 09 00 00 00 00 nt Flags
000000B0: 00 00 00 00 01 00 38 42 49 4D 04 0A 0E 43 6F 70 8BIM Cop
000000C0: 79 72 69 67 68 74 20 46 6C 61 67 00 00 00 00 01 yright Flag
000000D0: 00 00 38 42 49 4D 27 10 14 4A 61 70 61 6E 65 73 8BIM' Japanes
000000E0: 65 20 50 72 69 6E 74 20 46 6C 61 67 73 00 00 00 e Print Flags
000000F0: 00 0A 00 01 00 00 00 00 00 00 00 02 38 42 49 4D 8BIM
00000100: 03 F5 17 43 6F 6C 6F 72 20 48 61 6C 66 74 6F 6E Color Halfton
00000110: 65 20 53 65 74 74 69 6E 67 73 00 00 00 48 00 2F e Settings H /
00000120: 66 66 00 01 00 6C 66 66 00 06 00 00 00 00 00 01 ff lff
00000130: 00 2F 66 66 00 01 00 A1 99 9A 00 06 00 00 00 00 /ff
00000140: 00 01 00 32 00 00 00 01 00 5A 00 00 00 06 00 00 2 Z
00000150: 00 00 00 01 00 35 00 00 00 01 00 2D 00 00 00 06 5 -


regards



__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
Re: ripole output stream offset [ In reply to ]
Hello there Moses,

Appologies about the slow response - I've been too busy building model airplanes (radio controlled :-)

> the first of which closely resembles the jpg image inserted
> using insert->picture->fromfile. the original picture has
> 71189 bytes, while the output stream has 71564 bytes. the

Unfortunately at this point, ripMIME (or rather ripOLE) doesn't know how to handle embedded images, rather it can
currently only handle attached images/files. Attached files appear as a seperate file in the OLE struture complete with
filename headers and size representation, this is all documented in the OLE formats/standards.... however, embedded
images (and other embedded files) fall under the Microsoft Word (Office I guess) /structure/ format - that is something
beyond the immediate scope of ripOLE... not sure if I'm making any sense.

If anyone knows how to accurately determine how to name/format these streams, I'd love to know.


Regards.

--
Paul L Daniels - PLD Software - Xamime
Unix systems Internet Development A.B.N. 19 500 721 806
ICQ#103642862,AOL:pldsoftware,Yahoo:pldaniels73
PGP Public Key at http://www.pldaniels.com/gpg-keys.pld
Re: ripole output stream offset [ In reply to ]
I always thought (trying to use MS speak/usage) a packaged object (most
easily created by dragging and dropping a file into an ms office document)
is an entirely different mechanism to just inserting a graphic image. I
wouldn't think the latter has anything to do with OLE at all.

Phil


On Sun, 11 Jan 2004, Paul L Daniels wrote:

> Hello there Moses,
>
> Appologies about the slow response - I've been too busy building model airplanes (radio controlled :-)
>
> > the first of which closely resembles the jpg image inserted
> > using insert->picture->fromfile. the original picture has
> > 71189 bytes, while the output stream has 71564 bytes. the
>
> Unfortunately at this point, ripMIME (or rather ripOLE) doesn't know how to handle embedded images, rather it can
> currently only handle attached images/files. Attached files appear as a seperate file in the OLE struture complete with
> filename headers and size representation, this is all documented in the OLE formats/standards.... however, embedded
> images (and other embedded files) fall under the Microsoft Word (Office I guess) /structure/ format - that is something
> beyond the immediate scope of ripOLE... not sure if I'm making any sense.
>
> If anyone knows how to accurately determine how to name/format these streams, I'd love to know.
>
>
> Regards.
>
>
Re: ripole output stream offset [ In reply to ]
> is an entirely different mechanism to just inserting a graphic image. I
> wouldn't think the latter has anything to do with OLE at all.

Generally, yes that is correct - at least that's also what I believe.

What I have noticed though is that sometimes it might depend on the setup of Office... too many variables.

In short, as you said, drag-and-drop'd items are not generally available to ripOLE (although they do appear as 'unknown
streams').



--
Paul L Daniels - PLD Software - Xamime
Unix systems Internet Development A.B.N. 19 500 721 806
ICQ#103642862,AOL:pldsoftware,Yahoo:pldaniels73
PGP Public Key at http://www.pldaniels.com/gpg-keys.pld