dschmidt opened a new pull request, #3309: URL: https://github.com/apache/tika/pull/3309
Follow-up to the PE icon extraction in TIKA-4936. An `.ico` holds several images of the same icon at different sizes, and a reader that takes it for a multi-page image hands out the first entry. The order a resource compiler wrote carries no meaning - Windows looks up the size it needs via `LookupIconIdFromDirectoryEx` rather than reading in order - so whoever renders the first entry gets an arbitrary size. Of the four binaries I looked at, two list their icons ascending and two descending: ``` snoretoast.exe 16x16 24x24 32x32 48x48 96x96 256x256 opencloud.exe 16x16 24x24 32x32 48x48 64x64 128x128 256x256 mfc140.dll 32x32 16x16 mfc140u.dll 32x32 16x16 ``` A thumbnailer that asks a generic image library for the extracted icon therefore renders a 16 pixel image and scales it up, even though the group carries a 1024 pixel PNG. `buildIco` now writes the entries by descending pixel count, then colour depth. The size comes from the image itself rather than from its directory entry: an entry holds one byte per side and reads 0 for 256 or above, so a 1024 pixel PNG and a 256 pixel bitmap are indistinguishable there. The images themselves are copied verbatim as before. The round-trip tests compared the rebuilt file to the `.ico` the resources were compiled from, which no longer holds byte for byte. They now compare against `-rebuilt.ico` fixtures that hold the same images in the new order, and `testLargestIconComesFirst` pins the order itself. -- 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]
