A malformed spreadsheet could trigger a very large allocation.
Can be overruled by users via IOUtils.setByteArrayMaxOverride().
Fixes https://issues.oss-fuzz.com/issues/476431391
* Support rendering transparent bitmaps in presentations.
Add PictureShape.getAlpha() method and implementations for HSLF and
XSLF. Then make use of it in DrawPictureShape to apply the right alpha
value to the picture being drawn.
Fixed a bug in BitmapImageRenderer that considered alpha value 0 as
"fully opaque", when it means "fully transparent" instead.
Finally, added a test for this feature in TestDrawPictureShape for XSLF.
A test for HSLF could not be created because it was not possible to
generate a test file with today's tools; MS Office removes the
bitmap transparency effect when saving as .ppt, and LibreOffice blends
it into the bitmap.
* Address reviewer comments.
* Add comment about default alpha value.
* Prevent NPE in XSLFPictureShape.getAlpha().
* Change wording in comments to avoid the word "percentage".
* Use static vars for extreme alpha values.
These can be embedded in slideshows and POI supports
some handling of them.
Also Tika uses this code to extract some textual information
from such images.
These can be embedded in slideshows and POI supports
some handling of them.
Also Tika uses this code to extract some textual information
from such images.
When retrieving picture data
When retrieving text in slides
When handling XSLFTableStyles
In EmbeddedExtractor if ShapeName is not set
In HSSF with invalid EscherSpRecord
In HSSF with invalid RecordStreams
When drawing arcs for shapes in slides
In HSSFPicture.getPictureIndex
Adjust "opens" for tests in poi-ooxml
Either handle it gracefully or throw
IllegalStateException instead for broken files
* 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.
