Getting rid of the Bottom Margin's Blank Space

[denbertu]

Hello Everyone.
I found the way to eliminate that pesky blank space. (I search through internet but didn’t find any answer for this. So I decided to make a post.)

Here are a few steps:

1. For PC:

Go to the Koreader folder on your device, open the defaults.lua and change DCREREADER_CONFIG_B_MARGIN_SIZES_SMALL to -15.

2. For Ereader:

Summon the Main Menu, select the bottom tab with margin settings and set the bottom margin default value to -15 by pressing on the leftmost box.

I hope it will help someone.
Is there another way to get rid of it?

[NiLuJe]

(In a document): Top Menu > Gear > Status bar > Settings > Reclaim bar height from bottom margin

That'll ensure a 0 bottom margin will actually be 0.

Whether you do get a final line of text in here is subject to whether CRe decides it has enough space to do so or not given the current font settings .

I don't *think* it actually supports negative margins, in which case what you just did was just a roundabout way of negating the status bar height, but I very well might be wrong (ping @poire-z ^^).

[NiLuJe]

Also, defaults can be edited from within KOReader itself (Advanced settings, in the File Manager. It's in the Gear or Tools tab, I can't recall) .

[denbertu]

Thank you for reply and tips!

But the downside of having "Reclaim bar height from bottom margin" checked is inconsistent bottom margin.

[pazos]

Originally Posted by denbertu

Thank you for reply and tips!

But the downside of having "Reclaim bar height from bottom margin" checked is inconsistent bottom margin.

The margin is consistent: 0. The distance between the last line displayed on that page and the bottom will be < the height of a line of text + surrouding space.

[NiLuJe]

Which, in your examples, happen to fall just right when there's a bit of extra layout-provided vertical space (title, blockquotes), but not with only paragraphs, where it might be missing a very few pixels.

The usual process involves decreasing/increasing the *top* margin (increasing it will shift content to the bottom, balancing the top/bottom white space, while decreasing it might be enough to free enough space to squeeze that last line in) until you find something that works okay. And/or play with font sizes & line height.

That said, the fact that it behaved differently with a negative margin prooobably means we can lie to CRe. Which could arguably be construed as a bug, because it really shouldn't render to a larger buffer than the screen's ^^. I'll have to look into it one of these days.

[Frenzie]

@NiLuJe On the contrary, CREngine used to have a bug where it didn't do negative margins, see https://github.com/koreader/crengine/pull/299

(Probably not relevant to this particular margin here but either way I consider negative margins integral to getting the display you want.)

[NiLuJe]

Margins might have been the wrong word ^^.

IIRC, we feed CRe a rectangle, computed after *our* margins are applied. That's what it uses to draw to. If *that* doesn't clamp to device's screen-size, *that* could be construed as a bug ;p. (i.e., once we blit that back to screen, the extra bottom rows are essentially "lost". Which works out okay for this purpose, but, could be interpreted as undefined behavior ).

[Frenzie]

Right, so depending on what it actually does it could be a (seemingly benign) bug.