[ 
https://issues.apache.org/jira/browse/TIKA-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18122114#comment-18122114
 ] 

ASF GitHub Bot commented on TIKA-4937:
--------------------------------------

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.
   ```




> Extract image dimensions and entry list from ICO/CUR files
> ----------------------------------------------------------
>
>                 Key: TIKA-4937
>                 URL: https://issues.apache.org/jira/browse/TIKA-4937
>             Project: Tika
>          Issue Type: New Feature
>            Reporter: Dominik Schmidt
>            Priority: Major
>
> h3. Background
> Tika detects {{image/vnd.microsoft.icon}} (alias {{image/x-icon}}) and 
> {{ImageParser}} claims the type, but ImageIO has no ICO reader on the 
> classpath, so a {{.ico}} yields nothing beyond the content type: no 
> dimensions, no bit depth, no image count.
> Since TIKA-4936 every Windows EXE/DLL emits its icon groups as embedded 
> {{.ico}} documents (the first one typed {{THUMBNAIL}}), so an index now sees 
> plenty of .ico entries without width/height.
> h3. Proposal
> Read the ICONDIR/ICONDIRENTRY structure of {{.ico}} and {{.cur}} files 
> directly (no decoding, no new dependency) and set:
> * {{tiff:ImageWidth}} / {{tiff:ImageLength}} and {{tiff:BitsPerSample}} of 
> the largest image. Entries of 256 px are stored as 0 in the directory, and 
> the directory's width/height/bpp fields are unreliable in general, so take 
> the values from each image's header instead: the PNG IHDR for PNG-encoded 
> entries, the BITMAPINFOHEADER for BMP-encoded ones (height there is doubled 
> to include the AND mask).
> * the number of images
> * one multi-valued property listing each entry as {{WxH@bpp}} plus its 
> encoding (bmp/png), in directory order
> * for cursors ({{.cur}}, type 2 in the header): the hotspot of the largest 
> image
> No text content. Malformed files (directory beyond EOF, entry offsets outside 
> the file, count 0, unknown encoding) must not throw: emit what can be read 
> and record a warning.
> Implementation: a dedicated small parser in {{tika-parser-image-module}} for 
> {{image/vnd.microsoft.icon}} and {{image/x-win-bitmap}}, replacing the 
> {{image/x-icon}} entry in {{ImageParser}}'s supported types (which currently 
> finds no reader).
> h3. Out of scope
> * Decoding or rendering the images (the thumbnail presets keep passing the 
> .ico through as stored)
> * Animated cursors ({{.ani}}), {{RT_GROUP_CURSOR}} extraction from PE files
> h3. Acceptance criteria
> * {{tika -m}} on a .ico with 16/32 px BMP entries and a 256 px PNG entry 
> reports 256x256, 32 bpp, 3 images and the per-entry list.
> * The embedded icons of TIKA-4936's fixtures show width/height in {{/rmeta}} 
> output.
> * A .cur reports type cursor and the hotspot.
> * Truncated or corrupt .ico files yield a warning, not an exception.
> * Fixtures: {{testWindows-icons-app.ico}} / {{-doc.ico}} from TIKA-4936 plus 
> one generated .cur.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to