dschmidt commented on PR #3118: URL: https://github.com/apache/tika/pull/3118#issuecomment-5516265156
Presets are the better mechanism, and I would drop my configuration layer entirely: `ThumbnailDefaults`, the `thumbnail-defaults` config block and the `renderThumbnails` switch all go, and a preset carries that instead. Resolving the content worker-side at config trust, without `allowPerRequestConfig`, and giving a proxy an addressable path segment are all things my version could not do. Your `thumbnail-unpack-selector` is the right home for the rest. The selection rule is Tika knowledge rather than client knowledge, and as a component it stops being a server endpoint question: `/unpack/preset/thumbnail` returns the one image and its metadata, no new route, no base64 JSON. I am happy to give up the endpoint for that. One thing to settle before I build it. `UnpackSelector.select(Metadata)` is a per-document boolean with no lookahead, but the rule is a ranking: a raster THUMBNAIL directly below the document, else the rendering under a vector THUMBNAIL, else a depth-1 RENDERING. Streaming, that becomes "the first acceptable candidate wins", which differs from the ranking whenever a lower-ranked candidate is emitted before a higher-ranked one, e.g. a rendered PDF page ahead of a stored raster thumbnail. The two look mutually exclusive in practice, since a PDF has no stored thumbnail, but that is an assumption about emission order rather than something the interface guarantees. I can verify it against the files I checked the endpoint with (doc, docx, ppt, pptx, xls, xlsx, odt, epub, ggs, pages, numbers, key, mp3, m4a, flac, ogg, pdf, nef, pef), and if it holds I would keep the selector streaming rather than widening the interface. One correction to the analysis in the table on #3096: `standard-unpack-selector`'s `includeEmbeddedResourceTypes` is not an equivalent of the selection, and my endpoint already uses it for what it does do. It decides which embedded documents are unpacked at all; it cannot say which of them is the document's thumbnail. Filtering to THUMBNAIL and RENDERING still leaves the archive case (a DOCX in a ZIP contributes its own THUMBNAIL at depth 2), the OLE2 case (the THUMBNAIL is a WMF and the usable image is the rendering below it), and the OLE-object case (with rendering on, an embedded object's picture is a RENDERING too). That is the part clients keep getting wrong. `maxRenderedPages` stays either way, and I will keep it in this PR. -- 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]
