[
https://issues.apache.org/jira/browse/TIKA-4856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18109534#comment-18109534
]
Dominik Schmidt commented on TIKA-4856:
---------------------------------------
While I still think this endpoint could be useful, I'm thinking it needs more
concept behind it.
What I would like to have in OpenCloud:
- in the thumbnail service: just extract the embedded/rendered/whatever file I
can use as thumbnail
- in the search/index service: retrieve thumbnails metadata and original file
metadata in one request (using /rmeta)
The second one mostly works today: `/rmeta` already lists the thumbnail as an
embedded document with its type and, for raster images, its dimensions. What I
cannot get easily from `/rmeta` is the same view the thumbnail endpoint has:
the first PDF page rendered, the EMF/WMF thumbnail of an Office file rendered
(and only that one, not every picture in the document). Rebuilding that parse
context on the client means knowing the component names and keeping them in
sync with whatever `/unpack/thumbnail` does, and I want the dimensions in the
index to be the ones the thumbnail service will later produce.
So maybe the concept is not the endpoint but the defaults behind it: a
well-defined set of "thumbnail defaults" (first page rendered at 96 dpi, only
the THUMBNAIL metafile rendered) that lives in one place in tika-server, can be
overridden globally in the server config with the same parse-context JSON a
request would send, and is applied by a switch on the existing endpoints
(`/rmeta?thumbnails=true`, same for `/unpack` and `/unpack/all`), with the
request config still winning over both. `/unpack/thumbnail` would then be that
switch plus what only makes sense there (no text extraction, no OCR), picking
the thumbnail and returning it as JSON. It is not a general preset mechanism,
which I am not sure is needed; it is one named set of defaults for one common
question.
Two smaller things that fell out of this: the rendering of a THUMBNAIL should
itself be a THUMBNAIL rather than a RENDERING, so clients can filter on one
type (I would change that in #3095), and the EMF/WMF parsers could report the
metafile's size even without rendering.
What do you think?
> /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
> Priority: Major
>
> 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)
