Proper printing of editor output

[Garry Yao]

The current behavior for the Print command is printing the contents as we see them in the editor, not as they will be in the final output. So, anchors, flash placeholders and anything else that is editor specific will be visible in the print.
We should change the print plugin to instead print the outputted document (just like preview).

[Alfonso Martínez de Lizarrondo]

If this idea is followed I think that it could make sense to try to merge some other ideas as they are related.

There's a ticket about "preview mode" or something like that, also people request a readonly mode, so this is just the same. From that point, people can choose to print the current editor or the preview of that content.

A mode that just creates a normal iframe and populates it with the content should be enough to do all these tasks. (most toolbar buttons will be disabled in this situation)

[Garry Yao]

Bringing a new mode to the editor and introduce a triple-states button for it sounds counter-intuitive for me, the 'Print' command should simply print against the final output, in ignorance of the modes, we should not wave in the 'read only' feature here.

[Alfonso Martínez de Lizarrondo]

I don't want a triple-state button.

If I'm able to explain properly I think that you'll see what I mean:
In order to do only the Print command as you state, the code will need to create an iframe, put the correct stylesheets in the head, and add the contents of the editor to the body. When the content has been loaded (including images, flash or whatever) then the window.print will be called on that iframe. After the print has been executed, the iframe is no longer needed.

IE has an event to detect that a print has finished but not other browsers IIRC. So we can't know when it's the time to discard the iframe. We might even have to keep it forever.

If we provide a new button "Preview" that shows it in the content Area, and the Print command is still enabled, all that it would need is just like in the previous step: create an iframe, and populate it. Now the difference is that this iframe can be discarded when the user presses again the "Preview" button.

And the effect of having this "Preview" button active is that user can't edit the content, so we get another feature done at the same time: readonly mode.

I really think that the code required to implement the Preview mode is just the same than the one required to only make it possible to print the final output, and that by wrapping it properly we can get another feature done at the same time. The only difference is that in your original idea the iframe isn't "useful" and will not be shown directly to the user, but I state that by using it we give them a requested feature.

[Frederico Caldeira Knabben]

"Print" should be a single action. After all users want to print, not to go to preview and print. The problem here is understanding what users want to print in effect.

One idea would make printing through a dialog. The printing frame could be in that dialog, with a print button. The user could then have the option to decide whether to print the editor contents as is, or even print the final output results. In the second case, we may even make it possible to developers to provide a template that could be used to make it nicer (this feature could be included in the Preview command also).

Does it look good?

[Alfonso Martínez de Lizarrondo]

As you say, the problem is understanding the users. That's almost an impossible task.

So you suggest that when the user clicks on print we open a dialog and then the user prints the content of that dialog. Afterwards he closes the dialog.

Then we have the current popup with the preview and the new dialog to show the preview that will be printed. So we add a requirement in the print plugin of the preview plugin to share at least the code that generates the html of the page including any possible template system.

From that point, would it be so hard to make the preview not open a popup nor a dialog, but turn it into a new Mode of CKEditor, so it fully replaces the current iframe or textarea with a new iframe and the preview content? And then when the user presses print he prints whatever he sees on his screen.

As I said this has the extra advantage of providing a readonly mode as many people have been requesting, and I don't think that it's so much complex that whatever other option in this ticket. I'm almost tempted to write the code to verify if I'm wrong with my idea.

[Frederico Caldeira Knabben]

It's not a matter or being possible or not, and even a "preview" mode may be a wanted feature. The problem is, again, solving the "print" issue, not the preview need. Forcing having an unwanted button in the toolbar to solve the print problem is still a discussable solution.

Anyway, there is no priority for this feature right now. We can focus back on it in the proper moment in the future, reopening the discussion.

[Frederico Caldeira Knabben]

Milestone CKEditor 3.x deleted