Use #viewerContainer without position: absolute and overflow: auto

[hrst]

I'm currently testing pdf.js and stuck with the components examples such as the simpleviewer. These work great with the #viewerContainer div having position: absolute and overflow: auto.

I understand this makes a lot of sense for a setup such as the default viewer, however, I'd like to display PDFs by adding it (basically) to the main body, i.e. utilizing the main browser window scrollbar. When I remove position: absolute and overflow: auto, the viewer works but loads all pages at once (I'm assuming because it cannot correctly detect which pages are visible to the user anymore).

I also tried using the pageviewer.js example, which again works great but here I did not really find good examples on how to, after loading the first page, continue loading pages on demand when they are visible to the user (and unloading them afterwards), and so on, i.e. lots of functionality that is already perfectly implemented in the default viewer. I tried extracting the relevant parts (as I do not need 95% of the other stuff such as search, annotation, thumbnails, etc.), but this obviously got out of hand quickly and I felt as if was on the wrong path.

Is there any basic example on how to use pdf.js in a div without position: absolute and overflow: auto, and loading and unloading pages on demand as they are viewed by the user?

Any help is highly appreciated, I really tried to work with the examples and documentation but I'm stuck.

[burtonator]

I'm having the same issue... I still can't get it to auto-render on scroll and it just renders all the pages. even with overflow auto and position absolute.

[burtonator]

When using the rendering queue it doesn't render anything... even with overflow auto and position: 0

[burtonator]

If anyone has any suggestions where to start looking I'm going to try to fix this bug... It seems it only works with bot position AND overflow.

I think this has to do with BaseViewer and getVisiblePages....

[ChrisHSandN]

After getting caught out by this position: absolute|relative requirement I would like to add that if the library requires it (and will silently fail to work correctly if not set) then it becomes more than just a presentation attribute to be found in the CSS and feels like it should either:

1. Be automatically set by the pdf_viewer on initialisation
2. Be checked and an exception thrown if the position value is is not set to an acceptable value (possibly when you first try to scroll programmatically)

[timvandermeij]

@ChrisHSandN Thanks to the PR above PDF.js now throws an exception if the position is incorrect.

[Theiaz]

Any update for this issue?

I'm embedding a pdf viewer within my <main/> element. Because of absolute positioning, the calculation of the height for my <main> element does not take the displayed pdf file into account. Therefore it is not possible to push my footer underneath the pdf respectively to the bottom of the page.

Is absolute really mandatory?

[nikolas]

I am thinking I'll have to embed pdf.js in an iframe instead of directly into my React app because of this issue. It would be nicer to not have to do that, but I'll see if the iframe route works...

[emri99]

@timvandermeij The absolute requirement may be valid in some cases, however when implementing a custom solution without toolbar, this is unnecessary, produces BC break and force to use an overkill solution.

Could you consider replacing throwing exception by a warning or throwing an exception depending on an option, which can be defined to throw exception by default to ensure user is knowing the consequences ?

[Snuffleupagus]

The absolute requirement maybe valid in some cases,

It's necessary in all cases, since there's currently no way that rendering and scrolling works correctly without absolute positioning.

this is unnecessary, produces BC break and force to use an overkill solution.

As explained, it's definitely necessary. (And I don't know what BC is here, I'm guessing it's not "Before Christ" though?) It cannot really be overkill when it's currently needed for the viewer to actually work in all cases :-)

Could you consider replacing throwing exception by a warning or throwing an exception depending on an option,

The reason for adding the error was to reduce the number of issues opened about custom viewer implementations, where after some back-and-forth it turned out to be a lack of position: absolute being the culprit behind the problems. Generally speaking, it's unfortunately not sufficient to simply log a message since too many users will simply ignore those whereas an error cannot be ignored. (And we don't want to add options that are footguns.)

[emri99]

Wow ! Thanks for your reactivity !

It's necessary in all cases

Thanks for this clarification. As I tried commenting the check of absolute position for dev/test purposes and the PDF renders correctly and scroll is working properly, I naively thought this was not so much required. However, I understand that there can be bad side effects (like loading all the pages immediately).

BC stands for Backward Compatibility (in my mind ^^).

Many Thanks for your help.

[coagru]

Se seu front-end for feito em Angular, usar este parâmetro("encapsulation: ViewEncapsulation.Emulated") já resolve o problema.

Exemplo: @Component({ encapsulation: ViewEncapsulation.Emulated, selector: 'app-teste', templateUrl: './app-teste.component.html', styleUrls: ['./app-teste.scss'] })

[bernatgy]

For us (in Angular), the position: absolute approach works, and the viewer is able to load / render only visible pages.

With position: relative we have some (probably unrelated) issues with the textLayer disappearing on zoom and not even coming back. With absolute the issue has a workaround in the form of scrolling and then the textLayer reappears.

We had to locally patch this throw out to keep our workaround for the time being.

[kjartanvalur]

I have the same issue. I accidentally created a duplicate issue #15882 I cannot upgrade to a later version because of this. Is there no plan to resolve this?

[Theiaz]

Any update for this issue?

I'm embedding a pdf viewer within my <main/> element. Because of absolute positioning, the calculation of the height for my <main> element does not take the displayed pdf file into account. Therefore it is not possible to push my footer underneath the pdf respectively to the bottom of the page.

Is absolute really mandatory?

I've created a workaround with the help of JS, to push the footer to bottom.

After setting the document on the viewer I'm getting the height of the PDF container. This height is applied to a hidden container element which pushes the footer to the bottom.

Some pseudo code with tailwind styling:

 <div id="viewerContainer" class="focus:tw-outline-none tw-absolute tw-left-0">
    <div id="viewer" class="pdfViewer"></div>
  </div>
  <div id="hiddenContainer" class="tw-invisible"></div>

function pushFooterToBottom() {
   const height = viewerContainer.offsetHeight;
   hiddenContainer.style.height = `${height}px`;
};

viewer.setDocument(value);
pushFooterToBottom();

[kjartanvalur]

Hi @Theiaz and @Snuffleupagus Snuffleupagus I´m trying to get the pdf viewer to be 100% height and use the browser window scroll. See in issue https://github.com/mozilla/pdf.js/issues/15882 for a better explanation How would you accomplish that?

For example here https://stackblitz.com/edit/bootstrap-5-brshqu?file=src%2Findex.html