Print View

[Carreau]

replace 'Print view' by switching to a print 'layout' only in JS/css.

Pager/header/menubar/(...) fade away, trigger print dialog, then fade back.

The print layout is still editable, but then it makes almost sens as it is the same page as a normal page.
Is also allow to print unsaved version of the notebook, preventing sending data to get them back.

The animation are superfluous, doing a real file>print also works in hidding all the pager and menubar.

Still work in read-only mode

And we don't have to edit two templates in parallel.

[takluyver]

That sounds like a good plan. I assume the print dialog blocks execution so that it doesn't return to normal layout before the user prints?

[Carreau]

I assume the print dialog blocks execution so that it doesn't return to normal layout before the user prints?

At least on os x, yes.

[ellisonbg]

My vision for the print dialog is that over time we will move to a statically generated HTML page that is 1) completely read only and 2) completely print friendly. It should be a separate, static page that has little JavaScript and is also closely integrated with the "read only" or "published" notebook page. Because of this, I am -1 on removing the separate print dialog page. Using a static page will give us much more freedom and flexibility to tune the display to be print appropriate. This is especially the case as the notebook gets more interactive widgets whose print representations will need to be different (maybe a static image instead). In the long run, we may eventually always use a pdf for the print view, similar to how google docs works. In either case, I don't want to bing this logic into the make notebook page, it should be a separate URL and page.

[Carreau]

In the long run, I almost[*] totally agree, especially for the read-only and print view closely related. Except that the read-only view could also in a far future live sync with the real one, which the print would not.

This is a proposal for a better solution to what we have now until we have a real pdf export and print view.

The current print widget is broken enough, and does not differ enough from the editing view to be separate.

Right now the issues are :

• save in order to print which is a problem, both because
• you need back and forth to the server
• it is not what people expect
• codemirror is edittable
• codemirror is selectable which give a different print appearence to selected cell when printed
• errors thrown in the js console.

The only thing I did was bringing the current printing css into the main notebook, hide 3 more elements, and add media='print', Js is just pretty animation to show the user he won't be printing the headers and menubar. We could remove it, and remove the print entry from the js 'file' menu, the real printing action will still work better than what we have now in master.

I can add the print handler back if you wish to, or even split into 2 print options : Quick Print(mine) and Print view(current) that we can improve later...

[almost*]
I'm not sure a PDF only export is a good solution. Would it require LaTeX ? How would you provide a alternate graph for live things like flot plots ? But this is another story.

[ellisonbg]

On Thu, Jun 21, 2012 at 12:36 AM, Bussonnier Matthias
reply@reply.github.com
wrote:

In the long run, I almost[*] totally agree, especially for the read-only and print view closely related. Except that the read-only view could also in a far future live sync with the real one, which the print would not.

This is a proposal for a better solution to what we have now until we have a real pdf export and print view.

But doing a proper static HTML print page is not that much work. I
would rather put our efforts into that.

The current print  widget is broken enough, and does not differ enough from the editing view to be separate.

Right now the issues are :
 *  save in order to print which is a problem, both because
     * you need back and forth to the server
     * it is not what people expect

I know it is a hack but we can do a save and then wait for a bit
before opening the print view. Once we have a real print view, we
will still have to solve the same problem.

 * codemirror is edittable
 * codemirror is selectable which give a different print appearence to selected cell when printed
 * errors thrown in the js console.

I agree, but let's solve this for real.

The only thing I did was bringing the current printing css into the main notebook, hide 3 more elements, and add media='print', Js is just pretty animation to show the user he won't be printing the headers and menubar. We could remove it, and remove the print entry from the js 'file' menu, the real printing action will still work better than what we have now in master.

I can add the print handler back if you wish to, or even split into 2 print options : Quick Print(mine) and Print view(current) that we can improve later...

[almost*]
I'm not sure a PDF only export is a good solution. Would it require LaTeX ? How would you provide a alternate graph for live things like flot plots ? But this is another story.

We definitely want people to be able to print without latex installed.
But a basic pdf export would require it.

Cheers,

Brian

---

Reply to this email directly or view it on GitHub:
#1993 (comment)

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

[Carreau]

I know it is a hack but we can do a save and then wait for a bit
before opening the print view. Once we have a real print view, we
will still have to solve the same problem.

I just discoverd web-workers and message-channel of HTML5. But you can open two pages type in one, it is received in the other, no server involved.
We should be able to directly transfer data from one page to another as long as they comme from the same domain.
So back and-forth might not be necessary.

I'm thinking we could even make the pager detachable.

[fperez]

This looks like clearly 0.14 material to me, tagging as such.

[Carreau]

Removes javascript, just update css, and insert it in the normal notebook page with a print target to be abla to directly print the page without going through the print view.

Do not remove the current print view.

Is it better ?

[fperez]

Just to note that it seems to work fine for me and it's nice that the changes are so small. But I won't merge this without the eyes of our more JS-expert folks.

[Carreau]

I removed all the JS and rebased. It just link a css only for printing, and the print action still trigger the same page as before.

[ellisonbg]

Can you summarize what this does now? From the diff, it looks like the print css is always applied to the notebook.

[Carreau]

It apply only when someone try to print it. (media="print")

[Carreau]

As it is only minor css changes, that only hide things when someone want to print, I'm going to merge this.
But we can carry on discussing on how to handle the print view, and open another PR later.