You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tika.apache.org by "tballison (via GitHub)" <gi...@apache.org> on 2026/10/02 21:36:16 UTC
Re: [PR] TIKA-4937: parse ICO and CUR files for image dimensions [tika]
tballison commented on PR #3266:
URL: https://github.com/apache/tika/pull/3266#issuecomment-5961858448
from my bot. I think these make sense? Let me know what you think.
```
Must fix
1. The build CI job fails. TikaCLITest.testSupportedFormatsPartialIsCurrent reports supported-formats.adoc as stale. The later commit added image/x-icon to ICOParser.SUPPORTED_TYPES, but the partial
wasn't regenerated.
Edge cases
2. OS/2 bitmap arrays now throw (ICOParser.java:84-90). image/vnd.microsoft.icon also matches the OS/2 BA(\0… magic (tika-mimetypes.xml:6896). Those files now reach ICOParser, fail the u16 == 0 check,
and throw "Not an ICO or CUR file". Before, ImageParser found no ImageIO reader and quietly returned metadata only. It's a rare format, but it's a new exception on files that used to parse cleanly.
Fix: return early with only the content type set, or give BA its own type.
3. Negative dimensions from hostile headers. Math.abs(getIntLE(...)) on Integer.MIN_VALUE stays negative, and PNG getIntBE can come back negative. This can put e.g. tiff:ImageWidth=-2147483648 into
metadata and skew outranks. Clamp, or treat it as unreadable.
Mechanical fixes
- Icon.java: @since Apache Tika 4.1.1 should be 4.2.0. Same issue as #3263.
- No CHANGES entry. The 4.2.0 section exists, and the new .cur type, new icon: keys and the ImageParser→ICOParser switch are all user-visible.
```
--
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: dev-unsubscribe@tika.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org