[iliev-blnk]

Fixes #3567. Credit to @fuunnx for tracking down the root cause.

jay-peg's EXIF parser reads each tag ID through buffer.slice(), which returns a view for a Node Buffer, and then calls .reverse() on it for little-endian (II) data. So every decode() swaps the tag bytes in the image data in place: 12 01 (orientation) becomes 01 12.

@react-pdf/image decodes during resolution and then passes the same buffer to pdfkit. pdfkit's parseExifOrientation can't find tag 0x0112 anymore and falls back to 1. Layout has already swapped width and height for the rotated image, so the photo is drawn unrotated and stretched.

The fix decodes a copy in JPEG's constructor.

Repro

A 40×20 JPEG with little-endian EXIF orientation 6, rendered 4 times in one process, logging image.orientation from PDFDocument.prototype.openImage:

• master: 1,1,1,1 (pdfkit reads 6 from the untouched file)
• this branch: 6,6,6,6

With pdfkit 0.20.1 this hits every render, not only the later ones as in the issue. The issue was on the older @react-pdf/pdfkit. pdfkit 0.20.1's orientation parser only reads the buffer, so the IMAGE_CACHE clone proposed in the issue isn't needed anymore, and this PR doesn't copy cached buffers on every render.

Tests

packages/image/tests/jpeg.test.ts uses the fixture above. It checks that the dimensions are swapped, that the image data is unchanged after parsing, and that a second parse of the same data still reads the orientation. Without the fix, the last two tests fail. All image tests pass (55).

jay-peg could also be fixed at the source by reversing a copy of the tag bytes (Uint8Array.prototype.slice.call(tagAddress).reverse()). I'm happy to open that PR as well.

[vercel]

@iliev-blnk is attempting to deploy a commit to the diegomura Team on Vercel.

A member of the Team first needs to authorize it.