Bug 55566 - [PATCH] Accept 0-based ID values
Summary: [PATCH] Accept 0-based ID values
Status: RESOLVED FIXED
Alias: None
Product: POI
Classification: Unclassified
Component: XWPF (show other bugs)
Version: 3.9-FINAL
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: POI Developers List
URL:
Keywords: PatchAvailable
Depends on:
Blocks:
 
Reported: 2013-09-17 16:21 UTC by Joachim Breuer
Modified: 2016-07-26 12:58 UTC (History)
2 users (show)



Attachments
Patch extending the accepted identifier range to include 0 (837 bytes, patch)
2013-09-17 16:21 UTC, Joachim Breuer
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Joachim Breuer 2013-09-17 16:21:44 UTC
Created attachment 30854 [details]
Patch extending the accepted identifier range to include 0

XWPF documents using identifiers starting with 0 will currently fail with: "IllegalArgumentException: Value for parameter 'id' was out of bounds".

This is due to the IdentifierManager being initialized for IDs starting at 1.

Documents from LibreOffice (at least 4.0.4.2 and 4.1.1) may use IDs starting at 0. (AFAIU IDs get used for objects embedded into the documents, i.e. pictures.)

See also http://stackoverflow.com/questions/18756484/getting-illegalarguementexception-value-for-parameter-id-was-out-of-bounds

With the attached trivial patch, POI/XWPF worked correctly for such documents here.
Comment 1 Edu Garcia 2014-05-27 04:25:35 UTC
Is there any reason this hasn't been patched already?
Comment 2 Nick Burch 2014-05-27 09:59:35 UTC
This is pending a unit test, along with a very small file that shows the problem, which can be used to check that the problem is fixed by the bug + remains fixed into the future
Comment 3 Edu Garcia 2014-05-28 00:54:35 UTC
The following document breaks it: calibre-ebook.com/downloads/demos/demo.docx
Comment 4 Nick Burch 2014-05-28 14:18:50 UTC
Do you know what license that file is under? We can only accept test files that are either under the ASLv2, or explicitly contributed to us by the author
Comment 5 Dominik Stadler 2016-07-26 12:58:54 UTC
This was already fixed a while ago via github-18 - Handle documents with a picture-only header, see r1661908 for details