in scroll mode, "page width" (line length) is too short

[danielweck]

See edrlab/thorium-reader#2061

Relevant code and doc: https://github.com/search?q=repo%3Areadium%2Freadium-css%20RS__maxLineLength&type=code

[danielweck]

PS: my opinion (as a user, not specifically a developer) has always been that configuring "margin sizes" is the wrong approach, to me it makes a lot more sense to allow customisation of the "line length" (optimal text run width depending on user preferences / abilities, available screen real estate, etc.). With this perspective in mind, the "margin size" is then just a byproduct / side effect of configuring the "page width" (not the other way around, as was the case in Readium "1" if I remember correctly).

Side note: the implementation of margin indicators (e.g. highlights / annotations), previous/next icon buttons (+ various other reading system affordances) must factor in the fact that margins are dependent on (derived from) the chosen / preferred / default line width.

[mickael-menu]

👍 I'm also in favor of adding an explicit line-length setting. This would allow using the native font size setting on Android, which works even with publisher styles enabled.

https://github.com/readium/kotlin-toolkit/blob/7649378a0a6b924abedf8b72372c3808fe9b992f/readium/navigator/src/main/java/org/readium/r2/navigator/epub/EpubNavigatorFragment.kt#L136-L150

I would still keep an explicit horizontal-margins setting. It doesn't have to be a user setting, but rather a "static" RS setting. This would ensure a safe area for margin indicators, as you mentioned.

[JayPanoz]

Thanks Past Me for documenting design decisions, etc. as it helped catching up on this issue quite a lot.

So @danielweck pointed the variable pagination/scroll are using internally e.g. --RS__maxLineLength. Due to pagination using CSS multicolumn, it should be mentioned it’s impacted by --RS__pageGutter to mimic inline margins – so left and right for horizontal writing, top and bottom for vertical writing. In other words, the largest the margins, the shortest the line length. See Auto pagination model.

As a side note, it was also used to force a reflow in webkit-based views/browsers. I’ll have to check whether that bug still occurs as a side quest.

While scroll mode is obviously not using CSS multicolumn, it’s re-using these variables – either explicitly or through the cascade.

https://github.com/readium/readium-css/blob/583011453612e6f695056ab6c086a2c4f4cac9c0/css/src/modules/ReadiumCSS-scroll.css#L24-L27

And the user setting for page margins (--USER__pageMargins) is relying on --RS__pageGutter:

https://github.com/readium/readium-css/blob/583011453612e6f695056ab6c086a2c4f4cac9c0/css/src/modules/user-settings-submodules/ReadiumCSS-pageMargins_pref.css#L9-L12

This also points out an issue in documentation as these 2 are explicitly listed under pagination while they can be applied in
scroll mode.

Anyways, I guess adding a --USER__lineLength overriding --RS__maxLineLength should more or less do the trick as a first implementation to iterate over. Then it should be easier to see what could help make things predictable – in hindsight, we probably tried to be too smart for our own good in ReadiumCSS on occasion.

[JayPanoz]

TODO: define how a --USER__lineLength setting should behave.

One could complain it only works in scroll mode while it could also be applied in single column – but in that case how should it behave in 2 columns (pseudo spread).

Also, how it should interact with --USER__pageMargins.

[JayPanoz]

Draft for a proposed resolution.

• create a user setting submodule and expose --USER__lineLength as the custom property for line length
• --USER__lineLength should override --RS__maxLineLength
• --USER__lineLength should apply to single column pagination and scroll
• --USER__pageMargins should still apply if they are set by the user

At the moment it’s still unclear to me how this should behave in 2-columns as I need some practical implementation to see what’s possible.

[JayPanoz]

Note to self: some authors’ styles may have a max-width applied to body or a div for body copy so it should be overridden in the user setting submodule.

[JayPanoz]

Proposed resolution: While page margins can be kept for Reading System purposes and even as a user setting – if only for legacy/deprecation, a new USER variable should be created for line length so that it can be set.

It’s still unclear what would be best as a value e.g. CSS units (length), multiplier as is the case with page-margins, etc. so please feel free to record your preference in this issue.

This line length setting should override authors’ max-width as well, if set.

Documentation should be updated accordingly.

[danielweck]

The problem with "margins" in "pages" is that this tangible / physical concept does not technically map to column gap very well, as the whitespace is uniformly distributed across columns. This equidistant property is an inherent characteristic of the layout model which we can't fix (and it has its benefits anyway, so better live with it) but this is a problem on any widescreen, let me post screenshots which are easier than words :)

[danielweck]

[danielweck]

[danielweck]

The image above is a mockup, that's what I'd like to achieve in Thorium navigator ... technically it's a bit more complicated than it looks due to viewport calculations and applying masks (to hide the before/next CSS columns beyond the current page spread)

The margin indicators for annotations would still work, but there would be a number of changes in the arithmetics involved in computing character-level visibility, etc. It's a lot trickier than it sounds due to the current layout model.

To be honest, the more I think about it, the more I believe the easiest (less bug-prone) solution would be to shrink the actual viewport (out of process iframe, in Electron) and possibly collaborate from the navigator with the application to achieve the desired rendering layout.

[mickael-menu]

To be honest, the more I think about it, the more I believe the easiest (less bug-prone) solution would be to shrink the actual viewport (out of process iframe, in Electron) and possibly collaborate from the navigator with the application to achieve the desired rendering layout.

Yes, that's my sentiment as well. But it gets tricky to have proper page-turn animations. Maybe using snapshots we can provide a better experience with slide or fade-out pages.