You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@poi.apache.org by Nick Burch <ni...@torchbox.com> on 2005/04/29 17:08:02 UTC

Problems with DDF

Hi All

I'm trying to use DDF to handle the Escher records in PowerPoint, as part 
of my PowerPoint support. As part of this, I'm seeing quite a lot of 
problems with the DDF support.

What's the best course of action here? Should I file a bunch of bug 
reports, and discuss if I've correctly understood how things should work 
there? Shall I post them here for discussion?

Here are a couple of samples:
* atom of type F00D is of type msofbtClientTextbox, but 
   DefaultEscherRecordFactory is returning it as EscherContainerRecord
* atom of type F010 (msofbtClientAnchor / EscherClientAnchorRecord) is 
   sometimes returning a length (via record.getRecordSize()) of 26, when 
   it's only 16 on the disk. A call to record.toString() includes
   "Extra Data: error" at the bottom
* it appears that the only way to handle an entry containing
    RecordContainer
     RecordContainer
      Record
      Record
    Record
  is to grab the atom lengths from offset 5 in the header, and walk on 
   yourself making repeated calls to DefaultEscherRecordFactory - there's 
   no way to know how far to skip on by calling methods of a record, and
   there's nothing to return a tree of records

Cheers
Nick


---------------------------------------------------------------------
To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
Mailing List:    http://jakarta.apache.org/site/mail2.html#poi
The Apache Jakarta POI Project: http://jakarta.apache.org/poi/

Re: Problems with DDF

Posted by an...@superlinksoftware.com.
Nick Burch wrote:
> Hi All
> 
> I'm trying to use DDF to handle the Escher records in PowerPoint, as part 
> of my PowerPoint support. As part of this, I'm seeing quite a lot of 
> problems with the DDF support.
> 
> What's the best course of action here? Should I file a bunch of bug 
> reports, and discuss if I've correctly understood how things should work 
> there? Shall I post them here for discussion?

I'd post then if no one seems more clueful then just either post a bug 
report or patch.  We're about to commit more stuff here so its possible 
it may be fixed but uncommitted.

> 
> Here are a couple of samples:
> * atom of type F00D is of type msofbtClientTextbox, but 
>    DefaultEscherRecordFactory is returning it as EscherContainerRecord
> * atom of type F010 (msofbtClientAnchor / EscherClientAnchorRecord) is 
>    sometimes returning a length (via record.getRecordSize()) of 26, when 
>    it's only 16 on the disk. A call to record.toString() includes
>    "Extra Data: error" at the bottom
> * it appears that the only way to handle an entry containing
>     RecordContainer
>      RecordContainer
>       Record
>       Record
>     Record
>   is to grab the atom lengths from offset 5 in the header, and walk on 
>    yourself making repeated calls to DefaultEscherRecordFactory - there's 
>    no way to know how far to skip on by calling methods of a record, and
>    there's nothing to return a tree of records
> 
> Cheers
> Nick
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
> Mailing List:    http://jakarta.apache.org/site/mail2.html#poi
> The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
Mailing List:    http://jakarta.apache.org/site/mail2.html#poi
The Apache Jakarta POI Project: http://jakarta.apache.org/poi/