https://issues.apache.org/bugzilla/show_bug.cgi?id=54916
Bug ID: 54916
Summary: [PATCH] POI does not always read all the slides in
pptx files
Product: POI
Version: 4.0-dev
Hardware: PC
OS: All
Status: NEW
Severity: major
Priority: P2
Component: XSLF
Assignee: [email protected]
Reporter: [email protected]
Classification: Unclassified
Created attachment 30248
--> https://issues.apache.org/bugzilla/attachment.cgi?id=30248&action=edit
Patch for bug
I believe this bug may affect all XML-based formats that POI supports, but my
specific use case is with pptx files.
For some reason, a number of pptx files that I was given contain slides with
rels that contain relationships to other slides in the
ppt/slides/_rels/slideX.xml.rels files. Microsoft Office 2010 is able to deal
with these files and open them correctly.
When POI encounters such a file, generally it will omit one or more of the
slides when you call getSlides() on the XMLSlideShow object. When this occurs,
error messages such as "Slide with r:id 256 was defined, but didn't exist in
package, skipping" will be logged.
I believe what is happening is during building of the parse tree, POI treats
all references/relationships as equal, and if there are two or more
relationships that occur in the file, then POI uses the first occurrence to set
the package relationship field. If the first time that POI runs across it is as
a child reference, then the package relationship field is set incorrectly, and
later on POI sometimes may not be able to resolve it correctly.
I've determined that the simplest fix is to first parse all elements at a given
level, before trying to resolve elements at lower levels. This fixes my
problem, and doesn't break any unit tests.
The attached patch contains the fix, and a sample pptx file that exhibits this
behavior with a very simple test case.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
