Add pdf viewer

[ian-r-rose]

Adds a mimerenderer extension for embedded PDFs, addressing #670

I have tested it in Firefox and Chrome for Linux. Windows tests forthcoming.

[blink1073]

I'm getting a blank div in Chrome 60.0.3112.90 on OSX 10.12.6. Firefox is working though.

[blink1073]

Weird, I tried a different PDF and it worked. I'll try a few more.

[blink1073]

I'm not sure I can see a pattern. I loaded a 158 page dissertation with equations and figures but other things do not work like http://do1.dr-chuck.com/pythonlearn/EN_us/pythonlearn.pdf.

[blink1073]

It must be a limitation of the inline src handling, this works for instance:

<iframe class="jp-PDFViewer" type="application/pdf" src="http://localhost:8890/foo/files/Python.pdf">placeholder</iframe>

But that doesn't help us when we have just the content.

[ian-r-rose]

Hmm, I am not sure how to move forward with that. I am also seeing flakiness with Chrome on Windows, especially for large pdfs (like the one you linked). Perhaps there is some limit to the buffer size of data urls?

[ellisonbg]

Can we construct an actual URL instead? I realize we already have the PDF in memory, but maybe using an actual URL would be more robust.

…

On Thu, Aug 17, 2017 at 3:07 PM, Ian Rose ***@***.***> wrote: Hmm, I am not sure how to move forward with that. I am also seeing flakiness with Chrome on Windows, especially for large pdfs (like the one you linked). Perhaps there is some limit to the buffer size of data urls? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2867 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABr0OuZ4bHTN8f_LODmIJ0WHFIAjNTnks5sZLmugaJpZM4O6mHi> .

-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

[ian-r-rose]

Perhaps we can add an URL field to the IMimeModel interface, something like

interface IMimeModel {
  readonly trusted: boolean;
  readonly data: ReadonlyJSONObject;
  readonly urls: ReadonlyJSONObject;
  readonly metadata: ReadonlyJSONObject;
  setData(options: IMimeModel.ISetDataOptions): void;
}

And we could then access the URL with something like

if (mimemodel.urls[MIME_TYPE]) {
  url = mimemodel.urls[MIME_TYPE]
} else {
  url = `data:${MIME_TYPE};base64,${data}`;
}
<embed src=url ... />

[ellisonbg]

+1! Something else we talked about was to allow a file handler to declare it doesn't need the content in the first place - that it only is going to grab the URL. That would also be helpful for other content that is loaded by URL.

…

On Thu, Aug 17, 2017 at 3:43 PM, Ian Rose ***@***.***> wrote: Perhaps we can add an URL field to the IMimeModel interface, something like interface IMimeModel { readonly trusted: boolean; readonly data: ReadonlyJSONObject; readonly urls: ReadonlyJSONObject; readonly metadata: ReadonlyJSONObject; setData(options: IMimeModel.ISetDataOptions): void; } And we could then access the URL with something like if (mimemodel.urls[MIME_TYPE]) { url = mimemodel.urls[MIME_TYPE] } else { url = `data:${MIME_TYPE};base64,${data}`; } <embed src=url ... /> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2867 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABr0JA907z8nqui0Ow2rw4MKwIv1efdks5sZMH2gaJpZM4O6mHi> .

-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

[ian-r-rose]

After some snooping around, it seems that there are typically size limits for data URIs, but they are not well documented or stable between browser versions (but a limit of around a few megabytes seems common). A more robust way of referring to larger data is to use an objectUrl, created using URL.createObjectURL()

I have switched to doing that, and in my testing this seems more robust. It works with larger PDFs on Chrome and Firefox, both with Linux and Windows. I am not able to test Mac OS at the moment. Could somebody test that for me?

If this is sufficient, the changes to the IMimeModel interface seem less pressing, though we may still want to do that for other reasons.

[ellisonbg]

Tested this locally with about a dozen different PDF files and it seems to work great. Also tested with Matplotlib. Honestly, it is amazing! The code looks solid. I am +1 with us merging and iterating, but will let others review/comment first.

[ellisonbg]

I should note that I did my tests on a Mac, latest Chrome and Firefox worked fine.

[blink1073]

Thanks!

[oschulz]

Thanks!

[davidchall]

This doesn't seem to work in Safari on my Mac (works just fine in Chrome though!)

[joshjob42]

Also doesn't work in Safari Technology Preview or the Safari for High Sierra beta, alas. Sucks for mac owners as other browsers drain the battery a lot by comparison.

[idaho-hewitts]

For PDFs opened from the Jupiter file browser, no renderer should be needed for most browsers, since they can natively render PDF files. However, the MIME type must be set properly when the file is served up as per this stack overflow article. I recently fixed a similar problem in a Python web server.

I am teaching an introductory high-school programming class using Jupyter. I have placed the textbook as a PDF alongside the Jupyter notebooks, but when I attempt to open it from the Jupyter file browser, it shows a black window. I can open the file just fine in the browser if I open it manually with File->Open. It sure would be nice for my students if they could just click on the textbook.

[sushmit86]

I am having an issue while opening pdf files, Every time I go back to the pdf tab it reverts to the first page. Seems like the pdf gets reloaded once again. Is this an expected behavior?

[ian-r-rose]

Hi @sushmit86, this is a known issue and is being tracked in #5714