You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@poi.apache.org by Darien Kindlund <po...@kindlund.com> on 2004/02/24 01:15:38 UTC
EscherRecord Specifications
Hi. Long-time lurker; first-time poster.
Regarding Library: org.apache.poi.ddf
I've looked at the EscherRecord.java specifications and compared them
against what appears the OpenOffice and KOffice Escher code. To foster
understanding, I'm assuming this is the rough breakdown of Escher
"record headers":
header - 8 bytes
"version" - 4 bits unsigned
"instance" - 12 bits unsigned
"type" - 16 bits unsigned
"length" - 32 bits unsigned
In EscherRecord.java:
EscherRecord.options = (instance << 4 | version)
EscherRecord.recordId = type
... and length never really gets saved
Questions:
1) Aside from knowing that (version == 0xF) implies container, can
anyone attempt to explain meaning behind the "version" and "instance"
fields?
2) Before asking the question, here is some known information:
- The "type" or "recordId" defined within the library can have values
ranged from 0 to 65535... let's call that the "type spectrum".
- EscherDump.java and other corresponding files refer to record types
which are 0xF000 and above on the spectrum.
- Escher is known to exist in multiple applications, agnostic to some
extent.
- OpenOffice/KOffice references associate Escher with PPT specifically;
KOffice references the type spectrum ranging from 0 to about 10,000
(0x2710).
This suggests that there's some set range in the "spectrum" dedicated
for specific applications versus shared use... can anyone provide
additional insight as to what the partition structure may look like?
Thanks in advance,
-- Darien Kindlund
---------------------------------------------------------------------
To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: poi-dev-help@jakarta.apache.org
RE: EscherRecord Specifications
Posted by Michael Zalewski <za...@optonline.net>.
My guess is that these applications do not keep track of multiple records of
the same type. In fact, I'm not even certain that there is any more than one
version for each specific record type. Most of the records have a version
value of "0". The 'Shape' atom has a version of "2" in Office 97. Perhaps if
Office 2000 adds more basic types of shapes, the version could be "3" if
produced in Office 2000, and "4" in Office 2003. It would be interesting to
find an Office file with a 'Shape' atom that had a version of other than
"2".
Not sure if that answers your question. As far as I know, there is never any
stream offsets kept in Escher. Data is mostly kept inside atoms, and given
some type of ID. For example, each basic shape is given a 2 byte Shape ID
(called a SPID, which is actually 2 parts, a 6 bit cluster and a 10 bit
sequence). Other atoms which want to refer to a particular shape would
contain this SPID instead of a offset to the shape atom.
-----Original Message-----
From: Glen Stampoultzis [mailto:gstamp@iinet.net.au]
Sent: Wednesday, February 25, 2004 2:00 AM
To: POI Developers List
Subject: Re: EscherRecord Specifications
At 03:06 AM 25/02/2004, you wrote:
>Alright, any ideas as to how these applications keep track of multiple
>records of the same type? (i.e., recording relative byte-offsets or
>recording the exact order stored?)
By order stored as far as I know. There is also a record called
msofbtDgg that is used to track shape numbers it doesn't actually index
into the file so I'm not sure it helps any.
Glen Stampoultzis
gstamp@iinet.net.au
http://members.iinet.net.au/~gstamp/glen/
---------------------------------------------------------------------
To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: poi-dev-help@jakarta.apache.org
Re: EscherRecord Specifications
Posted by Glen Stampoultzis <gs...@iinet.net.au>.
At 03:06 AM 25/02/2004, you wrote:
>Alright, any ideas as to how these applications keep track of multiple
>records of the same type? (i.e., recording relative byte-offsets or
>recording the exact order stored?)
By order stored as far as I know. There is also a record called
msofbtDgg that is used to track shape numbers it doesn't actually index
into the file so I'm not sure it helps any.
Glen Stampoultzis
gstamp@iinet.net.au
http://members.iinet.net.au/~gstamp/glen/
Re: EscherRecord Specifications
Posted by Darien Kindlund <po...@kindlund.com>.
Michael Zalewski wrote:
> Version for atoms is probably just a record version. It always appears to be
> the same value per type of record when the drawing is made in Excel.
>
> The meaning of "instance" depends on the type of atom. For example, on a
> Properties atom, "instance" contains the number of properties.
Alright, any ideas as to how these applications keep track of multiple
records of the same type? (i.e., recording relative byte-offsets or
recording the exact order stored?)
> The Escher records used by Excel will have a type between 0x0f000 and
> 0x0f200. These correspond to the basic low level drawing shapes, such as
> lines, arrows, and images. Powerpoint also uses the same basic types (with
> type between 0x0f000 and 0x0f200), but it has many more types which
> represent such things as slides, bullets, slide titles, arrangements, etc.
> (I thought Powerpoint used 0x0e000 through 0x0efff but I could be rong).
Based on KOffice at least, PPT uses 0x0000 through about 0x2710.
URL:
http://www.koffice.org/developer/apidocs/filters/html/powerpoint_8h-source.html
That URL references the header file; check the corresponding .cc file
for the detailed mapping used.
If you have info suggesting 0xe0000 - 0xefff is also used, could you
provide a URL to the project code that uses it?
>
> A good reference for the low level Escher objects (those used in common by
> all Office applications) is at
>
> http://chicago.sourceforge.net/devel/docs/escher
Interesting prefix used...
MSOFBH
msofbt
The "mso" is obvious; any ideas as to what the "fb" signifies?
TIA,
-- Darien
> There is also some less well organized description of Powerpoint at
>
> http://www.wotsit.org/download.asp?f=powerpoint97
>
> -----Original Message-----
> From: Darien Kindlund [mailto:poi@kindlund.com]
> Sent: Monday, February 23, 2004 7:16 PM
> To: poi-dev@jakarta.apache.org
> Subject: EscherRecord Specifications
>
> Hi. Long-time lurker; first-time poster.
>
> Regarding Library: org.apache.poi.ddf
>
> I've looked at the EscherRecord.java specifications and compared them
> against what appears the OpenOffice and KOffice Escher code. To foster
> understanding, I'm assuming this is the rough breakdown of Escher
> "record headers":
>
> header - 8 bytes
> "version" - 4 bits unsigned
> "instance" - 12 bits unsigned
> "type" - 16 bits unsigned
> "length" - 32 bits unsigned
>
> In EscherRecord.java:
>
> EscherRecord.options = (instance << 4 | version)
> EscherRecord.recordId = type
>
> ... and length never really gets saved
>
> Questions:
>
> 1) Aside from knowing that (version == 0xF) implies container, can
> anyone attempt to explain meaning behind the "version" and "instance"
> fields?
>
> 2) Before asking the question, here is some known information:
>
> - The "type" or "recordId" defined within the library can have values
> ranged from 0 to 65535... let's call that the "type spectrum".
>
> - EscherDump.java and other corresponding files refer to record types
> which are 0xF000 and above on the spectrum.
>
> - Escher is known to exist in multiple applications, agnostic to some
> extent.
>
> - OpenOffice/KOffice references associate Escher with PPT specifically;
> KOffice references the type spectrum ranging from 0 to about 10,000
> (0x2710).
>
> This suggests that there's some set range in the "spectrum" dedicated
> for specific applications versus shared use... can anyone provide
> additional insight as to what the partition structure may look like?
>
> Thanks in advance,
> -- Darien Kindlund
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: poi-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: poi-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: poi-dev-help@jakarta.apache.org
RE: EscherRecord Specifications
Posted by Michael Zalewski <za...@optonline.net>.
Version for atoms is probably just a record version. It always appears to be
the same value per type of record when the drawing is made in Excel.
The meaning of "instance" depends on the type of atom. For example, on a
Properties atom, "instance" contains the number of properties.
The Escher records used by Excel will have a type between 0x0f000 and
0x0f200. These correspond to the basic low level drawing shapes, such as
lines, arrows, and images. Powerpoint also uses the same basic types (with
type between 0x0f000 and 0x0f200), but it has many more types which
represent such things as slides, bullets, slide titles, arrangements, etc.
(I thought Powerpoint used 0x0e000 through 0x0efff but I could be rong).
A good reference for the low level Escher objects (those used in common by
all Office applications) is at
http://chicago.sourceforge.net/devel/docs/escher
There is also some less well organized description of Powerpoint at
http://www.wotsit.org/download.asp?f=powerpoint97
-----Original Message-----
From: Darien Kindlund [mailto:poi@kindlund.com]
Sent: Monday, February 23, 2004 7:16 PM
To: poi-dev@jakarta.apache.org
Subject: EscherRecord Specifications
Hi. Long-time lurker; first-time poster.
Regarding Library: org.apache.poi.ddf
I've looked at the EscherRecord.java specifications and compared them
against what appears the OpenOffice and KOffice Escher code. To foster
understanding, I'm assuming this is the rough breakdown of Escher
"record headers":
header - 8 bytes
"version" - 4 bits unsigned
"instance" - 12 bits unsigned
"type" - 16 bits unsigned
"length" - 32 bits unsigned
In EscherRecord.java:
EscherRecord.options = (instance << 4 | version)
EscherRecord.recordId = type
... and length never really gets saved
Questions:
1) Aside from knowing that (version == 0xF) implies container, can
anyone attempt to explain meaning behind the "version" and "instance"
fields?
2) Before asking the question, here is some known information:
- The "type" or "recordId" defined within the library can have values
ranged from 0 to 65535... let's call that the "type spectrum".
- EscherDump.java and other corresponding files refer to record types
which are 0xF000 and above on the spectrum.
- Escher is known to exist in multiple applications, agnostic to some
extent.
- OpenOffice/KOffice references associate Escher with PPT specifically;
KOffice references the type spectrum ranging from 0 to about 10,000
(0x2710).
This suggests that there's some set range in the "spectrum" dedicated
for specific applications versus shared use... can anyone provide
additional insight as to what the partition structure may look like?
Thanks in advance,
-- Darien Kindlund
---------------------------------------------------------------------
To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: poi-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: poi-dev-help@jakarta.apache.org