search

stephanrauh / ngx-extended-pdf-viewer

A full-blown PDF viewer for Angular 16, 17, and beyond
https://pdfviewer.net
Apache License 2.0
474 stars 182 forks source link

Text rendering issue in pdf viewer #1659

Closed robotestyukon closed 1 year ago

robotestyukon commented 1 year ago

Hi, using ngx-extended pdf viewer(14.0.5) in angular application where the text in pdf is getting blurred or sometimes not rendering properly in chromium browsers(chrome,edge,etc) attached the screenshot and the pdf url https://moneyandme.pgimindiamf.com/api/v1/portal/pdf/PDF_2118943213 for reference. image

url to access : https://moneyandme.pgimindiamf.com/household-budget/articles/4-Steps-to-Financial-Wellbeing

Please provide solution for this.

Originally posted by @robotestyukon in https://github.com/stephanrauh/ngx-extended-pdf-viewer/issues/275#issuecomment-1401527755

stephanrauh commented 1 year ago

I've been using your document for a couple of days now. There seems to be something wrong with the document. It renders slowly, and Chrome complains about an inefficient use of the internal API. But until now, I haven't seen any layout glitch.

robotestyukon commented 1 year ago

Checked by updating to v16.0.0-alpha.5, facing same issue only in windows(chrome) for some pdf's, working fine in firefox (Windows), Mac (chrome,safari,firefox).

Note: when viewed the pdf directly in chrome browser (windows), it renders properly. Facing issue when only viewed in the plugin

stephanrauh commented 1 year ago

Oh. Windows. That explains why I didn't see it. It's also a strong hint that the bug hasn't got anything to do with ngx-extended-pdf-viewer itself. Instead, I suspect it's a problem of the base library, pdf.js.

Can you verify if the bug occurs on https://mozilla.github.io/pdf.js/web/viewer.html, please? If so, you'll need to report the bug at Mozilla's bug tracker. I'm not familiar with the rendering engine, so I can't help you.

Unfortunately, it's always possible that I introduced a bug to my fork of pdf.js. That'd be ugly: looking for a merge conflict in unfamiliar code isn't fun. But I'm positive you can reproduce the problem on https://mozilla.github.io/pdf.js/web/viewer.html.

robotestyukon commented 1 year ago

@stephanrauh https://mozilla.github.io/pdf.js/web/viewer.html this link is opening a pdf file, should we try by rendering this pdf in ngx-extended-pdf-viewer?

stephanrauh commented 1 year ago

@robotestyukon The other way round. https://mozilla.github.io/pdf.js/web/viewer.html is the showcase of Mozilla's PDF viewer. That viewer is also the built-in PDF viewer of Firefox, so it's easy to get confused. But if you open the file in Chrome, you'll spot the differences between the built-in viewer and the showcase.

As you may or may not know, ngx-extended-pdf-viewer doesn't implement a PDF viewer. It's just a wrapper around Mozilla's viewer (called pdf.js). So a fair share of bugs reported to me are bugs of the base viewer and need to be address by the pdf.js team.

I want you to open your file on https://mozilla.github.io/pdf.js/web/viewer.html (for example, by clicking the upload button). I expect the layout glitches to show there, too. If so, please open a bug ticket on https://github.com/mozilla/pdf.js/issues.

robotestyukon commented 1 year ago

Thanks @stephanrauh, checked in https://mozilla.github.io/pdf.js/web/viewer.html, some texts were not rendering properly.

stephanrauh commented 1 year ago

I'm sorry you've run into Snuffleupagus. He's got a long record of closing issues within minutes. I've read the issue he's pointed you to, and I wonder if I should add an option to set the willReadFrequently option. I'm reluctant because I don't see how disabling the hardware renderer improves performance, but it's worth a try.

robotestyukon commented 1 year ago

I'm sorry you've run into Snuffleupagus. He's got a long record of closing issues within minutes. I've read the issue he's pointed you to, and I wonder if I should add an option to set the willReadFrequently option. I'm reluctant because I don't see how disabling the hardware renderer improves performance, but it's worth a try.

@stephanrauh this may help us. I tried disabling hardware acceleration on chromium browsers and pdf was rendering properly Please let us know once willReadFrequently is updated

robotestyukon commented 1 year ago

@stephanrauh any update??

stephanrauh commented 1 year ago

Currently, I'm busy preparing a conference talk, so I can't report any progress yet. I'm propably going to continue working on ngx-extended-pdf-viewer at the end of next week.

robotestyukon commented 1 year ago

Currently, I'm busy preparing a conference talk, so I can't report any progress yet. I'm propably going to continue working on ngx-extended-pdf-viewer at the end of next week.

Hi @stephanrauh , Please let us know once implemented.

stephanrauh commented 1 year ago

Thanks for reminding me! Please update to version 16.2.3 and set the new flag pdfDefaultOptions.activateWillReadFrequentlyFlag=true in the constructor of your component. You'll also need to activate the bleeding-edge branch (see https://pdfviewer.net/extended-pdf-viewer/pdfjs-versions).

My short test didn't reveal any problems, but this is one of the features I want to be able to roll back without traces if they don't work. I'm positive it will work, but I can't test the library with Windows, so I need your help. Please run a test and tell me about it.

Thanks in advance, Stephan

robotestyukon commented 1 year ago

Thanks for reminding me! Please update to version 16.2.3 and set the new flag pdfDefaultOptions.activateWillReadFrequentlyFlag=true in the constructor of your component. You'll also need to activate the bleeding-edge branch (see https://pdfviewer.net/extended-pdf-viewer/pdfjs-versions).

My short test didn't reveal any problems, but this is one of the features I want to be able to roll back without traces if they don't work. I'm positive it will work, but I can't test the library with Windows, so I need your help. Please run a test and tell me about it.

Thanks in advance, Stephan

Thanks @stephanrauh for the input.

I followed the above mentioned steps by adding activateWillReadFrequentlyFlag flag by updating to v16.2.3. On adding pdfDefaultOptions.assetsFolder = 'bleeding-edge' in the constructor for testing purpose, pdf was not rendering(getting blank screen) image

Tried uploading the pdf to https://pdfviewer.net/extended-pdf-viewer/pdfjs-versions, still facing the same issue(broken text) in chromium browser. attaching screenshot for reference image.

stephanrauh commented 1 year ago

Did you include the bleeding-edge folder in the angular.json? Otherwise, there's no JavaScript to execute.

Which error message does your console show?

BTW, I didn't update the showcase yet, so rendering issues aren't surprising.

robotestyukon commented 1 year ago

Did you include the bleeding-edge folder in the angular.json? Otherwise, there's no JavaScript to execute.

Which error message does your console show?

BTW, I didn't update the showcase yet, so rendering issues aren't surprising.

@stephanrauh Yes, included in angular.json, attached the screenshots scenario 1: image image

scenario 2 image image

stephanrauh commented 1 year ago

You get a blank screen? That's strange. To double-check it, I ran a test on my employer's PC. I've created a new project (ng new demo), added ngx-extended-pdf-viewer (ng add ngx-extended-pdf-viewer), said "no" when I was asked if I want to use the stable version, activated the demo component, and added your PDF file.

Now I can confirm that

However, I still believe you should reach out to the author of the PDF file. The PDF renders surprisingly slow, so I suspect there's something wrong with the PDF file. I can't tell you what's wrong, because I'm no expert on authoring PDF files, but my gut feeling says it's a simple file and it should render within milliseconds.

stephanrauh commented 1 year ago

I just saw your screenshots. They weren't part of the email GitHub sends me, so my answer isn't as helpful as it should be. Your screenshots indicate that you replaced the section of the angular.json copying the assets folder by a section copying the bleeding-edge folder. This didn't work. Here's my theory what's going wrong:

I hope that helps! If it doesn't, don't hesitate to tell me. I'm going to close this ticket soon, but I'm still listening to this channel.

Best regards, Stephan

robotestyukon commented 1 year ago

@stephanrauh I rechecked by adding pdfDefaultOptions.assetsFolder = 'bleeding-edge' in the constructor as well, pdf is rendering properly.

I have small confusion, Currently I have included only below snippet in angular.json(did not included assets in angular.json). Is it enough or any modification to be done for stable release.

 {
                "glob": "**/*",
                "input": "node_modules/ngx-extended-pdf-viewer/bleeding-edge/",
                "output": "/bleeding-edge/"
  }
stephanrauh commented 1 year ago

Yesterday I've copied the modifications to the stable branch and published version 16.2.4. So you can go back to the stable branch now. You can safely remove the bleeding-edge glob and the line pdfDefaultOptions.assetsFolder = 'bleeding-edge' after updating.

The additional glob is only neccessary if you want to test the bleeding-edge branch.

However, if you want to use the bleeding-edge branch, you need both globs. That's because the locales and the fonts are always loaded from the assets folder. Here you can see the content of the folders:

https://www.npmjs.com/package/ngx-extended-pdf-viewer?activeTab=explore