Multiple pdfs on same page without iframe

[barhemo]

Is there an estimated performance or limitation for using multiple PDF viewers on the same page without iframes?

Also, I noticed you’re using id="viewer" inside the library. Please consider using more unique or namespaced IDs, or better, dont use id's at all. It took me an hour to figure out why my PDFs weren’t rendering turned out I had a parent div id="viewer", which caused conflicts. (I believe its relate to the iframe necessity)

Thanks for the great library just a suggestion to help avoid this for others.

[stephanrauh]

At the moment, I can't spend much time on the project, to I'm afraid the non-iframe solution is years away. If you're using the library in a business context, we could talk about paid consulting. You'd have to talk my boss into it, so I could work on the topic during business hours. Problem is I don't have a clue how much work is left. Maybe a week (40 hours)? My gut tells me I could solve the issue within a week of focused work, but it could also be two or three weeks, so it's difficult to make it a fixed-price project.

Be that as it may, currently I'm working on the project during my leisure time, an I guess you can imagine it's difficult to do a 40-hours job in my leisure time without neglecting my family duties.

As for your second question: yes, you're right, using id the way I do is a stupid approach. Maybe I can get away with a simple excuse: I've inherited the ids from the base project, pdf.js, and I'm unhappy about it. It's one of the reasons why the non-iframe solution doesn't work.

I like your suggestion of getting rid of the ids. However, I'm not sure I can do that easily. As you may or may not know, ngx-extended-pdf-viewer builds on top of Mozilla's pdf.js, and I want you to benefit from the progress of the base library. Every modification I do tends to backfire. After so many years I've got some practice, but it's always painful to solve all these merge conflicts. Adding insult to injury, there are changes that don't pop us as merge conflicts but still cause trouble. For example, the pdf.js teams might use the id in a new method, so Git can't detect the problem, but after replacing the ids by something else, that's an incompatibility.

I'm also reluctant to introduce breaking changes. I don't want to break anybody's CSS by replacing ids by class names (or something like this).

So my current idea is replacing every occurrence of document.getElementById('xyz') by something more specific, such as querySelector('::host xyz') - with some intelligent implementation of ::host. You know, pdf.js isn't aware of ::host, so I have to invent an alternative to Angular selectors.

Cutting a long story short: you're absolutely right, but it's not easy to follow your advice, and it's going to take a while!

[barhemo]

Thanks for the detailed reply, totally understand where you're coming from. I'm in a similar boat myself. My project is just something I'm building in my spare time, and while it might turn into something bigger down the line, right now it's just me trying to push it forward when I can.

I actually started out using ng2-pdf-viewer (it supports non-iframe rendering), but came across your library and found it really impressive. It’s clearly more powerful and has a bunch of great features.

That said, switching over would mean a lot of changes on my end, and at the moment I’d rather spend that time wrapping up the core of my project. But I’ll definitely keep your library in mind going forward, appreciate all the effort you’ve put into it, and thanks again for taking the time to reply!

[sc-mhaenel]

Hi @stephanrauh.

First of all, thanks for your work on the PDF Viewer. We originally used the n2-pdf-viewer as well but have now switched to yours.
However, we need a solution that allows us to use multiple instances of the PDF Viewer without relying on iframes.

We’re currently considering, if it’s okay with you, making the necessary modifications ourselves and then providing the changes to you in a pull request.
Do you happen to have any information on what currently causes issues with multiple instances or any other details that could help us avoid starting completely from scratch?

[stephanrauh]

Sounds good! Please split your PR into multiple smaller pull requests. That way, merging is easier, especially when I update pdf.js, and it's easier to verify that your change works. I think the bulk of the work is in the base library. The source code is here: https://github.com/stephanrauh/pdf.js. Use the "bleeding edge" branch. I think the most pressing problem is that the base library uses ids to find DOM elements. These queries must be converted: currently they search the entire DOM tree, but they must search the current PDF viewer instance only. Among other things, that means we have to pass a reference to the current DOM element of the viewer to the method getViewerConfiguration() in the file viewer.js. Maybe there's already a variable you can use, or maybe you have to add it. In total, I see 205 calls of getElementById(), plus a few other methods like getElementsByTagName().

The same applies to the TypeScript code in https://github.com/stephanrauh/ngx-extended-pdf-viewer. It also uses document.getElementById() instead of using relative queries.

Maybe there are more pitfalls - but I think that's the last huge showstopper. After that, enabling multiple viewers on a page should be simple.

One last thing: please decorate your changes of pdf.js with comments like

// #2946 modified by ngx-extended-pdf-viewer
(put your change here)
// #2946 end of modification by ngx-extended-pdf-viewer

These comments help me to merge the latest changes of pdf.js into my fork. Without these comments, it's hard to say why the source code differs.

Thanks in advance,
Stephan

[sc-mhaenel]

Thank you for the information.
I'll let you know when the changes are done :)

Best regards,
Marius