From what I remember about Office Document Properties, these are just different from the NT file forks, as these also exist under Windows 9x. I remember there being some OLE/COM interfaces that allowed you to get/set these properties. But as these properties have to survive copying and FAT32 filesystems, they are stored within the main fork of the file.

Of course I might be totally wrong about this.

I've never thought that SummaryInformation was stored anywhere except inside the file, for COM "Compound Document" files specifically including MS Office files. The shell extension simply looks at that.

Meanwhile, I noticed that Windows 2000 allowed a Summary tab on other files as well. I assumed it stored that in an alternate stream, but never looked into it in detail.

So I disagree with your second paragraph. To read SummaryInfo from a Structured Storage file, use the SS-related function for that. (IPropertyStorage, I think). The COM SDK has a page "Structured Storage Serialized Property Set Format". If that interface is a dual (dispatch-enabled), then it's a simple matter to drive with Perl's OLE module and then parse out the individual fields.

The alternate data stream is trivial to read from Perl, once you figure out the correct name. I suppose it uses the same serialized format.

I agree, a Perl module to read/write this information would be awesome! It would figure out which way is being used, and use the proper way to add info to a file that doesn't have it already.

—John

xlHtml This project displays Excel ss as html docs. It works pretty well. There is also a pptHtml -- not so great. It uses the (open source) Cole library to read the files and comes with some utilites to read and analyze the files and their internal filesystems.

wotsit seems to have some info on file formats that might be useful.

HTH, --traveler

I was reading about the Summary info only the other night in a Delphi COM Programming book. Something about Property Sheets. In a DocFile, there are streams directly off the root (where the stream name starts with, I think, 0x05). The stream you want is <0x05>SummaryInformation. If you've got Visual Studio, you can use the DocFile Viewer to look at these streams. You *should* be able to use OLE::Storage or OLE::Storage_Lite to get into these (but I've never tried it myself). I'm not sure if you are trying for a pure Perl i.e. platform-independent solution or a Windows-only one (in which case you could write a helper DLL). The underlying API calls you need are StgOpenStorage and then using the returned IStorage interface, OpenStream (dunno if you could use Win32::API with these calls?).

   :♣SebiesnrMkudrfcoIaamtykdDa:$DATA	136
   :♣SummaryInformation:$DATA	128
   :{4c8cc155-6c1e-11d1-8e41-00c04fb9386d}:$DATA	0

For those not familiar with Windows, the club is really a character code 0x0005. The DOS OEM code page shows a clubsuit for that code point. So maybe there's a translation happening between ANSI/OEM code pages when you try to open the file. Try turning ON the Wide System Call support, and use \x{0005} explicitly in the name, and see if that works for you.

—John

Check this out!

#!/usr/bin/perl -wT

use strict;

open ( AAA, "$ARGV[0]:\x{0005}SummaryInformation" )
  or die "Cannot open: $!\n";

while ( <AAA> ) {
  print "$_\n";
}
[download]

WOOHOO! I can read it, now. But can I set it. Have to fire up hexl-mode.el

Thanks All! I'll post my final code when I'm done!

UPDATE: http://msdn.microsoft.com/library/en-us/com/hh/com/stgasstg_7agk.asp has assitional programming information about this.

HTH
--
idnopheq
Apply yourself to new problems without preparation, develop confidence in your ability to to meet situations as they arrise.

~ Shunryu Suzuki

So, it was the literal chr(5) getting munged?

Hmm, that's odd. As written, it will convert the Unicode to ANSI using the current code page before calling the OS primitive. Ah, it probably passes the 5 unchanged (thus breaking symetry: a 5 is converted to the club character.)

Just to be more kosher, I'd use Wide system calls, or use a byte-oriented string.

How to read it: Load it in and use the OLE interface to un-persist it. I think you need to read it as one binary lump.

Here's a suggestion when you get past the proof stages: have a tied hash to get/set Summary Info or other supported property sets.

—John