Getting rid of the Bottom Margin's Blank Space
#1  denbertu 01-15-2020, 12:27 PM

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?
Windows.png Blank Space.png Press.png Reader_2020-Jan-15_173808.png Reduced.png 

#2  NiLuJe 01-15-2020, 01:53 PM
(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 ^^).

#3  NiLuJe 01-15-2020, 01:57 PM
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) .

#4  denbertu 01-15-2020, 04:41 PM
Thank you for reply and tips!

But the downside of having "Reclaim bar height from bottom margin" checked is inconsistent bottom margin.
Reader_2020-Jan-15_233107.png Reader_2020-Jan-15_233119.png Reader_2020-Jan-15_233136.png 

#5  pazos 01-15-2020, 07:15 PM
Quote 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.

#6  NiLuJe 01-15-2020, 08:39 PM
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.

#7  Frenzie 01-16-2020, 07:24 AM
@NiLuJe On the contrary, CREngine used to have a bug where it didn't do negative margins, see

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

#8  NiLuJe 01-16-2020, 11:31 AM
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 ).

#9  Frenzie 01-16-2020, 11:58 AM
Right, so depending on what it actually does it could be a (seemingly benign) bug.

Today's Posts | Search this Thread | Login | Register