TIKA-4856 presets

[tballison]

Thanks for your contribution to Apache Tika! Your help is appreciated!

Before opening the pull request, please verify that

• there is an open issue on the Tika issue tracker which describes the problem or the improvement. We cannot accept pull requests without an issue because the change wouldn't be listed in the release notes.
• the issue ID (TIKA-XXXX)
  • is referenced in the title of the pull request
  • and placed in front of your commit messages surrounded by square brackets ([TIKA-XXXX] Issue or pull request title)
• commits are squashed into a single one (or few commits for larger changes)
• Tika builds and unit tests pass with ./mvnw clean install (clean test alone cannot resolve the pipes plugin zips)
• if you used a generative AI tool: follow the ASF Generative Tooling Guidance (Generated-by: <tool> in the commit message), and consider running the pre-flight in .skills/devs/pr-review/SKILL.md — fix what it finds; don't paste its report here
• there should be no conflicts when merging the pull request branch into the recent main branch. If there are conflicts, please try to rebase the pull request branch on top of a freshly pulled main branch
• if you add new module that downstream users will depend upon add it to relevant group in tika-bom/pom.xml.

We will be able to faster integrate your pull request if these conditions are met. If you have any questions how to fix your problem or about using Tika in general, please sign up for the Tika mailing list. Thanks!

[tballison]

First draft. @dschmidt wdyt?

[dschmidt]

My agent was a bit quick to post a response I didn't want him to, sorry about that. Here's my handwritten response:

I like this a lot - it feels way more natural than the thumbnails specific config: no allowPerRequestConfig, content resolved worker side, and a path a proxy can filter on.

Just one remark for the UnpackSelector discussed in my PR (not because it's part of this, but because it's the other half of the desired functionality):
the select function has no lookahead, so we can't decide between two THUMBNAIL files. So for example when we have an embedded .emf file and its rendering, with this API we can't know which to pick. We could make the rendering the only thumbnail and mark the original file as INLINE/ATTACHMENT, but then the resource type depends on the request parameters which is kinda weird.

P.S.: I'm happy to provide the maxRenderedPages features in a separate standalone PR (or you incorporate it from my PR, however you like)

[tballison]

Can we filter on type and mime?

 "thumbnail": {
    "standard-unpack-selector": {
      "includeEmbeddedResourceTypes": ["THUMBNAIL", "RENDERING"],
      "excludeMimeTypes": ["image/emf", "image/x-emf", "image/wmf", "image/x-wmf"]
    },
    "... renderer/enricher config ..."
  }

[dschmidt]

Can we filter on type and mime?

 "thumbnail": {
    "standard-unpack-selector": {
      "includeEmbeddedResourceTypes": ["THUMBNAIL", "RENDERING"],
      "excludeMimeTypes": ["image/emf", "image/x-emf", "image/wmf", "image/x-wmf"]
    },
    "... renderer/enricher config ..."
  }

Ah, yeah, why not?! Sounds good :)

I don't see when I (or anyone else) would ever want those weird windows vector graphics ...

[dschmidt]

but I think the thumbnail preset should only contain the THUMBNAIL resource type, not rendering... in my recent work I tried to make sure that renderings of the thumbnail also have the type THUMBNAIL. So we can differentiate it from other renderings

[tballison]

Y, makes sense.

Unrelated -- I'm getting uncomfortable with THUMBNAIL vs RENDERING. One should be the thing actually in the document, and the rendering is something derived. I think you added a metadata key to distinguish, but it doesn't sit well. And yet there should be a "USE AS THUMBNAIL" flag for your use case, which I'm sure others have.

My 🤖 thinks it is fine, but.... wdyt?

[dschmidt]

This PR or the THUMBNAIL vs RENDERING situation?

THUMBNAIL vs RENDERING: not sure what the right approach here is ... they are two separate dimensions really.
Something can be the thumbnail and be rendered 🤷🏻
A new type THUMBNAIL_RENDERING sounds clumsy as well, I don't know

Regarding this PR:

This is what config would look like?

{
  "presets": {
    "thumbnails": {
      "pdf-parser": {
        "imageStrategy": "RENDER_PAGES_AT_PAGE_END",
        "maxRenderedPages": 1,
        "ocr": { "dpi": 96, "imageType": "RGB" }
      },
      "emf-parser": { "renderImage": true, "renderOnlyEmbeddedResourceTypes": ["THUMBNAIL"] },
      "wmf-parser": { "renderImage": true, "renderOnlyEmbeddedResourceTypes": ["THUMBNAIL"] }
    },
    // no idea for a good name, it should simply disable everything expesnive not needed for the thumbnail
    "thumbnails-no-ocr": {
      "pdf-parser": {
        "imageStrategy": "RENDER_PAGES_AT_PAGE_END",
        "maxRenderedPages": 1,
        "ocr": { "dpi": 96, "imageType": "RGB", "strategy": "NO_OCR" }
      },
      "emf-parser": { "renderImage": true, "renderOnlyEmbeddedResourceTypes": ["THUMBNAIL"] },
      "wmf-parser": { "renderImage": true, "renderOnlyEmbeddedResourceTypes": ["THUMBNAIL"] },
      "tesseract-ocr-parser": { "skipOcr": true }
    }
  }
}

Can we somehow ship this by default?

[tballison]

Y, on a separate ticket we can add defaults.

[tballison]

THUMBNAIL vs RENDERING situation?

Unrelated to this PR specifically.

[dschmidt]

Sounds good :)