PdfSharp fails to import a jpeg file - MoveToNextHeader moves over EOF

[jaku-soft]

IssueSubmissionTemplate attached

Issue happens during ImageImporterJpeg.ImportImage.
The jpeg file used could be opended by many image viewers and also some online jpeg validation tools found no problems in it.

            // MoveToNextHeader moves to the following positions:
            // 2      Blocklength: 16       Header: 0xFFE0
            // 20     Blocklength: 67       Header: 0xFFDB
            // 89     Blocklength: 67       Header: 0xFFDB
            // 158    Blocklength: 17       Header: 0xFFC0
            // 177    Blocklength: 30       Header: 0xFFC4
            // 209    Blocklength: 47       Header: 0xFFC4
            // 258    Blocklength: 20       Header: 0xFFC4
            // 280    Blocklength: 20       Header: 0xFFC4
            // 302    Blocklength: 12       Header: 0xFFDA
            // 316    Blocklength: 32540    Header: 0xFF00
            // 32858 but FileStream.Length is 29912
            // In TestColorFormatHeader the code tries to read a Word from that last position and failed.

Issue.zip

[Phil-oops]

It seems there is something wrong with your file. you can see it in the last reading Block. it jumps from 12-60 to 32540. If i head to guess an take a look on the "TestColorFormatHeader" message, I would assume that you or someone else tried to change something in this file and made a mistake at it.(i suggest you meant the picture at /src/pdfsharp/src/issuesubmission/iäissue.jpg) another thing that made me suspicious is the fact that this is a ~100k Pixel file (850×110 px) and needs a space of 30kb. on my Phone An actual Screenshot from a textfile is saved with 3MP (3.000.000 Pixel) and just needs 60kb space.
ps.: reading and showing an image ist totally different as converting and changing it. especially if the internal state is corrupted and there aren't valid checksums anymore.

[jaku-soft]

The jpg is created from a tiff file (containing a scan of a document on paper) with 100 % quality using SkiaSharp.
The resulting size is not important to us, because it is small enough for our use cases.

As written before, I had checked the image file with an online tool for errors, but it was reported as OK.
I also checked the file format again using a hex viewer against the jfif specification and it still seems to be correct to me.
What I found instead is, that you do not handle 0xFF00 and 0xFFFF words correctly.
A 0xFF may occur in the data and is then followed by a 0x00. Assuming that a 0xFF00 is followed by a block size word is incorrect, because this is not a valid segment marker.
There might be also multiple 0xFF in a jpeg file, but a 0xFFFF is also not a valid segment marker and should be ignored.

After the Start of Scan Segment Marker at Position 302 with blocksize 12 there is only image data until the 0xFFD9 at the EOF.
So, the 0xFF00 at position 316 is not a valid header and should be ignored.

Therefore I suggest to change the MoveToNextHeader method in ImageImporterJpeg from

private bool MoveToNextHeader(StreamReaderHelper stream) { int word = stream.GetWord(2, bigEndian: true); byte @byte = stream.GetByte(0); int byte2 = stream.GetByte(1); if (@byte == byte.MaxValue) { switch (byte2) { case 217: return false; case 1: case 208: case 209: case 210: case 211: case 212: case 213: case 214: case 215: stream.CurrentOffset += 2; return true; default: stream.CurrentOffset += 2 + word; return true; } } return false; }

to

private bool MoveToNextHeader(StreamReaderHelper stream) { int word = stream.GetWord(2, bigEndian: true); byte @byte = stream.GetByte(0); int byte2 = stream.GetByte(1); if (@byte == byte.MaxValue) { switch (byte2) { case 217: return false; **case 0:** case 1: case 208: case 209: case 210: case 211: case 212: case 213: case 214: case 215: stream.CurrentOffset += 2; return true; **case 255: stream.CurrentOffset += 1; return true;** default: stream.CurrentOffset += 2 + word; return true; } } return false; }

With this change I was able to successfully create a PDF with taht image (see attachment of this post).

Thanks in advance for your help.

IssueTemplate-WIN-CORE-6.0-B57B0BFD38_temp.pdf

[ThomasHoevel]

See #309 and #310

[ThomasHoevel]

Issue is fixed with PDFsharp version 6.2.4, coming in 2026.