Rendering problems on Chrome - overlapping characters and not readable letters in default view

[PawelW13i]

PDF file: 0939bfa0-731d-48ca-8c0b-ea110cdcf143.pdf

Configuration:

• Web browser and its version:
  Works fine on: Firefox - 97.0.2 (64 bity)
  Problem noticed on: Chrome 99.0.4844.51 (and lower)
• Operating system: Windows
• PDF.js version: latest (currently v2.13.216)

Steps to reproduce the problem:

1. Try to open attached PDF in Chrome (and in Firefox)
2. Check the "footer" - telephone, bankgiro and other words are not fully visible on Chrome

What is the expected behavior? (add screenshot)

What went wrong? (add screenshot)

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

[tgreiser]

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.

[breezyJake]

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?

[RayHemm]

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.

[albertbal]

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.

[Rstyl3]

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

[bmrinal]

is there any acknowledgement of issue from the maintainers? We are having the same issue. Any idea when this might be fixed?

[Snuffleupagus]

This document looks just fine in Firefox, which is the primary development target for the PDF.js library.
Hence it's not clear that it's necessarily an actionable bug here, and it may very well be a browser-bug (in Google Chrome).

[PawelW13i]

@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.

[marco-c]

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.

[jwikman]

I'm having the same issue on Edge v106.0.1370.42 when having the setting Use hardware acceleration when available. enabled. Disabling that setting solves the issue, but then I have no hardware acceleration in Edge... 😕

I'm running on a Dell XPS15 9510.
Edge is using the Intel(R) UHD Graphics GPU when this happens.

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:

• Disable Hardware Acceleration in Edge
• Force Edge to use another GPU (if available)

But I hope that the root cause of this this will be solved.

[monsterfish]

Hi, is there any update available to this pdf/browser bug?

[calixteman]

As @Snuffleupagus said in #14641 (comment), our main focus is Firefox so there are almost no chance we spend some time on this issue.
But, you can either:

• file a bug on Chrome bug tracker
• or if you're sure it's a pdf.js issue or something we can easily workaround, then find someone to work on it and make a pull request.

Considering the comment #14641 (comment), it's very likely a Chrome issue.
FYI, I tested this pdf in Chrome and Safari on mac 13.0 and the rendering is ok. I tested on Windows 11, and the rendering is ok in Chrome on hdpi screen but it's far from perfect on a non-hdpi screen.
So really if the issue is because of a mix of Chrome, gpu and screen, as far as I can tell we won't fix this issue here.

[PawelW13i]

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?

[calixteman]

Out of curiosity, did you open the pdf in Acrobat ??
Because if you did, you'd have seen the result is worst in Acrobat compared to Chrome.

The main reason is that there is only an image rendered in this pdf, and it has the property Interpolate set to false (see 8.9.5.3 Image Interpolation) .
And few months ago we fixed a bug about that:
#13991
But in Firefox, image smoothing is enabled when the image is downscaled:
https://searchfox.org/mozilla-central/rev/3c194fa1d6f339036d2ec9516bd310c6ad612859/dom/canvas/CanvasRenderingContext2D.cpp#4933

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 git bisect or whatever tool in order to pinpoint a potential culprit and then we can discuss the opportunity to improve (or not) the way to render things.
And if you don't have the answers you want or you aren't happy with our answers, I'm sorry about that, but you can contribute to this project or pay some people to help, instead of just waiting and pinging us...

[PawelW13i]

@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.
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.

Thank you much @calixteman for this, now you can even close it as "working as design".

[calixteman]

In Acrobat, there is a pref to enable image smoothing which isn't enabled by default (I just discovered it today).

[joshpotterton-pagesuite]

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.

1. Would image smoothing be in reference to imageSmoothingEnabled on the canvas context?
2. When you mention the interpolate flag, wouldn't this just be for image based PDFs? I was a bit confused as the PDF posted in the OP was pretty much all text

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

[PawelW13i]

@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.
In general I think nowadays this flag in standard should be set to true :) I think most of computers are able to handle documents fast enough with smoothing - but this is not a scope here.

[albertbal]

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.

[calixteman]

As we already said it: it's an issue in Chrome...
I don't really understand why you guys want us to fix it when, really, it isn't our fault.
So please, file a bug on Chrome bug tracker and add a link here in order to be able to follow it.

@albertbal, if you add a return at the first line of showText then you'll see that the pdf is still rendered: so really what you see on your screen is an image (I'm talking of course about the pdf in #14641 (comment)).
And if you look in the pdf you'll see some 3 Tr which mean that the text rendering mode is set to 3 which means that the text is invisible.
But, afaik, hardware acceleration implies that the drawing is done on the gpu, which really should be faster that rendering on the cpu. One problem we have in pdf.js is that we're drawing letters one by one (because we don't want to let the canvas doing the layout of the strings) and possibly it induces a slowdown which causes moving data from the gpu to the cpu and then something is wrong.

In Firefox, willReadFrequently has no effect, but in the future it could be plugged in order to be able to disable to hardware acceleration.

[albertbal]

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.
I wasn't able to reproduce it with just a canvas without pdf.js yet. So it's difficult to fill a bug elsewhere.

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.

[1Jesper1]

Thank you for your attention to this matter, and that it is not a pdf.js issue, and I do see that a chrome bug has been submitted for this at https://bugs.chromium.org/p/chromium/issues/detail?id=1382692

What makes you think that the linked chromium bug is associated to this? Looks like that it is related to sometimes hiding text completely because text rendering bounds go to 0. The issue reported here seems to be more related to not rendering well pdf files where the content is raster image.

Looks like a different problem indeed, maybe we should report a new bug to Chrome?

[callabr1]

Thank you for your attention to this matter, and that it is not a pdf.js issue, and I do see that a chrome bug has been submitted for this at https://bugs.chromium.org/p/chromium/issues/detail?id=1382692

What makes you think that the linked chromium bug is associated to this? Looks like that it is related to sometimes hiding text completely because text rendering bounds go to 0. The issue reported here seems to be more related to not rendering well pdf files where the content is raster image.

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).

[1Jesper1]

@callabr1 Did you file a new Chromium issue?

[callabr1]

@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:
https://bugs.chromium.org/p/chromium/issues/detail?id=1404710

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 :)

[martin-kl]

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! ).

[callabr1]

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.

[jransonhayes]

I still have the glitches on the canary version that introduces that commit (111.0.5530.0) too.

This suggests it is a different issue

[devalberg]

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 PDFPageProxy.render multiple times which seems to make the document look correct.

// 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.

[achanizbekov]

@devalberg Thank you. It worked in my case!!

[pluengom]

@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.-

[achanizbekov]

@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:
Before fix:
var renderTask = page.render(renderContext);
renderTask.promise.then(function () {
...
});

After fix:
var renderTask = page.render(renderContext);
renderTask.promise.then(function () {
renderTask = page.render(renderContext);
renderTask.promise.then(function () {
...
});
});

[pluengom]

@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: Before fix: var renderTask = page.render(renderContext); renderTask.promise.then(function () { ... });

After fix: var renderTask = page.render(renderContext); renderTask.promise.then(function () { renderTask = page.render(renderContext); renderTask.promise.then(function () { ... }); });

Many thanks for the answer.
It worked perfectly.

[maybephilipp]

I don't know exactly how, but PDFPageView view class does work like a charm and fixes text distortion completely. I've adapted it instead of my previous solution and now it looks perfect!

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

[suryaprythvi]

I don't know exactly how, but PDFPageView view class does work like a charm and fixes text distortion completely. I've adapted it instead of my previous solution and now it looks perfect!

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
Can you provide more details on how you fixed the text distortion? I am using 2.16.105 version of pdf.js. I am facing the rendering issue with chromium browsers on certain windows machines only.
Thanks in advance

[maybephilipp]

Can you provide more details on how you fixed the text distortion? I am using 2.16.105 version of pdf.js. I am facing the rendering issue with chromium browsers on certain windows machines only.
Thanks in advance

@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.

[wmerobertson]

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 img/imgData.interpolate to be true on the following two lines in canvas.js

• https://github.com/mozilla/pdf.js/blob/master/src/display/canvas.js#L1344
• https://github.com/mozilla/pdf.js/blob/master/src/display/canvas.js#L2994

I can achieve this by adding an enableInterpolation option to defaultOption and accessing that option in canvas.js.

Does this sound right to you all? Would you be open to a PR that adds enableInterpolation as an option that consumers could toggle?

Thanks!

[Snuffleupagus]

Would you be open to a PR that adds enableInterpolation as an option that consumers could toggle?

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.