[
https://issues.apache.org/jira/browse/TIKA-4852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18109395#comment-18109395
]
ASF GitHub Bot commented on TIKA-4852:
--------------------------------------
dschmidt opened a new pull request, #3093:
URL: https://github.com/apache/tika/pull/3093
EpubParser emitted every image as an untyped embedded document, so a client
had no way to tell the cover from the other images. The OPF names it: EPUB 3
with the `cover-image` property on the manifest item, EPUB 2 with `<meta
name="cover" content="<item id>"/>`. The parser now resolves the cover
(property first, meta as fallback) and emits that image as the THUMBNAIL
embedded document, like the preview image of the other container formats. Both
fixtures cover one of the two ways.
https://issues.apache.org/jira/browse/TIKA-4852
> EpubParser: mark the cover image as a THUMBNAIL embedded resource
> -----------------------------------------------------------------
>
> Key: TIKA-4852
> URL: https://issues.apache.org/jira/browse/TIKA-4852
> Project: Tika
> Issue Type: Improvement
> Reporter: Dominik Schmidt
> Priority: Major
>
> EpubParser emits every image of the package as an untyped embedded document,
> in manifest order. The OPF names the cover, though: EPUB 3 via
> properties="cover-image" on the manifest item, EPUB 2 via <meta name="cover"
> content="<item id>"/>. Neither is read (OPFParser has no notion of a cover),
> so a client that wants the representative image of an EPUB has to guess.
> Proposal: resolve the cover item from the OPF (properties first, then the
> meta fallback) and emit it with tk:embedded-resource-type=THUMBNAIL, like the
> preview image of the other container formats (ODF, OOXML, iWork, GeoGebra,
> audio cover art as of TIKA-4850). Other images keep their current handling.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
