-
-
Notifications
You must be signed in to change notification settings - Fork 416
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Fix PDF render #1038
Fix PDF render #1038
Conversation
@fredrikekre Wanted to flag this as ready for review. :) |
Is display of PDF images well supported in Jupyter? This issue jupyter/notebook#3652 seems to indicate that it only works in certain browsers or with certain plug-ins installed. |
I think you're right in pointing out there is a bit of a file type conflict here: Per the issue you linked, browser support of PDFs is (potentially) incomplete. But Latex workflows like quarto's use case which use Jupyter to build a document (but not display it in the browser) do not work well with SVGs and require the use of the PDF format for exporting / displaying vector graphics. Right now, if you create a PDF document with R, Python, and Julia graphs via quarto, the Julia graph gets dumped out as a PNG and looks significantly pixelated, the other two languages (afaik) allow for PDF viz export and certainly lead to vector viz output in the latex PDF document. tldr ruling out support of PDFs because it does not work everywhere, perfectly, cuts out meaningful use cases for (quarto) Latex documents; R and Python allow this |
It's worth noting that you can display the PDF "manually" using I don't think it should be added by default. It has higher priority than image/xyz, which is probably unexpected for most use cases, and will also increase the notebook file sizes (Jupyter stores all different supported formats of a file in the notebook, not just one). If Quarto really want's to customize this, they can define a custom method for |
@travigd Thanks for the feedback and flagging potential downsides to this change. Can you say more about the cases in which Jupyter would actually generate multiple file formats for a given cell as a result of adding specifically My understanding (please correct): For the Plots.jl usecase, at any point in time there should only be one active backend, with one format for that backend. So only in the case that your active backend, say I can't come up with a case in which you'd see multiple outputs, and certainly in the case of the PDF plots which this PR seeks to open up as a possibility, to my knowledge you're really talking about a sort of wrapped svg, so not very large file sizes for typical cases. While it certainly would be possible to overload a function or patch IJulia, this creates other (minor?) types of unpleasantness should IJulia change the code base. |
The Jupyter format defines cell outputs as a dict that contains multiple representations of an output (e.g., plot). The frontend (e.g., jupyterlab) chooses which of the formats its want to render (so only one is shown at a time, but the various formats are present in the notebook file). IJulia tries to generate a representation for every MIME type it supports (which is what this PR is changing). This is actually not the case for Plots.jl -- it actually does override |
@travigd Thanks for the nudge to investigate this further, the Plots.jl PR JuliaPlots/Plots.jl#4188 solved the issue for Plots, so this isn't necessary. And for Makie, turns out it's a one-liner which can be done on the Quarto side: |
Is there a way to override this in
in order to output both
ℹ️ With |
Fixes #1035 alongside
PR #4188 (which has been merged)