* Allow to load a word document with chartex chart
ChartEx (new charts introduced in Office 2016) will raise exceptions in underlying XML parsing, we catch them here in order to still be able to load the document
* spacing
some extra spaces were unbearable and could have prevented the pull request
* add test
* Update POIXMLDocumentPart.java
* Update POIXMLDocumentPart.java
* Update POIXMLDocumentPart.java
* reduce risk of swallowing zip bomb exceptions
* Update POIXMLDocumentPart.java
---------
Co-authored-by: PJ Fanning <pjfanning@users.noreply.github.com>
* Fix rules for table style application in XSLFTables.
Table styles contain rules for first and last rows/columns, even and
odd rows/columns... When one of these rules is empty, we are supposed
to fall back to the "whole table" rules. The fallback must also be
applied for the format that's not explicitly specified in the specific
rules.
when the corresponding specific rule is missing some info.
Fallback must also be applied when the corresponding specific rule is
missing some info. A couple of examples from the reproducer/test file
included:
The included reproducer/test file contained a few problems related to
table style application:
* The second style for horizontal/vertical banding (band2H, band2V) was
never applied.
* In the table with horizontal banding enabled, the style band1H did
not set a font color, POI returned a null font color instead of the
color from wholeTable.
* In the table with horizontal banding enabled, the style band2H did
not set a background color, POI returned null instead of the color
specified in wholeTable.
This patches fixes the behaviors mentioned above, making POI behavior
match the one from MS Office and LibreOffice.
* Replace uses of java.util.list.getFirst().
We recently changed the getters so they don't create the PPr object if
it doesn't exist, but we missed adding one null check for the new
situation.
Add a test to exercise all the getters in a case where there isn't a PPr
object.
Besides the start/center/end values specified in the OOXML standard,
Word also uses "left" and "right" as values. We need to support this
to prevent POI code from crashing with such documents.
Fixes: https://bz.apache.org/bugzilla/show_bug.cgi?id=69744
* Add getters and setters for XWPFTable indentation.
The element tblPr->tblInd represents "table indent from leading margin".
It specifies the indentation which shall be added before the leading
edge of the current table in the document (the left edge in a
left-to-right table, and the right edge in a right-to-left table). This
indentation should shift the table into the text margin by the specified
amount.
This value is specified in the units applied via its type attribute. Any
width value of type pct or auto for this element shall be ignored.
If this element is omitted, then the table shall inherit the table
indentation from the associated table style. If table indentation is
never specified in the style hierarchy, no indentation shall be added to
the parent table. If the resulting justification on any table row is not
left, then this property shall be ignored.
To implement this property, we included a getter and a setter for the
property value, and another couple of getter/setter for the existence
(and validity) or absence of the property itself, for clients to know
they must fall back to the table style.
* Address reviewer comments.
* Allow null values in XWPFParagraph.get/setAlignment().
A null value in this field would indicate that the paragraph should
follow the alignment provided by the style hierarchy.
Fixes: https://bz.apache.org/bugzilla/show_bug.cgi?id=69720
* Revert getAlignment() and implement isAlignmentSet() instead.
* Replace test case file.
* Implement XWPFParagraph.getTCPPr(create).
It lets the caller choose if a new PPr should be created in case it
doesn't exist.
* use getCTPPr(boolean)
* compile issue
---------
Co-authored-by: PJ Fanning <pjfanning@users.noreply.github.com>
Prevent too deep nesting by throwing an exception
instead of just not parsing more nesting-levels as
this still caused OOMs.
Allow to adjust the limit via static setter as elsewhere
to give users a chance to parse very complicated files
if really necessary.
https://issues.oss-fuzz.com/issues/42528505
git-svn-id: https://svn.apache.org/repos/asf/poi/trunk@1923277 13f79535-47bb-0310-9956-ffa450edef68
Currently processing stops at multivalued properties.
This at least continues processing, so other properties are processed properly.
git-svn-id: https://svn.apache.org/repos/asf/poi/trunk@1923051 13f79535-47bb-0310-9956-ffa450edef68
Processing formats uses regular expressions. Very complex formats
can recurse very deeply and thus can cause StackOVerflows depending
on the used stack-size.
In order to handle this a bit more gracefully, we now catch this
and report a better exception with details about the parsed
format and potential mitigation.
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=66137
git-svn-id: https://svn.apache.org/repos/asf/poi/trunk@1919342 13f79535-47bb-0310-9956-ffa450edef68
