Support pagination #125

zhouhao27 · 2023-04-11T01:28:45Z

zhouhao27
Apr 11, 2023

I replace the <body> element in html with the following code to support pagination. The pagination is working well.

<body style="overflow:-webkit-paged-x; overflow:paged-x;">

But there is a problem. The even page can't be edit. Please refer to my video.

demo.mov

What could be the problem? Any idea? Thanks.

stevengharris · 2023-04-11T04:58:41Z

stevengharris
Apr 11, 2023
Maintainer

Hmm, I don't have any experience with pagination at all, so I'm not really sure where to begin. I guess in the absence of a reason to the contrary, I might have done the styling on the contenteditable editor div, but maybe that is just wrong. I also noticed this article which might have some useful information. I will try to poke around at it a bit, but I think this is pretty much beyond the scope of what the MarkupEditor is meant to be. Along those lines, I even wonder if it's not more practical to use the height of the document to create different MarkupWKWebViews on-demand on the Swift side and combine the separate HTML at save time.

0 replies

stevengharris · 2023-04-11T20:39:37Z

stevengharris
Apr 11, 2023
Maintainer

It's interesting. What I see is that the caret insertion point is shown incorrectly. When you open the demo, the SelectionState reflects the position being at the beginning of the document, in <h1>Welcome to the MarkupEditor</h1>. You can see the paragraph style show up as "Header 1". Changing the style to "Normal" results in it being changed to <p>Welcome to the MarkupEditor</p>. However, the blue caret/insertion point is visually on the 2nd page. My suspicion is that there are some base WKWebView issues with style="overflow:-webkit-paged-x", which is where I would recommend you start on debugging it. I'd strip pretty much everything out of a vanilla WKWebView on a contenteditable DIV within the body styled as you specified and see if it behaves like non-paginated version when edited. I'm not doing anything directly with the insertion point other than specifying the selection using a range like this...

const sel = document.getSelection();
sel.removeAllRanges();
sel.addRange(range);

Occasionally the insertion point disappears if range is invalid or there is some timing issue, but I've never seen it show up on the screen where it's not supposed to be. Plus, the toolbar is reflecting what the document state is for the selection, and it's doing what it's supposed to be doing correctly based on that selection, even though it shows the blue caret/insertion point on the 2nd page. So, I'd wager there are deeper WebKit or WKWebView (or even perhaps Catalyst) issues here. I am not planning on debugging this further myself.

0 replies

zhouhao27 · 2023-04-12T01:56:15Z

zhouhao27
Apr 12, 2023
Author

Hmm, I don't have any experience with pagination at all, so I'm not really sure where to begin. I guess in the absence of a reason to the contrary, I might have done the styling on the contenteditable editor div, but maybe that is just wrong. I also noticed this article which might have some useful information. I will try to poke around at it a bit, but I think this is pretty much beyond the scope of what the MarkupEditor is meant to be. Along those lines, I even wonder if it's not more practical to use the height of the document to create different MarkupWKWebViews on-demand on the Swift side and combine the separate HTML at save time.

Thanks for your suggestion. I'm wondering how to get the current height of the document? We can divide it by the content height to get the number of pages then. Then only thing is we need to calculate it in real time.

I think some ePub application doing this pretty well.

0 replies

stevengharris · 2023-04-12T04:29:44Z

stevengharris
Apr 12, 2023
Maintainer

One way you can do it is to implement func markup(_ view: MarkupWKWebView, heightDidChange height: Int) in your MarkupDelegate and then just use the height it passes to you whenever the height changes. This will happen after the document loads, as you type, and as images load.

If you want to determine the height from the MarkupWKWebView directly, you can use updateHeight and the handler will execute with the height, as in:

webView.updateHeight { height in
...
}

0 replies

zhouhao27 · 2023-04-12T06:14:23Z

zhouhao27
Apr 12, 2023
Author

One way you can do it is to implement func markup(_ view: MarkupWKWebView, heightDidChange height: Int) in your MarkupDelegate and then just use the height it passes to you whenever the height changes. This will happen after the document loads, as you type, and as images load.

The delegate works. Then need to figure it out how to split the html into multiple pages. No idea how to do it now. Do you have any suggestion?

0 replies

stevengharris · 2023-04-12T16:21:24Z

stevengharris
Apr 12, 2023
Maintainer

My initial thought was to keep the full doc in a non-visible MarkupWKWebView, and present a single page extracted from it (as an HTML template like cut/paste does in markup.js) that you are actually editing. Then you could push the changes to the full doc when needed. As with most initial thoughts, this ends up being complicated. It's complicated to split pages in lists, etc to get this single page to edit, and it will be complicated to recombine them when needed. I know it's complicated because I had to do a lot of that kind of thing for the special handling of Enter in the MarkupEditor, for cut/paste, undo/redo, etc, and I suspect a lot of similar work would have to be done here, too. Hmm.

All this mainly makes me wish the style="overflow:-webkit-paged-x" just worked, and would probably push me more toward trying to debug that with the contenteditable in the standard WKWebView first. One of the good things about this approach to doing a WYSIWYG editor is that you can take advantage of all the investment in WebKit for free, so it's kind of tragic if you can't do that here and end up getting pushed into re-implementing a lot of what it already does. Still, since the only conversations about pagination that come up in searches seem to be WebKit-specific and 7-8 years old, it doesn't give me a lot of confidence it was ever fully baked.

I will think about it some more. Maybe there is a way to suppress scrolling and then use some scroll position magic that presents the document in a kind of page-at-a-time way? If so, then the height change could be used to trigger any needed changes to the scroll positions that corresponded to pages.

0 replies

zhouhao27 · 2023-04-13T01:03:45Z

zhouhao27
Apr 13, 2023
Author

Thanks for your reply and patience. I'm not familiar with JS part. Do you have any suggestion on this topic? If there are any document regarding with this?

0 replies

stevengharris · 2023-04-14T16:45:01Z

stevengharris
Apr 14, 2023
Maintainer

As I said, I think my initial thought on "keep the full doc in a non-visible MarkupWKWebView, and present a single page extracted from it" would be a pretty big project. To me it resembles the work I did for special handling of Enter. This is particularly difficult for lists, where you sometimes want Enter to create a new list item and other times (when the list item is empty) to back up a level in the list. That is some of the ugliest code I wrote, which I can't say I'm very proud of, beyond the fact that it works.

To try to be clearer about why it's hard, consider you are inside of bolded text in a sublist item of a bulleted list, and your typing causes the page length to go beyond the size displayable on a single screen. At that point, how do you create a new document that begins with a list whose contents is empty but is several levels deep and contains an empty editable bold element that can be selected and allows you to continue to type? I don't know exactly, but I'm sure it will be difficult, and I wouldn't embark on it lightly.

I think I would pursue the following in order:

Create a testbed that contains a MarkupWKWebView next to a vanilla WKWebView that contains a contenteditable DIV with the same content. Make both paginated like you started to do. If the vanilla WKWebView has the same weird caret-not-properly-positioned behavior, then I would try to see if I could find a way to get that fixed. Maybe there is some info online about it, or maybe even the WebKit team would be responsive. They might want you to show the problem in a browser rather than the app, which might be a good exercise anyway. If the problem is in the MarkupWKWebView, then I'd start trying to narrow down what's causing it from there.
Explore whether there is any scrollling or CSS magic that might work. There are so many funky things you can do with css that I have never looked into, I wonder if there might be a way to deal with it that way to get the effect you want. The only fun I've really had with it has been to make images display an outline and handles and then use them to resize the images, so I don't have any real suggestions that wouldn't amount to me googling.

0 replies

stevengharris · 2023-08-19T18:34:57Z

stevengharris
Aug 19, 2023
Maintainer

I moved the original issue to Discussions in case anyone wants to pursue it further.

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support pagination #125

{{title}}

Replies: 9 comments

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

Support pagination #125

zhouhao27 Apr 11, 2023

Replies: 9 comments

stevengharris Apr 11, 2023 Maintainer

stevengharris Apr 11, 2023 Maintainer

zhouhao27 Apr 12, 2023 Author

stevengharris Apr 12, 2023 Maintainer

zhouhao27 Apr 12, 2023 Author

stevengharris Apr 12, 2023 Maintainer

zhouhao27 Apr 13, 2023 Author

stevengharris Apr 14, 2023 Maintainer

stevengharris Aug 19, 2023 Maintainer

zhouhao27
Apr 11, 2023

stevengharris
Apr 11, 2023
Maintainer

stevengharris
Apr 11, 2023
Maintainer

zhouhao27
Apr 12, 2023
Author

stevengharris
Apr 12, 2023
Maintainer

zhouhao27
Apr 12, 2023
Author

stevengharris
Apr 12, 2023
Maintainer

zhouhao27
Apr 13, 2023
Author

stevengharris
Apr 14, 2023
Maintainer

stevengharris
Aug 19, 2023
Maintainer