mrdevel2002-ui opened a new pull request, #3559: URL: https://github.com/apache/tika/pull/3559
`ToMarkdownContentHandler.appendMath` writes the text of any `<span class="math">` as a raw commonmark `HtmlInline`, so TeX keeps its backslashes (TIKA-5011). The handler goes by the class name alone, and the text is document content. `PDFMarkedContent2XHTML` writes a tagged PDF's custom structure type in inline context as `<span class="<type>">`, so a page whose `Em` element holds a `Math` element with the text `<img src=x onerror=alert(document.domain)>` parses, with the default config, to `Invoice total: *<img src=x onerror=alert(document.domain)>*` in markdown, while the XHTML of the same parse has `<img ...>`. Markdown is the default handler for `/rmeta` and `BasicContentHandlerFactory`, and renderers that pass raw HTML through (commonmark-java's default, markdown-it with `html: true`, pandoc) turn that into script in whatever displays the extracted text. VLM OCR output reaches the same path through `MarkdownToXHTMLEmitter`'s math spans. A `<` at the end of the span als o joins the text after it, so `<` followed by `img src=y onerror=...>` becomes a tag too. The fix puts a space after every `<` in the math literal that isn't already followed by whitespace, the trailing one included. TeX ignores whitespace in math mode, so `$a<b$` written as `$a< b$` renders the same in math-aware readers, and in CommonMark a `<` followed by a space can't start an HTML tag, comment, HTML block or autolink. I considered escaping `<` as `<`, but readers that take math source verbatim, such as pandoc's `tex_math_dollars`, would hand the entity to TeX. The cost is a visible space after `<` in readers without math support. This is a separate path from #2891, which escaped link, image and table text in the old string writer; the raw passthrough for math came later. `testMathSpanCannotOpenRawHtml` renders the handler's output with commonmark's `HtmlRenderer`. On main it fails with both `<img>` tags raw in the HTML, and with the fix it passes. A throwaway test with `TaggedPdfBuilder` in the PDF module gave the end-to-end output above on main and `*< img src=x onerror=alert(document.domain)>*` with the fix. `./mvnw clean apache-rat:check install -Pci -pl tika-core` (1473 tests, checkstyle, spotless, forbidden-apis) is green on JDK 21, and `MarkdownToXHTMLEmitterTest` in tika-vlm (41 tests) passes. - [ ] open issue on the Tika issue tracker: not filed yet, happy to open one or have it linked - [ ] issue ID in the PR title and commit message: pending the issue above - [x] commits are squashed into a single one - [x] Tika builds and unit tests pass with `./mvnw clean install` (affected module) - [x] generative AI tool used: `Generated-by: Claude Code. - [x] no conflicts with the recent `main` branch - [ ] new downstream module added to `tika-bom/pom.xml`: not applicable -- 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]
