Print View #1993

Merged
merged 1 commit into from Jul 12, 2012

Conversation

Projects
None yet
4 participants
@Carreau
Member

Carreau commented Jun 20, 2012

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

This comment has been minimized.

Show comment Hide comment
@takluyver

takluyver Jun 20, 2012

Member

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?

Member

takluyver commented Jun 20, 2012

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

This comment has been minimized.

Show comment Hide comment
@Carreau

Carreau Jun 20, 2012

Member

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.

Member

Carreau commented Jun 20, 2012

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

This comment has been minimized.

Show comment Hide comment
@ellisonbg

ellisonbg Jun 20, 2012

Member

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.

Member

ellisonbg commented Jun 20, 2012

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

This comment has been minimized.

Show comment Hide comment
@Carreau

Carreau Jun 21, 2012

Member

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.

Member

Carreau commented Jun 21, 2012

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

This comment has been minimized.

Show comment Hide comment
@ellisonbg

ellisonbg Jun 22, 2012

Member

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

Member

ellisonbg commented Jun 22, 2012

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

This comment has been minimized.

Show comment Hide comment
@Carreau

Carreau Jun 24, 2012

Member

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.

Member

Carreau commented Jun 24, 2012

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 comment has been minimized.

Show comment Hide comment
@fperez

fperez Jun 25, 2012

Member

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

Member

fperez commented Jun 25, 2012

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

Allow direct print of the notebook.
this improve the current css of the print page and add css to the
classical notebook with print as target to get a better print view ant
the ability to directly print a notebook without going through the print
view
@Carreau

This comment has been minimized.

Show comment Hide comment
@Carreau

Carreau Jun 30, 2012

Member

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 ?

Member

Carreau commented Jun 30, 2012

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

This comment has been minimized.

Show comment Hide comment
@fperez

fperez Jun 30, 2012

Member

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.

Member

fperez commented Jun 30, 2012

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

This comment has been minimized.

Show comment Hide comment
@Carreau

Carreau Jun 30, 2012

Member

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.

Member

Carreau commented Jun 30, 2012

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

This comment has been minimized.

Show comment Hide comment
@ellisonbg

ellisonbg Jul 3, 2012

Member

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

Member

ellisonbg commented Jul 3, 2012

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

@Carreau

This comment has been minimized.

Show comment Hide comment
@Carreau

Carreau Jul 3, 2012

Member

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

Member

Carreau commented Jul 3, 2012

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

@Carreau

This comment has been minimized.

Show comment Hide comment
@Carreau

Carreau Jul 12, 2012

Member

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.

Member

Carreau commented Jul 12, 2012

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.

Carreau added a commit that referenced this pull request Jul 12, 2012

Merge pull request #1993 from Carreau/printview
Update print-view css, and link the print css when trying to print a notebook without going through the print view.

@Carreau Carreau merged commit 7cbe62f into ipython:master Jul 12, 2012

mattvonrocketstein pushed a commit to mattvonrocketstein/ipython that referenced this pull request Nov 3, 2014

Merge pull request #1993 from Carreau/printview
Update print-view css, and link the print css when trying to print a notebook without going through the print view.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment