Support for paginated content with single or dual column/spread

[HadrienGardeur]

For this task, we're targeting the ability to force a single or dual column/spread.

For reflowable EPUB files, this means:

• [x] forcing a single column while remaining in almost full width for the content area
• [x] dynamically calculating and fitting the width of the content area for dual column mode
• [ ] fallback when dual columns can't be fitted (could be a single column and/or a smaller line length)

For FXL files, this means:

• [x] support for a single page mode
• [x] support for a forced spread mode

[JayPanoz]

Alright, indirectly documenting what’s happening being the scenes with CSS multicol, and clarifying the behaviour based on that. I guess it’s useful for others checking this issue re. "content area" and how it translates.

First things first, we have multiple widths in practice:

1. the width of the Navigator’s container, which is part of the app UI;
2. the max-width of the content paginated using columns, which serves as line-length.

For auto (layout) we’re doing the following:

• the width of the navigator’s container is constrained when a breakpoint has been reached (say 1024px wide). At this point the area (size and offset) of left and right arrows is subtracted from the window’s innerWidth;
• the number of columns is based on this width, and an optimal line length that can be computed for a specific font-family, letter- and word-spacing applied by users, etc.

Basically, value auto is the multiple of optimal line-lengths + gap (page gutter as padding in ReadiumCSS) you can fit in the viewport.

The Navigator’s container is then constrained by line-length and gap in order to be consistent with dual-column mode.

With that in mind, let’s now switch to the other options: single or dual column/spread.

forcing a single column while remaining in almost full width for the content area

The navigator’s container is not constrained in that case.

The line-length is applied, be it the optimal one or, in the future, the one the user has set.

dynamically calculating and fitting the width of the content area for dual column mode

In practice, you just have to set column-count: 2 and CSS multicol will take care of the rest.

The width of the navigator’s container is constrained by the line-length and the gap.

fallback when dual columns can't be fitted (could be a single column and/or a smaller line length)

Based on the dual column mode case, the fallback you get for free from CSS Multicol is that it will force 2 columns no matter what so, you get a smaller line-length by default.

So if you want to switch back to a single-column you have to simply change the column-count based on conditions. In that case, what should be these conditions?

[HadrienGardeur]

Based on the dual column mode case, the fallback you get for free from CSS Multicol is that it will force 2 columns no matter what so, you get a smaller line-length by default.

So if you want to switch back to a single-column you have to simply change the column-count based on conditions. In that case, what should be these conditions?

IMO we need a way to return the current number of characters per line that's actually displayed (vs the optimal number of characters), which an app could use to lower the number of columns to a single column when the number of characters per line gets below a specific number.

This could even be part of the Preferences API where we would support both:

• an optimal number of characters per line
• and a minimal number of characters per line

[HadrienGardeur]

Some additional thoughts on this:

• we should set the minimal number of characters per line to 35, anything below that is considered problematic
• we could use the higher bound value for optimal number of characters per line at 75
• our settings will be smart enough to get to something optimal on all devices that way, we might not even need our fallback to a single column on mobile anymore