Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Attached PDF not able View (7th page) #10880

Closed
satishreddy81 opened this issue Jun 3, 2019 · 5 comments · Fixed by #11523
Closed

Attached PDF not able View (7th page) #10880

satishreddy81 opened this issue Jun 3, 2019 · 5 comments · Fixed by #11523

Comments

@satishreddy81
Copy link

Configuration:

  • Web browser and its version: Chrome latest version
  • Operating system and its version: Windows 10
  • PDF.js version: tried in all versions
  • Is a browser extension: No

Steps to reproduce the problem:

  1. Please try to open in Browser and 7th page

What is the expected behavior? (add screenshot)

What went wrong? (add screenshot)

Link to a viewer (if hosted on a site other than mozilla.github.io/pdf.js or as Firefox/Chrome extension):

@satishreddy81
Copy link
Author

Sorry, I have uploaded file now
[
B3-T-G5-50.pdf
](url)

@THausherr
Copy link
Contributor

I thought it is #6741 but the messages in the console are different. The two images in p7 and 8 are big, but not THAT big.

@satishreddy81
Copy link
Author

Is there any solution for this yet?

@THausherr
Copy link
Contributor

I'm not part of this project, I just hang around and look at problem PDFs. #6741 does not have a solution yet, obviously. And as I wrote, it isn't sure that this is the cause.

@Snuffleupagus
Copy link
Collaborator

Snuffleupagus commented Jan 9, 2020

Pages 7 and 8 contains corrupt JPEG images, which have SOF (Start of Frame) markers with completely incorrect scanLines parameters, see excerpt below:

ffc0 0011 08ff 0028 0803 0122 0002 1101 0311 01..

As outlined in the JPEG specification, see https://www.w3.org/Graphics/JPEG/itu-t81.pdf#page=40, the scanLines value here is 0xff 0x00 => 65280 whereas the correct value would be 3712.

Trying to fix this will, most likely, require adding a fair bit of heuristics but is probably doable (although it probably won't be fast, since we'll have to parse the image twice in order to recover).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants