Individual page option

[Cerabbite]

Currently, when typing, you have one infinite page. It would be nice to have the ability to see a separation between pages, kinda like Trelby does:

[Lycoon]

Page splitting in text formatting is a very challenging question and it has been something I've been investigating on for quite some time.

There is no good answer with the library TipTap (based on ProseMirror) that I'm using, as it would require to track when the height of a standard page height has been reached and creating a new editor for each page (or just giving the illusion it's split using bare CSS and keeping one editor?). In addition to that, you would still need to be careful while editing in the middle of screenplay so that each following pages get updated, etc.

In fact, I find it less distracting to have one continuous document rather than having your story split at each page change. For now, a hint of the current page is displayed next to the text. However I can understand that some people might prefer old-school page splitting display. If anyone has a clever approach to solve this, I would be glad to hear! I will let that issue open for further discussion.

[jelling]

This is something I was looking to add, as well. Reason being that page numbers are essential when working with actual productions, or at least, people used to working on productions.

[anasaijaz]

Hey Lycoon, You don't need multiple editors to add a page break. Just see how writer duet has solved this issue, You have to add a div block inside of the editor and style it to make it look like page break!

[dbousamra]

How do you know WHERE to insert this break though @anasaijaz? I.e. you don't want the user to insert this pseudo break element themselves

[Lycoon]

As @dbousamra pointed out, the tricky part is getting these page breaks positions correct through any document update. I think the most versatile (but quite anti-pattern) way is to base the model on the view. The idea is basically to check if the last screenplay node element for each page overflows it. This is trivial logic that I started implementing here.

The drawback is that we need to update the model depending on the view as we need to wait for DOM rendering to finish to decide if we need to shift DOM elements from one page to another. This is clearly an anti-pattern but whose advantages outweigh the disadvantages IMHO as it allows infinite customization of styling.

As I've started considering one page as one TipTap/ProseMirror node, content which lies within one must be shifted to another on deleting/inserting, depending on text selection, which raises quite few edge case concerns that must be addressed. I did pause development because the solution I've come up with bothered me and did not sound fun to implement.

[dbousamra]

We also need to consider what happens if you have a document 100 pages long, and you press enter on the first page: we must then calculate the height across all the nodes in the document, which sounds quite intensive on the DOM.

[Lycoon]

We also need to consider what happens if you have a document 100 pages long, and you press enter on the first page: we must then calculate the height across all the nodes in the document, which sounds quite intensive on the DOM.

Absolutely. I've noticed Celtx (and surely other screenplay editors) only updates pages that are visible to the user, which seems to be the best approach to that issue.