[
https://issues.apache.org/jira/browse/TIKA-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18135782#comment-18135782
]
ASF GitHub Bot commented on TIKA-5017:
--------------------------------------
tballison merged PR #3468:
URL: https://github.com/apache/tika/pull/3468
> PPTX SAX extractor iterates slides in "lexographic relationship id" order
> instead "presentation" order
> ------------------------------------------------------------------------------------------------------
>
> Key: TIKA-5017
> URL: https://issues.apache.org/jira/browse/TIKA-5017
> Project: Tika
> Issue Type: Bug
> Components: parser
> Affects Versions: 4.0.0
> Reporter: Ken Reese
> Priority: Minor
> Attachments: libreoffice-twelve-slides.pptx
>
>
> This seems like a regression in behavior between the how the old PPTX DOM
> extractor worked and how the newer PPTX SAX extractor works.
> The current PPTX SAX extractor is iterating slides in lexographic order of
> their relationship id instead of actual presentation order. This doesn't
> always make sense - you can have `rId10` show up before `rId4` for example.
> Tika is currently just using POI to iterate `ppt/_rels/presentation.xml.rels`
> and returning the slides in whichever order POI returns in - which is just
> using the relationship id as a key in a `TreeMap`. So we really shouldn't be
> relying on the POI iteration order to give us the actual slide order back
> here.
> I think we should instead be looking at `ppt/presentation.xml` to get the
> slide ordering, which is how Tika used to work when it used the DOM extractor
> by default. As of 4.0.0, the DOM extractor implementation has been completely
> remove from Tika, so there is no longer an easy workaround.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
