[
https://issues.apache.org/jira/browse/TIKA-4855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18110262#comment-18110262
]
ASF GitHub Bot commented on TIKA-4855:
--------------------------------------
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.
> Render EMF/WMF images to raster previews and emit the OLE2 SummaryInformation
> thumbnail
> ---------------------------------------------------------------------------------------
>
> Key: TIKA-4855
> URL: https://issues.apache.org/jira/browse/TIKA-4855
> Project: Tika
> Issue Type: Improvement
> Reporter: Dominik Schmidt
> Priority: Major
>
> Office documents carry their preview image as a vector metafile: the OOXML
> docProps/thumbnail.emf of Word (an EMF wrapping a WMF) and thumbnail.wmf of
> Excel, and the SummaryInformation thumbnail (PIDSI_THUMBNAIL,
> CF_METAFILEPICT, a WMF) of the OLE2 formats, which PowerPoint writes almost
> always and Word/Excel on request. Neither is usable as a preview outside
> Windows, and outside the JVM there is no maintained EMF/WMF rasterizer. POI's
> HEMF/HWMF can draw both and Tika already bundles them.
> Proposal, following the PDF parser's rendering design:
> 1. A Renderer for image/emf and image/wmf (POI HemfPicture/HwmfPicture drawn
> onto a white canvas, a PNG of a configurable width, the height following the
> aspect ratio). The WMF thumbnails Word writes consist of a setWindowExt and a
> dibStretchBlt record only, for which POI cannot compute bounds; for those the
> renderer emits the record's bitmap.
> 2. EMFParser and WMFParser implement RenderingParser and, with "emf-parser" /
> "wmf-parser": {"renderImage": true, "renderWidth": 800} (off by default),
> emit the rendering as a RENDERING embedded document named after the image,
> the way the PDF parser emits page renderings. An injected renderer is used
> when it supports the type, the POI one otherwise.
> 3. OfficeParser emits the SummaryInformation thumbnail of the OLE2 formats as
> a THUMBNAIL embedded document (image/wmf, named thumbnail.wmf), consistent
> with the docProps thumbnail of the OOXML parsers. Existing tests that count
> the embedded documents of .ppt fixtures gain one.
> With that, a client that asks for THUMBNAIL and RENDERING embedded documents
> gets a raster preview for docx, xlsx, doc, xls and ppt files that carry a
> thumbnail, with the same request it uses for every other format. Verified
> against tika-server with /unpack: each of these yields the thumbnail at depth
> 1 and its PNG rendering at depth 2.
> Note for clients: with rendering enabled every embedded metafile is rendered,
> e.g. the picture of an OLE object, so the preview is the RENDERING under the
> THUMBNAIL, not the first RENDERING.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
