TFA suggests that Xerox was offering the option of lossless JBIG2 compression but they implemented it incorrectly -- they didn't include the delta blocks that described how individual image blocks differed from canonical patterns.

Which brings up another point: How did Xerox's SW development process take place? Was it done in-house with frequent code reviews or was it outsourced to a low bidder and then thrown back over the wall with no real quality assurance process?

This isn't the kind of issue a code review would catch. Code review will find when the code isn't written to standards or doesn't look maintainable. It isn't going to catch a subtle misuse of a technique that should be valid.

That depends on what kind of code review you're doing. Code reviews intended to find bugs are very good at finding bugs that would be hard to find by testing.

the review should also be reviewing the tests, and you should really have a test if you have a standard.

> the review should also be reviewing the tests, and you should really have a test if you have a standard.

Codes reviews and unit tests aren't a substitute for QA or acceptance testing. It's great when code reviews do catch stuff like this, but that's not going to catch everything. To me this bug points to deficiencies in another part of the process.

One would have to know about this failure mode to write a test for it. Would you think to write this particular test?

I know nothing about this encoding but I would think each implementable feature of the standard should have some tests that you can implement. Maybe some sample data and then process it’s encoded counter part. I bet I am trivializing it but I would hope they are thinking twice about shoring up their process.

Who scans documents as JPEG, though?

PDF is widely more common and there are a million different ways you can write them. Including with JBIG2 images.

PDF files are often made up of JPEGs internally.