[Bug] Ordered list restarts on every page when printed

[pabloscloud]

Describe the bug
When an ordered list continues on the next page it will start from the beginning (for example at 1)
This does not include the pdf / paper / print modes but rather the exported pdf

To Reproduce
Steps to reproduce the behavior:

1. Go to a cryptee document
2. Create a list from scratch, via the ordered list menu item or via keyboard shortcut
3. Make sure the list is between separate pages by using the pdf / paper / print mode to view the cryptee document
4. Export to pdf

Expected behavior
Should just continue counting

Screenshots
cryptee github.pdf

System Information (please complete the following information):

• Device: MacBook Air M1, 2020
• OS: macOS 13.0 Beta (22A5311f)
• Browser: firefox
• Browser Version: 13.0 Beta (22A5311f)
• Browser Extensions / Add-ons / Content/Ad-Blockers uBlock Origin, Bitwarden, Multi-Account Containers, CSS-Exfill Protection, Decentralyses
• Do you have any DNS-based content/ad-blockers? no
• Are you on a managed network? no

Additional context
I also noticed that whenever I type on the second (or any other than the first) page it will jump to the first page and I can't see what I type.

[johnozbay]

Hey @pabloscloud 👋🏻

Thanks a lot for filing this!

We're aware of this bug, and we're working on a fix for it, but it's surprisingly difficult to fix.

In short, the bullet numbering system uses CSS counters. So if you're in continuous mode, and the list isn't interrupted, it works as expected.

But, in paper mode, you technically split the list into two pages (and two separate page-divs) which causes the list to be interrupted and the counter to be reset.

To work around this, when the list is split to two pages for example, we're working on prepending invisible list items to the list to keep the counter number the same.

It's surprisingly difficult and slow to work on paper mode, because the algorithm needs to calculate each character, their height and width and figure out if it belongs on this page or next page. So a list could theoretically be interrupted if each bullet has a paragraph that is so tall that it fills and exceeds the whole page. Then what would happen is that a single bullet item would take two pages, and some characters / words would be split to the next page. Which then means we need to implement the counter-trick differently.

Which is what's taking us some extra time. We hope to have a fix for this in the very near future though.

Thanks for your patience with us 🙏🏻

Best,

J

[pabloscloud]

To work around this, when the list is split to two pages for example, we're working on prepending invisible list items to the list to keep the counter number the same.

Clever!

Which then means we need to implement the counter-trick differently.

This issue isn't of high priority anyways imo. It's just a bit confusing — that's all.