Smaller margins in dual page mode?

[WS64]

Is it possible to make the borders on the L/R margins in the middle smaller?
Here in dual page portrait mode it is extrem, but in landscape mode it is not much different.
I have set L/R margins to zero already, but there is still a lot of space in the middle wasted.

[poire-z]

It is hardcoded at https://github.com/koreader/crengine/blob/c4b6b9ee2a5e123f20955b80b29b3a0063863844/crengine/src/lvdocview.cpp#L2579-L2611 to be at min 1.2em (= 1.2 your normal font size) - unless I messed the computation.
So, it decreases as your font size decreases. May be your text itself has a font-size: 0.8 and is smaller than the normal (1rem) font size, so this large gap ? You can check that by enabling the "Ignore publisher font sizes" style tweak.

For me, with the text using the normal font size, it feels alright at various font sizes:

We don't want to go as low as the L or R margin, we need more between the 2 columns for readability.

[WS64]

ok, !important did the trick.
It is for sure better that way. But to be honest, when I put the margins to zero I'd expect "zero", so the columns should stick together.
If there is a chance to make the 1.2em configurable I would prefer that.
Epecially in portrait mode I still think there is too much space wasted in the middle!

[poire-z]

But to be honest, when I put the margins to zero I'd expect "zero", so the columns should stick together.

Mhhh, you put the L/R margins to 0, and you would expect KOReader to not care much and put 0 in the middle and make the book unreadable ?! I'm sorry to hear hat you expect so little of us :)

@zwim: any thought of the middle margin size, after a few days of playing with dual page in portrait mode?

I f*cking hate this github Discussion stuff, it has no visibility, no linkability to the issue where we're currently discussing dual pages... I always have to click "view more" to read the latest posts... Please please please give up on it and use regular Issues...

[WS64]

I agree on the gitthub discussion, really hard to keep track.
It was suggested I use it, and it was worth a try, but the "issue" section really is better!

[hius07]

any thought of the middle margin size

Who told about two items only in the bottom menu and a room for more settings? :)

[Frenzie]

@poire-z

I always have to click "view more" to read the latest posts...

I really hate that about GH PRs btw. I haven't yet noticed it in these discussion things.

I do like the theory behind them, namely that your issues are things more directly relating to the code and these are… discussions about any old thing. I'm fairly neutral on them I think but I'm inclined to agree it's more of a poor forum and not really a part of GH with added value.

[NiLuJe]

@poire-z: Wild idea: what about picking up the "line spacing" prop instead of hard-coding it to 1.2em?

[Frenzie]

@poire-z Oh, I just saw that "view more" here. Okay, that's really annoying.

[NiLuJe]

@poire-z Oh, I just saw that "view more" here. Okay, that's really annoying.

Huh, yeah, first time I've noticed it, too. I was fairly okay with this it showed up, actually ^^.

[poire-z]

first time I've noticed it, too

That means you haven't noticed all the other ones :) There was one just here, there is another one above for the sub-discussion with screenshots - an earlier discussion may continue, and you won't notice it if you scroll to bottom like we're used to with issues/PRs...
The only real way to follow this is via the mail notifictions we get...

And hop, hitting Reply and having this post ending in a nearly invisible View more... :/

[NiLuJe]

@poire-z: Okay, after testing, rewriting the logic in a possibly-easier-to-grok yielded similar results...

And it actually feels decent... as long as there aren't margins/padding in the CSS...
Do we have a way to know about those at this point?

(Romeo & Juliet in the tests is a perfect example of that, it has ginormous margins).

# With L/R set to 18px, and the book's page margins disabled.
min_middle_margin=48
max_middle_margin=18
middle_margin=36
additional_middle_margin=12

# Which matches my commented logic ;p
floor_margin=48
target_margin=18
baked_margin=36
Increasing margin to floor_margin
margin=12

        // We want at least 1.2em
        int floor_margin = 1.2 * m_font_size;
        fprintf(stderr, "floor_margin=%d\n", floor_margin);
        // We prefer using the greater of L or R first, though
        int target_margin = m_pageMargins.left > m_pageMargins.right ? m_pageMargins.left : m_pageMargins.right;
        fprintf(stderr, "target_margin=%d\n", target_margin);
        // The amount of space that will be baked in the rects later
        int baked_margin = m_pageMargins.right + m_pageMargins.left;
        fprintf(stderr, "baked_margin=%d\n", baked_margin);

        // Which gives us the final extra margin we actually need to add (or subtract) given that.
        int margin = 0;
        // If our target margin is smaller than floor, use the floor
        if (target_margin < floor_margin) {
            // If the baked in marging is *also* smaller than the floor, make sure we add enough space to reach the floor
            if (baked_margin < floor_margin) {
                fprintf(stderr, "Increasing margin to floor_margin\n");
                margin = floor_margin - baked_margin;
            } else {
                fprintf(stderr, "Using floor_margin\n");
                margin = baked_margin - floor_margin;
            }
        } else {
            // Here, baked_margin cannot be smaller than target_margin, because it's essentially target_margin + the opposite margin.
            fprintf(stderr, "Using target_margin\n");
            margin = baked_margin - target_margin;
        }
        fprintf(stderr, "margin=%d\n", margin);

[NiLuJe]

With the crappy CSS:

Nerfed by the style tweak:

[poire-z]

It's lacking what you do with the "margin" at the end.
I had to rewrite "my" code with your naming to get to understand your new terminology:

int floor_margin = 1.2 * m_font_size;
int target_margin = m_pageMargins.left > m_pageMargins.right ? m_pageMargins.left : m_pageMargins.right;
int margin = 0;
int baked_margin = m_pageMargins.right + m_pageMargins.left;
if (baked_margin < floor_margin) {
        margin = floor_margin - baked_margin;
}
else if (baked_margin > target_margin) {
        if (target_margin > floor_margin)
                margin = target_margin - baked_margin; // negative
        else
                margin = floor_margin - baked_margin; // negative
}
// Note: with negative values, we allow these 2 m_pageRects to
// overlap. But it seems there is no issue doing that.
m_pageRects[0].right = middle - margin / 2;
m_pageRects[1].left = middle + margin / 2;

And had to re-picture what are rects, and m_pageMargins is a false rect, just a holder of 4 values. And realized that "middle" is just a point.
I'm still very confused by both our codes :) The good thing is that we get the same result with different thinkings (are they really equivalent?), so, somehow we must both be right and that validates any algo :)

[NiLuJe]

Oh, yeah, the end seemed to make sense as-is ;p. i.e., you've got the middle of the screen, you've just computed how much of a gap, total, you want between columns, so, just stop one column at half of margin on the left of that and start the other at half of margin on the right ;).

The main "issue" I have with the logic that way around is that, technically, baked_margin > target_margin is always true, because baked_margin is target_margin + the opposite margin, so, even with super-weird margins, they're at worst equal ;p.

[NiLuJe]

What works decently well (but with generally tighter margins), is using L+R as the target gap, and the user's interline as the floor.

        fprintf(stderr, "interline=%d\n", m_def_interline_space);
        // We want at least an interline's worth of column gap
        int floor_gap = (m_def_interline_space / 100.f) * m_font_size;
        fprintf(stderr, "floor_gap=%d\n", floor_gap);
        // But we prefer using the the sum of the L+R margins as the column gap
        int target_gap = m_pageMargins.right + m_pageMargins.left;
        fprintf(stderr, "target_gap=%d\n", target_gap);
        // The page margins happen to *already* be baked into the pageRects later on,
        // so take that into account to compensate
        int baked_margin = m_pageMargins.right + m_pageMargins.left;
        fprintf(stderr, "baked_margin=%d\n", baked_margin);

        // Which gives us the final size of the column gap we'll actually need to add (or subtract) given that.
        int gap = 0;
        // If our target gap is smaller than floor, use the floor
        if (target_gap < floor_gap) {
            // If the baked in margin is *also* smaller than the floor gap, make sure we *add* enough space to reach the floor
            if (baked_margin < floor_gap) {
                fprintf(stderr, "Increasing margin to floor_gap\n");
                gap = floor_gap - baked_margin;
            } else {
                fprintf(stderr, "Using floor_gap\n");
                gap = baked_margin - floor_gap;
            }
        } else {
            // Here, baked_margin cannot be smaller than target_margin, they're always equal ;).
            fprintf(stderr, "Using target_gap\n");
            gap = baked_margin - target_gap;
        }
        fprintf(stderr, "gap=%d\n", gap);
        // NOTE: with negative values, we allow these 2 m_pageRects to
        // overlap, which appears to be harmless.
        // middle is at the middle of the screen, which becomes the middle of our column gap,
        // so, just set the left column's right edge at half a gap's worth on the left of that,
        // and the right column's left edge at half a gap's worth on the right of that.
        m_pageRects[0].right = middle - gap / 2;
        m_pageRects[1].left = middle + gap / 2;

Lit3rata, with a small native interline, and KO set to 110%

Noto Serif, with its giant native interline, and KO set to 80%

[NiLuJe]

e.g., if I were actually the target audience, that'd work for me. Keep in mind that I tend to favor very small margins and very small interlines, though, so, YMMV ;).

[poire-z]

Well, I'm not a fan of that kind of setting re-use/intervening :)
I guess I'll just switch the 1.2em to 0.8em (0.6em was really too small, 0.8em looked almost OK on the emulator, will have to check on my Kobo).

People wanting a larger one could just increase L/R margins:

(so we can be done with this - and this hellish GitHub Discussion. :)

[NiLuJe]

That works, too ;).