Dominik Schmidt created TIKA-4856:
-------------------------------------
Summary: /unpack/thumbnail: return the document thumbnail with its
metadata
Key: TIKA-4856
URL: https://issues.apache.org/jira/browse/TIKA-4856
Project: Tika
Issue Type: New Feature
Reporter: Dominik Schmidt
With TIKA-4850 through TIKA-4855 every container format that carries a
thumbnail emits it as a THUMBNAIL embedded document, the PDF parser renders
pages as RENDERING documents, and the EMF/WMF renderer turns the vector
thumbnails of Office documents into raster ones. Getting "the thumbnail of this
file" out of that still takes format knowledge on the client: the THUMBNAIL of
a Word or Excel file is an EMF/WMF whose usable form is the RENDERING
underneath it, a PDF has no THUMBNAIL but a page RENDERING, the THUMBNAIL of a
DOCX inside a ZIP is not the ZIP's, and with rendering enabled the picture of
an embedded OLE object is a RENDERING too. Plus the request config that
switches the renderers on.
Proposal: POST /unpack/thumbnail next to /unpack and /unpack/all, multipart
like them. It runs the usual forked parse in unpack mode with a fixed parse
context (PDF page 1 rendered, EMF/WMF rendered) and picks, in this order: the
raster THUMBNAIL at depth 1; the rendering of that thumbnail; the depth-1
RENDERING of PDF page 1. The endpoint extracts what the document carries; it
does not resize, convert or generate previews.
The response is JSON: the /rmeta metadata object of the selected embedded
document, and the image as base64. Thumbnails are small, so the encoding
overhead does not matter, and the caller gets type, dimensions, origin (stored
thumbnail or rendering, tk:rendering:rendered-by) and path in one round trip
without unpacking a zip. 204 when the document has no thumbnail.
{
"metadata": {
"Content-Type": "image/png",
"Content-Length": "8459",
"tiff:ImageWidth": "800",
"tiff:ImageLength": "1131",
"tk:embedded-resource-type": "RENDERING",
"tk:embedded-resource-path": "/thumbnail.emf/thumbnail.png",
"tk:embedded-depth": "2",
"tk:rendering:rendered-by": "poi-metafile-renderer",
"tk:resource-name": "thumbnail.png"
},
"image": "iVBORw0KGgoAAAANSUhEUgAA..."
}
To keep the selection rule short, the metafile renderer could give the
rendering of a THUMBNAIL the THUMBNAIL type as well (its
tk:rendering:rendered-by tells it apart), so a raster thumbnail is a THUMBNAIL
regardless of whether the document stored it as PNG or as EMF.
What do you think?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
