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!