Printing (physical page rendering) support

[Reinmar]

The question is whether CKEditor may support physical page layouts like MS Word or Google Docs.

The use case of such feature is clear I guess – being able to create documents for print.

The problems are quite clear as well:

• CSS has only a few features allowing control for print and they are very poorly implemented.
• Rendering a web page in the same way it would be printed is also very hard, because you need to simulate page breaks. There was a proposal for a CSS feature (CSS regions AFAIR) which would allow this but it's not yet widely supported. And even if it is, browsers are splitting content for pages (and hence regions) poorly (I saw that some are not even splitting lines correctly, so one line can end on 2 pages), so that'd still make for a very low quality of such a feature.

So, while this is an interesting feature to have, there serious technical challenges. CKEditor is focused on web content and we don't want to use canvas like Google Docs does (otherwise, we'd be duplicating GDocs functionality). We're using native DOM and it's not made for printing... yet.

[luzfcb]

I do not know if that has relationship with this issue, but just a historical reference about how Google Docs works http://web.archive.org/web/20101202060733/http://googledocs.blogspot.com/2010/05/whats-different-about-new-google-docs.html

[Reinmar]

Actually, I've just realised that I lied to you – just like the doc says, GDocs is using a custom DOM-based layout engine. That engine is controlling each word and perhaps letter separately. Obviously that gives them the power to do whatever they want as long as it's not killing the browser (in terms of performance), but it's has its serious downsides such as it's going to break miserably in uncontrolled environment, you can't style it through a stylesheet, it's not gonna work on mobiles, etc. Plus, obviously, it's a huge amount of work and tones of code.

CKEditor 5's architecture allows plugging in a different rendering engine, because it's layered and event based. But we're not planning to even try to prototype a custom layout engine at the moment. It just doesn't make sense for CKEditor, because that would mean building a very different kind of application.

[oleq]

What is possible at this moment

To start off, there are several techniques available to control the print layout of the web page:

1. Units like cm, mm or in are commonly supported in the web browsers. They help setting the paper format, e.g. div { width: 210mm; height: 297mm } renders an A4-sized <div> element.
2. CSS properties like page-break-after (also -before and -inside) can be used to control the flow of the elements in the page and, in a result, to defined pages. In CKEditor 4 the feature is offered by the Page Break plugin. I suppose, eventually it will become part of the CKEditor 5 ecosystem too.

Check out the "Document Editor" sample:

What could help us in the future

CSS Regions is a working draft, which (in theory) would give developers a very firm control over the flow of the document, especially in the context of printing and layout management.

This feature is far from being mature but I managed to create some sample in Safari anyway. Despite the broken table rendering on the second page, it shows the general potential of the regions, offering an experience similar to the native text processors like MS Word.

Unfortunately, at this moment it is available only in Safari, IE11, and Edge, where Apple implemented it partially and Microsoft limited it even more. The status of regions in Google Chrome is "No longer pursuing", which probably means that even if Google decided one day to implement it, it would probably take years anyway before developers can use it in production.

The truth is, as CKEditor developers, we're at the mercy of web browser vendors in this matter because there's no way we could provide a decent print layout editing experience unless we decide to follow the Google Docs philosophy, which means abandoning contenteditable completely in favor of a custom rendering engine. And by doing so, CKEditor would lose its web page "WYSIWYG–ness", which is quite out of question for obvious reasons.

I do really hope some day web browsers (CSS) will provide useful tools to manage printing and layouts in general and we'll be able to offer our users the best experience to work with. Sadly, there's no way to tell when would that happen, and if, given that CSS Regions Module draft have been proposed in 2011 and it's still quite unpopular.

[Reinmar]

Cleaning up old discussions. See #186.

[Reinmar]

More details: ckeditor/ckeditor5#1054 (comment)

[long-lazuli]

Sorry to interfere, but I see a relation between this issue and this ckeditor/ckeditor5#1121
With Electron, you can be sure of the rendering engine,
thus can lead to a PageBreakPlugin which turn into an <hr style='page-break-after: always' />

CSS Regions are unfortunately not a thing anymore in Webkit.
But in a single column view, we could do something similar to what Prince does, but with modern and hackable technologies.

And that would be really awesome !

(that may not be the goal of the cksource team, but this comment makes a +1 to ckeditor/ckeditor5#1121 )

[Reinmar]

The problem is that enforcing (or rather, encouraging) the browser to split a contet when printing it is one thing. CKEditor 4 allows inserting page breaks. But this is completely manual job.

What people would like to have are real page breaks in the content. Page breaks which are updated live and which are able to split things like images, tables, lists, etc. Unfortunately, without implementing a custom rendering system (which e.g. Google Docs did) that's not doable today.

So, the best way around this, currently, is implementing easily accessible preview of PDFs generated via a tool like Prince. You edit the content in CKEditor 5 in one place, press some button and you can see how the content will be printed. Then you need to get back to the editor to edit the content further. Of course, it's far from perfect, but that's the reality today.