dschmidt commented on PR #3095:
URL: https://github.com/apache/tika/pull/3095#issuecomment-5493842306
Thanks, that list was worth it. All nine are in, one I would like to keep
and explain.
**renderWidth was dead**, confirmed before fixing: requesting 200 or 400
rendered at 800, because the SPI-injected renderer wins over the config-built
one. The renderer now reads the metafile parser config from the ParseContext,
the way PDFBoxRenderer reads dpi and imageType from PDFParserConfig, and a
parameterized test asserts the width in the PNG header. That gap is why no test
caught it.
**Unbounded height**: capped at 10000 like the width, with an IOException
instead of an OutOfMemoryError; both paths share one height helper now.
**Bare RuntimeException in draw(HwmfPicture)**: narrowed to
IllegalStateException, which is what POI throws for Word's bitmap-in-WMF
thumbnails ("invalid wmf file - window records are incomplete."), verified
against testControlCharacters.doc.
**Injected renderers got an empty stream**: the parser spools when it is
going to render, so the renderer is handed the metafile itself; the parsed
picture stays attached as the open container for the fast path.
**Rendering before shouldParseEmbedded**: gated now, with provisional
metadata (name, image/png, resource type) before the raster work.
**renderingName**: FilenameUtils.getName.
**renderOnlyEmbeddedResourceTypes**: validated against EmbeddedResourceType,
a typo throws instead of silently disabling rendering.
**OLE2 thumbnail**: OfficeParserConfig.extractThumbnail, default true to
match the OOXML parsers, which emit docProps/thumbnail unconditionally.
**Duplicate wiring**: AbstractMetafileParser holds the config and renderer
plumbing for both parsers.
The one I kept: the rendering of a THUMBNAIL is typed THUMBNAIL rather than
RENDERING. It is deliberate and the reason this PR chain exists: a client
should find the preview picture of any file the same way, and for an Office
document the stored thumbnail is an EMF/WMF whose only displayable form is that
rendering. The two THUMBNAIL entries are the vector original and its raster
rendering, so the client rule is "the first raster THUMBNAIL". If you would
rather keep the type strictly about provenance, I will change it back and pair
the rendering with its parent by embedded path instead.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
