-
Notifications
You must be signed in to change notification settings - Fork 9.9k
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
[Color rendering] Bug or feature? Colors get blurred (or "smoothened"?) when very small images are scaled up #5757
Comments
Use a file hosting service, such as: Dropbox, Google Drive, Microsoft OneDrive, or similar. |
Here is the PDFs source code. It should work if you copy it from the web page into a text editor and save it as a Also pay attention that your text editor does not use Windows line endings (double-byte) -- set it up to use Unix-style EOL characters. Edit: It now occurred to me that there may be another reason that could cause a "corruption" when copying my PDF's source code into a text editor, and then saving it from there:
|
@Snuffleupagus: Is the upload of the PDF to some hosting provider still needed now? (After all, the code has only 84 lines and 3081 Bytes.) Anyway, good to know how it is supposed to work in the future. After all, I won't always have the time to create an ASCII-only PDF file for bug reports. :-) |
The PDF appears to be corrupt/invalid. If I close the PDF with Adobe Reader, it prompts to resave the file, indicating that something is wrong with the file itself. |
In my opinion (since you asked): while not strictly necessary, it would still be nice if you could do that! (As a general note: The fewer "hoops" a developer/contributor have to jump through to reproduce an issue, that better its chances of getting fixed are :-) |
Edit: It occurred to me that there may be another reason that could cause a "corruption" when copying my PDF's source code into a text editor, and then saving it from there:
|
@Snuffleupagus: You wrote
That's right -- but it also is true the other way round ;-) If you want users who report bugs and make the reports meaningful, you should also lower the bars and not ask them to jump through "hoops"! What do you think about a website which in today's times...
What makes it much worse:
So: _The fewer "hoops" a user has to jump through to submit a bug report, that better the chances of developers to get good and meaningful feedback :-)_ |
Ok, here is the link to a binary version of a PDF exhibiting the problem I described:
@Snuffleupagus: Is there any more info you need that continues to earn the @timvandermeij: happy now? (BTW, my Acrobat Pro 11.0.10 is perfectly happy with the PDF which I created through copy'n' paste from the codeblock above! And, believe me, I also tested it before I uploaded the code, and afterwards too. The mistake must have been on your side, not taking into account my specifically given hints about the EOL conventions) |
Your PDF file works fine for me. Sorry for the noise in that case. I think it is some sort of scaling problem in PDF.js. Thanks for reporting this. |
Is this still an outstanding issue? Could this issue be closed? |
Yes, this is still an issue. There is a pull request above, but it's not complete. |
The pull request above is closed since it caused some other regressions, but if anyone wants to look into this issue, it may serve as a good starting point/inspiration. |
Here are three different screenshots of PDF viewers (composed into one image) rendering the exact same file:
The PDF source code is written by myself in order to demonstrate a problem I've previously noticed with other (real life) files and provide a "minimal working example PDF".
The characteristics of this PDF:
As you can see, only Acrobat renders the 4 pixels as one would expect (IMHO). Or? (You may disagree with me and regard the way PDF.js renders it as a feature, not a bug...)
PDF.js deviates from Acrobat's rendering and prefers to show the 4 scaled-up pixels in a smoothened (if you regard it as a feature :-) or heavily blurred (if you regard it as a bug) way.
Preview.app also deviates from Acrobat -- albeit in a different way (you'd think that the image is ridden by heavy JPEG artifacts).
However, there are other open source PDF viewers which all render the file identical to Acrobat's way, with sharp edges between the pixels and uniform color for the four areas:
gs
(Ghostscriptgv
(Ghostscript-based)MuPDF
(own rendering engine)Zathura
(Poppler-based)Evince
(Poppler-based)SumatraPDF
(MuPDF-based)gv
(Ghostscript-based)Hmmm... I'm looking for a way to attach my demo PDF, but I can't find it. Maybe I re-write it to use ASCII-only stream for the image data, so I can embed it inline.
The text was updated successfully, but these errors were encountered: