Scribe -- reduce margins?

[shamanNS]

Originally Posted by Quoth

On the really old Kindles you could edit a prefs file (which setting was destroyed if you selected a margin on the GUI).

I used to use that on my Kindle Keyboard and to be able to fix that overwritten-by-UI problem (when other people mess with my Kindle) without using a computer I had a script (for whatever was the name at the time for "script launcher" thing that offered creating shortcuts using keyboard buttons) that used sed to re-edit that prefs file

Originally Posted by Quoth

It's not the only daft thing Amazon has done with Kindles.

And since fw 5.10.x or thereabouts they even made it so that reducing margins via editing hardcoded values inside JAR files doesn't work... probably there is duplicate or triplicate code in some new files and those "legacy" ones we the "power users" have known and modified past ~10 years are overridden somewhere else.

That was 1 of 2 things that pushed me into using KOReader + epub when I bought PW5 instead of combination of "patched" stock reader (with non-CSS approach to reducing margins) + KFX book format that was the combo I've used on my PW3 (that I've intentionally kept on firmware 5.8.11 until the day I've sold it).

The second thing was not being able to redefine font sizes for KFX books by using "CONTENT_FONT_RAMP" file in similar way that "FONT_RAMP" does for KF8 / AZW3 books... since that also requires editing JAR files to enable parsing of CONTENT_FONT_RAMP and me not having an answer to the question "would PW5 with its locked bootloader and secure boot thing even boot after user has edited existing system files?" and PW5's board not having serial pads and me already having bricked one PW5 unit while trying to deal with missing "Book Cover" option / toggle in Device Settings... I've decided that safest and financially sound approach would be to just use KOReader instead on the replacement PW5 unit.

And since I've read comments of bunch of PW5 owners having they devices stuck in bootloop and even if just one of those comments has reported that bootloop / brick has occurred when PW5 froze while it was left in standby with KOReader opened I'm being extra paranoid and don't keep KOReader running on my PW5 all the time but exit out of KOReader every time I'm finished reading for that day.

[Sonnenfee]

Originally Posted by DuckieTigger

Since different devices need different values for the offset, I tried to avoid that by going relative. Try this one on your Scribe, see if it works:

html {
  margin-left: -6%;
  margin-right: -6%;
}

The break-inside may or may not be necessary - for some fringe cases where the margins are being abused as layout support.

If it works on Scribe, then it will work universally - either for kf8 or kfx.

I have tried the setting -6% for margin-left and margin-right for azw3.
For the Scribe it's the identical result as with value -100px for margin-left and margin-right.

For the Oasis 3 it works with the values -6%, if you want the text very close to the edges. Personally, on the Oasis 3 it would be too close to the edges for me with this setting.

Fortunately some users made it possible that the Oasis 3 became jailbreakable with FW-Version 5.14.2 and KOReader could also be installed; for their work I'm still grateful.

With the Scribe, I'm satisfied with the margins that can be achieved with the above mentioned values.

A quick & dirty pic which shows the difference:

[tomsem]

I do not find it comfortable reading lines of text that are that long.

As it is, I have margins on my Scribe set to maximum and have increased font size a bit from what I use on smaller screens, just to make it more readable. So I find this quest to reduce margins on Scribe rather strange. At very large text sizes, it would make more sense, of course: you'd want to get lines of text to be long enough.

https://baymard.com/blog/line-length-readability
https://www.paulolyslager.com/optima...t-line-length/

[DuckieTigger]

Originally Posted by Sonnenfee

Personally, on the Oasis 3 it would be too close to the edges for me with this setting.
[..]
With the Scribe, I'm satisfied with the margins that can be achieved with the above mentioned values.

A quick & dirty pic which shows the difference:

Thanks for that. That is unfortunate that the same setting does not work equally well when adding the Scribe to the mix. With anything I tested 7" to 6", the differences between the devices was much smaller.

Also thanks for the side by side. It makes me want a Scribe less than before. The only usecase for me would be PDF files. For novels the lines on the Scribe are a bit too long for me. And increasing the font size would defeat the need for a bigger screen. Maybe I will wait until my eyes need a larger print or the Scribe gets a two column option.

[tomsem]

Originally Posted by DuckieTigger

Thanks for that. That is unfortunate that the same setting does not work equally well when adding the Scribe to the mix. With anything I tested 7" to 6", the differences between the devices was much smaller.

Also thanks for the side by side. It makes me want a Scribe less than before. The only usecase for me would be PDF files. For novels the lines on the Scribe are a bit too long for me. And increasing the font size would defeat the need for a bigger screen. Maybe I will wait until my eyes need a larger print or the Scribe gets a two column option.

It does take some adjustment, but I appreciate the versatility of a larger screen.

Even with larger margins and text, there is more text per page so I find it as comfortable as on small screen. I don't think 2 column would be helpful for Portrait but surely it is needed for Landscape.

Eventually, when they sort out issues with Print Replica, it will be nice to read PDFs (converted to PR) more comfortably and have that functionality for 'PDF' personal documents in the apps as well (sync of reading position, annotations etc.). And I have a number of Kindle books in that format that I'd like to read on Scribe.

I'm starting to get a little impatient for the update. But adding Print Replica support is the biggest change on Kindle in years, and it will be better supported across the Kindle platform than PDF is.

[JSWolf]

Originally Posted by Quoth

Next test is to see does

survive epub2 upload to KDP, and still be in a bought azw3 download.

I'd not hold my breath! I'd try it without the "break-inside: avoid !important;"

Don't remove the break-inside. It fixed some issue back when it was discovered. It doesn't cause any problems so just leave it.

[Barty]

Originally Posted by Quoth

About 5 minutes programming and week testing, maybe, to have a margin that doesn't add 6% to the ebook margins. It's plain silly. On the really old Kindles you could edit a prefs file (which setting was destroyed if you selected a margin on the GUI).

It's not the only daft thing Amazon has done with Kindles.

I think the problem is these design choices are made for the product page and review screen shots, not for the users. Having small margins looks ugly in the ads and in reviews, having large margin looks better. Having 4 or 5 margin choices looks "cluttered," so we're stuck with only 3. Looks trump functionality and flexibility. On the other extreme is something like Koreader, which has a ton of options and an overwhelming UI

We used to be able to reduce the margins by editing a config text file. I think that was a good compromise, keeping the clean UI while having a relatively simple way for people who care to tweak the setting to their liking. But they took that away because ...?

[DuckieTigger]

Originally Posted by Barty

But they took that away because ...?

They took that away so they wouldn't need to waste CS training on fixing stupid mistakes. Same as they intentionally broke the font-ramp and custom fonts. The functionality is technically there, at least last time I had a jailbroken Kindle, but the filename it is looking for has a newline character in it (==cannot find custom file).

[Sirtel]

Originally Posted by DuckieTigger

They took that away so they wouldn't need to waste CS training on fixing stupid mistakes. Same as they intentionally broke the font-ramp and custom fonts. The functionality is technically there, at least last time I had a jailbroken Kindle, but the filename it is looking for has a newline character in it (==cannot find custom file).

Eh? Both the font_ramp and custom fonts worked with my Oasis 3. The first only with AZW3, true.

[DuckieTigger]

Originally Posted by Sirtel

Eh? Both the font_ramp and custom fonts worked with my Oasis 3. The first only with AZW3, true.

Oh? Have to try again with newer than PW1 - that one, I believe got broken.

[Sirtel]

Originally Posted by DuckieTigger

Oh? Have to try again with newer than PW1 - that one, I believe got broken.

Custom fonts have been officially supported for several years now. And I've used the font_ramp on various Kindles, the newest being the Oasis 3. None of my Kindles were jailbroken.

Font_ramp doesn't work with KFX, though.

[DuckieTigger]

Originally Posted by Sirtel

Custom fonts have been officially supported for several years now. And I've used the font_ramp on various Kindles, the newest being the Oasis 3. None of my Kindles were jailbroken.

Font_ramp doesn't work with KFX, though.

I mixed that up with unofficial way of adding custom fonts on KT, and initially on PW1, which later on got broken (still works on KT). I do see a few custom fonts in my Oasis2, haven't bothered on the Oasis3. Most of the time Bookerly or Caecilia Condensed is good enough for me.

[Quoth]

And embedded fonts work on any Kindle that works with AZW3, assuming in Theme or Aa you select publisher.

[mg10]

Originally Posted by JSWolf

How can you use -100px? That would make the text go past the edges of the screen.

This is what I used for a 300DPI Kindle.

html {
  margin-right: -45px;
  margin-left: -45px;
  break-inside: avoid !important;
}

Is it possible to apply this to reduce the bottom margin?