-
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
Rendering problems on Chrome - overlapping characters and not readable letters in default view #14641
Comments
One of my clients has the same issue on Windows 11 Pro. Issue happens in Chrome as well as in electron (chromium). Seems specific to that computer. Reproduceable there, but not on other computers. |
We use an older version of pdf.js to render pdf resume's and we are seeing the same issue on Chromium browsers intermittently. What information would be useful to narrow down this issue? |
Some of our customers are using current DELL XPS 13 notebooks with Iris Graphics. They encounter the same issue with Chromium-based browsers. If you disable the hardware acceleration in Chrome the issue is gone. With Intel UHD we do not encounter any issues. No issues with AMD and NVIDIA. |
Same problem here. Verified it affects PDF.js versions from 2.8.335 to 2.14.305, and it doesn't affect version 2.7.570. |
I have the same issue and refreshing the page/canvas changes the missing fragments. The workaround I have, is to disable "Accelerated 2D canvas" in Chrome. You can check Here |
is there any acknowledgement of issue from the maintainers? We are having the same issue. Any idea when this might be fixed? |
This document looks just fine in Firefox, which is the primary development target for the PDF.js library. |
@Snuffleupagus it is a bit strange as it is actually working on PDF.js 2.7.570 and stops working on same browser version but on PDF.js 2.13.216. In our case there are multiple versions of PDF.js between but maybe others observed from what version to what they upgraded when they observed the issue. |
It is entirely possible that we started doing something that trips Chrome, especially given what @Rstyl3 mentioned regarding the problem disappearing when disabling hardware acceleration in Chrome. |
This comment was marked as off-topic.
This comment was marked as off-topic.
I'm having the same issue on Edge v106.0.1370.42 when having the setting I'm running on a Dell XPS15 9510. If I force MS Edge to use my other GPU, NVIDIA GeForce RTX 3050 Ti, the PDF looks good. The downside of using this GPU is that Power Consumption increases... But anyway, I got two workarounds with their own downsides:
But I hope that the root cause of this this will be solved. |
Hi, is there any update available to this pdf/browser bug? |
As @Snuffleupagus said in #14641 (comment), our main focus is Firefox so there are almost no chance we spend some time on this issue.
Considering the comment #14641 (comment), it's very likely a Chrome issue. |
Wow you closed it @Snuffleupagus... please than state in your documentation that you are only supporting Firefox and skip chromium based browsers. I would assume that this is a Chrome issue if it wouldn't be working in previous versions of PDF.js?!? If it is working in one version and not in newer it is than browser issue? |
Out of curiosity, did you open the pdf in Acrobat ?? The main reason is that there is only an image rendered in this pdf, and it has the property Anyway, pdf.js is still a free product, some contributors work for it for free and on their spare time. So don't hesitate to help us in using |
@calixteman - yes I opened it in Acrobat, and the view is better than in Chrome + PDF.js, I usually use FoxIt which is even better on preview. I know I can contribute and this is not about it, I know that this is free product so I don't expect support more than help from other who know this product better, and what more - your answer was super great and finally brought some light to this topic. Thank you much @calixteman for this, now you can even close it as "working as design". |
In Acrobat, there is a pref to enable image smoothing which isn't enabled by default (I just discovered it today). |
Firstly, thanks for all the detail in the responses on this thread, it's been very helpful! I had a couple of questions in regards to: #15659 Now I think if I understand it correctly - the Firefox overrides anyway the image rendered by PDF.js and adds/switches image smoothing. Conclusion is that I can now pass this information to PDF providers to switch the "interpolate" flag and than the problem should is gone.
Any other information anyone has too would be much appreciated as this is an issue I'm struggling to replicate. Only seems to be users on Dell laptops (not all of them, and not always Iris Graphics). Randomly had one on a Lenovo report the same thing too |
@joshpotterton-pagesuite from my recent experience - PDF which we use is text based, with "interpolate" flag changed the smoothing is visible as on any zoom in and zoom out the gaps in letters are filled better. |
I bought a Dell XPS laptop with an Iris Graphics card to fix this, and I was finally able to reproduce the error consistently. I think it has nothing to do with image interpolation. The problem is in the canvas text rendering, and I reproduced it on all pdf.js 3 and 2 versions (3.0.279 - 2.0.943). It happens on all Chromium-based browsers with hardware acceleration enabled (it's the default). The problem is on the ctx.fillText calls on canvas.js, and it happens on the first page render only. Re-rendering the page fixes the issue, and adding a delay on each ctx.fillText fixes it too, so it's probably some kind of race condition on the initialization. I'm still working on a definitive solution, but a workaround is to add { willReadFrequently: true } on all getContext calls both in pdf.js and pdf.worker.js to disable hardware acceleration on the Canvas. I didn't notice any significant performance impact. |
As we already said it: it's an issue in Chrome... @albertbal, if you add a In Firefox, |
I understand, and it's clearly not your fault. I'm not asking you to fix it, I'm trying to do it by myself. In any case, this is affecting a lot of users, and I wanted to add some more info here because it's where it can help the most people at the moment. Thank you for the explanation about the interpolation, I get it now. I was not trying with that PDF. It happens to any PDF with text. The compressed.tracemonkey-pldi-09.pdf for example: Yes, willReadFrequently should slow it down, but it doesn't seem to have so much impact. I know it's not a solution you could add to the library, but it's a quick fix for anyone who needs it. |
Looks like a different problem indeed, maybe we should report a new bug to Chrome? |
I was about to enter a bug in Chromium as I don't see anything exactly like it, only similar (like the aforementioned zoom bug). However I realize when submitting there it'll automatically log my PC specs, and I left the affected device at home today 🙃 I will log a new issue in 4-5 hours, when I get home from office. @stenvala I'll link the new Chromium issue tonight after I enter it, but for now it seems the most information and tracking can be done in related issue wojtekmaj/react-pdf#1010 which is still open and has an attached MR which somewhat fixes the issue (some text was fixed, but PDFs with images seem to render badly still). |
@callabr1 Did you file a new Chromium issue? |
Yes I did, sorry I didn't enter it until I was back from holiday but it's here: I'm trying to get a screen cast for them now, but my work disabled all the recording options on my device (they are locked to admin rights) - trying to get that sorted out to give a full video now :) |
A new Chromium commit from today seems to fix the issue, at least on my XPS with an Iris Xe Graphics that has the same problems with the latest stable Chrome version whereas the latest Canary build works (with hardware acceleration enabled! ). |
hmm I have the same integrated Iris Xe graphics as you but still see the issue on sites like react-pdf or pdf.js express demo pages. Shown here is my in Chrome canary with both those webapps displaying the issue and my version of canary: Am I using the wrong Chrome canary build perhaps? Additional note; we tried wojtekmaj/react-pdf#1025 (comment) internally and it seemed to of fixed the issue for the affected device. We did notice a regression where the documents flicker black when zoomed in or out, but the regression is very minor in comparison to the blotchy text on the device. |
I still have the glitches on the canary version that introduces that commit (111.0.5530.0) too. |
Maybe someone out there will find this useful... I've discovered a naive "workaround" until Chrome fixes the issue, in our PDF viewer code I called the // 5 is arbitrary, 2 works but 5 is just to be sure.
// The higher the number the slower the render (page stays white longer), 5 isn't noticable.
for (let i = 0; i < 5; i++) {
await page.proxy.render({ canvasContext: ctx, viewport }).promise;
} I came to this conclusion because I noticed when zooming in and out the document somehow fixes itself. Tested triggering auto zoom-in-out but that didn't consistently work. Then I tried to do that multiple times but no luck either - Finally tried this and seems to work out fine. |
@devalberg Thank you. It worked in my case!! |
I'm not sure where you put that code, can you help me please? Thanks in advance.- |
@pluengom It's easy. You don't have to put the same code, in my case it didn't work('await' expressions are only allowed within async functions and at the top levels of modules.). But as @devalberg said, you have to call render of pdf page multiple times. In my case it looks so: After fix: |
Many thanks for the answer. |
I don't know exactly how, but Solution with rerendering a page N times doesn't solve the problem completely. After few iterations page looks better, but still distorted in many places. Took an example from there: https://github.com/mozilla/pdf.js/blob/master/examples/components/simpleviewer.js |
@maybephilipp |
@suryaprythvi Here is an adapted version of our React code. Sorry if some syntax or vars will not work. General idea of implementation is present. import * as pdfJS from 'pdfjs-dist'
import * as pdfJSWeb from 'pdfjs-dist/web/pdf_viewer'
import 'pdfjs-dist/web/pdf_viewer.css'
const eventBus = new pdfJSWeb.EventBus();
const doc = await pdfJS.getDocument({
url: activePdf.url,
}).promise
const page = await doc.getPage(pageNum)
const origViewport = page.getViewport({ scale: 1 })
const scale = wrapperSize.width / origViewport.width
const viewport = page.getViewport({ scale })
const pageView = new pdfJSWeb.PDFPageView({
container: canvas,
id: pageNum,
scale: 1,
defaultViewport: viewport,
eventBus,
})
pageView.setPdfPage(page)
pageView.draw() Our client that did have this problem in a worst way confirmed that the bug had completely disappeared. |
Hi @Snuffleupagus and @calixteman, I believe there are two separate bugs being discussed within this ticket. In the PDF posted initially by @PawelW13i the text is blurry and does not look smooth. The PDF in this comment has chunks of letters missing and is unreadable in some places. I have a PDF where I can reproduce the initial issue reported. The issue with chunks of letters missing I cannot reproduce on my ARM Mac using Chrome. I believe I cannot reproduce this because I do not have one of the specified graphics cards mentioned on the chromium bug. I am working on a fix for the initial issue. I am able to fix the blurriness by forcing
I can achieve this by adding an Does this sound right to you all? Would you be open to a PR that adds Thanks! |
Sorry, but I'm not at all excited about that unfortunately. Please keep in mind that all options have a maintenance/support burden, and none of this applies to Firefox (which is primary development target for this library). Note that this is a bug (or possibly multiple bugs) specific to a particular combination of one browser (i.e. Google Chrome), certain graphics cards, and hardware acceleration being enabled; hence it doesn't seem entirely reasonable that we should have to "work-around" that here. |
PDF file: 0939bfa0-731d-48ca-8c0b-ea110cdcf143.pdf
Configuration:
Works fine on: Firefox - 97.0.2 (64 bity)
Problem noticed on: Chrome 99.0.4844.51 (and lower)
Steps to reproduce the problem:
What is the expected behavior? (add screenshot)
![Firefox](https://user-images.githubusercontent.com/101097553/157042983-1e9f93a3-d9ae-4823-972c-191b008728e6.png)
What went wrong? (add screenshot)
![Chrome](https://user-images.githubusercontent.com/101097553/157042980-5c09b9cc-f008-4bbb-8b58-4abd63da0444.png)
Problem was not spotted in version 2.7.570
One extra finding done recently - problem occurs on some subset of PDF's and they are coming from one "provider" - ABBY FineReader Engine 12
![abby](https://user-images.githubusercontent.com/101097553/169555036-de9776d2-63d2-4ea9-8362-4a4824a6b43e.png)
The text was updated successfully, but these errors were encountered: