Based on https://github.com/hypothesis/h/blob/document-pdfjs/docs/internals/pdfjs.rst:
documentloaded
metadataloaded
pageremoved
Also add state properties to indicate that those events were already triggered.
/cc @csillag
I can confirm that this would make integration between PDF.js and other projects (like Hypothes.is) easier.
I like the idea, but for my purposes, instead of listening to an event, I use the PDFViewerApplication.pdfVieweronePageRendered
promise instead. Don't you think providing a nice set of promises would be better than emitting a bunch of new events?
I would like to work on this bug. So should these remain as events or should these be impelmented as promises like @speedplane suggested.
Promises are called only once and will not be suitable for "pageremoved". Also, if we want to scale and have multiple PDFs per main page, it will be useful to have 'documentloaded'/'metadataloaded' as events too.
So I've been looking aroung the code and found these locations where these can be implemented.
documentloaded
: https://github.com/mozilla/pdf.js/blob/master/web/pdf_viewer.js#L259metadataloaded
: https://github.com/mozilla/pdf.js/blob/master/web/viewer.js#L1023pageremoved
: https://github.com/mozilla/pdf.js/blob/master/web/pdf_page_view.js#L105I'm not sure if I have the right location for metadataloaded
. If someone could look over the these locations that'd be great.
Let me know the locations are okay.
from IRC:
documentloaded and metadataload shall be in https://github.com/mozilla/pdf.js/blob/master/web/viewer.js#L834
... somewhere after documentFingerprint is set
...
[pageremoved at] https://github.com/mozilla/pdf.js/blob/master/web/pdf_page_view.js#L130
My approach to pageremoved event.
https://github.com/mbbaig/pdf.js/commit/e4203d70bab321e80c80d54f4ba181d7576804b9
Need some feedback on this. Is the right approach?
Here are dcumentloaded and metadataloaded.
https://github.com/mbbaig/pdf.js/commit/58e9c0fdce8bcbdbe17669724b79209d175efd67
waiting on feedback
This looks good enough to me to open a pull request for. Make sure to remove the debug statements before doing so. After a pull request has been made, we can do a more thorough review.
If I'm reading this right, this doesn't provide a way for a page using the built-in Firefox PDF.js to determine when the PDF is done rendering (i.e. to trigger printing or the like)?
I had no idea pdf.js could be so controversial. But it does make for some
amusing friday afternoon reading.
On Fri, May 15, 2015 at 4:23 PM, Lord-of-Darkness [email protected]
wrote:
Developers and leaders of Mozilla, which are shemales ass!
Someone should hang you up in your own balls and let your dog bite his
caricature of a cock!They should then put it long as needed by the throat until he swallows
themselves in suicide!You Mozilla is... Stupid fucking pussies!
.....................................................
You can lick my penis and my golden eggs and kiss my ass son of a bitch
with a personality disorder from the depths of the abyss of hell from the
abysses of Mozilla!Fuck you and your mother you autistic son of a bitch, you will lick Putin
eggs, fascist fucking faggot!The shit out of your dog, your cat and your dirty faggot asshole mountain
goat!Suck cocks Mozilla and together go and suck Google ass full of shit!
Shit in your knee you cock suckers! And that damn Australis Chrome clone
of shit! Mozilla gay homosexual lesbian fucking bastards from hell!
....................................
Do you love the pain that you do? And to do a favour... I'm going to do
that!I kicked her so hard failure golden eggs until they are ringing and sing
you all the melodies of forward and back pain in an instant! I am the boy
Nutcracker who cracks your are crazy nutheads!And now go to the stupid shit shit cones!
....................................................................
Was it expected?Oh, Yes, that was!
A movement such as the Mozilla!
So happy that I never upgraded to Firefox 29 and beyond!
Let me tell you something Mozilla developers! If I would be still using
your latest crap-ware that really my mission would at this time to find out
where you live and then drill him often in Golden's failure until you
analyzes and understands how to threaten power users in the correct way!Without a doubt, has been said before - but may not be repeated enough...
You are...Stupid cones!
—
Reply to this email directly or view it on GitHub
https://github.com/mozilla/pdf.js/issues/5765#issuecomment-102517305.
is there an ability for viewier.html?file=<file>
to have hooks? I would like to display a loader is while the XHR is in progress and stop the loader when the XHR is done. Can this be done using just viewer.js
? Any help is appreciated!
+1
EventBus was added in #7254, we need to raise these events there
While there's now an event bus, do I read the viewer code correctly when I say that there's no way to know from the outside (e.g. an <iframe>
referring to the viewer.html
) when PDFViewerApplication
itself has finished initializing? Before it finishes there's no eventBus
property to at all...
@yurydelendik : I need to access webViewerPrint() from viewer.js to viewer.html. My scenario is i have button in the viewer.html when i click the button it needs to trigger the print event in viewer.js.
Can anyone help here.
Based on https://github.com/hypothesis/h/blob/document-pdfjs/docs/internals/pdfjs.rst:
That document is no longer available, and hence the use-cases for having the default viewer dispatch new events which are used nowhere in the code-base are difficult to justify at this point (in my opinion).
Need an event when document loaded --
documentloaded
There's already both documentinit
and documentloaded
events dispatched on the eventBus, representing when the document is ready for user-interaction respectively when the entire document has been loaded.
Need an event when metadata is loaded --
metadataloaded
This seems like a fairly specialized use-case, and it could probably be achieved by simply waiting for the documentinit
event and then manually access the metadata through e.g. the PDFViewerApplication.pdfDocument.getMetadata()
method instead.
Need an event when page is cleared (removed from the cache) --
pageremoved
There's no real substitute for such an event (which based on the "removed from the cache" part probably ought to be placed in PDFPageView.destroy
, if it were ever implemented).
Given the age of this issue, and that the use-cases might be "special", should this be closed as WONTFIX at this point?
Most helpful comment
While there's now an event bus, do I read the viewer code correctly when I say that there's no way to know from the outside (e.g. an
<iframe>
referring to theviewer.html
) whenPDFViewerApplication
itself has finished initializing? Before it finishes there's noeventBus
property to at all...