[jira] [Commented] (TIKA-4856) /unpack/thumbnail: return the document thumbnail with its metadata

["Dominik Schmidt (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TIKA-4856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18129633#comment-18129633 ] 

Dominik Schmidt commented on TIKA-4856:
---------------------------------------

/unpack/preset/thumbnail (TIKA-4856 presets in #3118, the thumbnail catalog preset and ThumbnailUnpackSelector in #3179, maxRenderedPages in #3146). The remaining ask, activating the preset without a config file, is TIKA-4988.

> /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)