Edit jars on 5.6.1.0.5 (margins, font sizes) -- and non-jb fonthack

[knc1]

Originally Posted by shamanNS

Lab126 of course. Who else would choose "logical" design of always heading in opposite direction from modular programming and having 3 different renderer and "reader software" (sub)systems with separate codebases & hardcoded values.

Legacy baggage.

They started out using short-term contractors with very little experience in embedded Linux and with little or no planning and supervision for guidance.

Or, at least that is the impression I have from following the Kindle development over the years.

Amazon didn't invent that situation, it has been far too common in industry.

Back 'in the day' - when I did this sort of thing for a living . . . .
I even got involved in such: "Just throw something together so Marketing can claim we have something new/different" projects.

Some of which that where supposed to have a lifetime of one 'marketing season' are still with the general public today.
Too to mention any by name now.

[tiandijie]

Originally Posted by Barty

I've made my dictionary font really large (maybe too large) by editing a jar, so I know it's possible. I just don't remember which jar and which values.

Attachment 144043

ETA: I think the dictionary font size is determined by one of the sizes in FONT_RAMP or jar equivalent. Maybe the fourth or fifth, I don't know which exactly. You'll need to experiment.

Since 5.65 jailbreak went quite handy, now I'm eagerly looking for a way to play this dictionary font trick. Is there anyone have any ideas ? Thanks for any kinds of comments

[PRS-T2]

Thought I'd make a summary based on findings in this long thread and some simple calculations for beginners like me. Hope this helps understanding how the FONT_RAMP values correlate to what the kindles show on display as measurable height in mm (approximately, differs a bit depending on the font - I'm using Bookerly on 300dpi PW3)

##### Default values are: #################
7.13 7.81 8.49 9.17 10.53 12.56 16.98 29.2

This translates to height in px:
19.2; 21.1; 23; 24.7; 28.6; 33.9; 45.8; 78.9

How? FONT_RAMP value * 2.7 = height in px

How many px per mm are shown on 300dpi PW3/Voyage:

300/25,4 = 11,81px/mm
Height in px / 11,81 = height in mm

Example:

29.2*2,7=78.9
78.9/11.81=6.68mm

##### Some working sets from other users: ########

11.30 11.72 12.14 12.56 12.98 13.40 13.82 14.24

9.33 10.00 10.67 11.33 12.00 12.67 13.33 14.00

12.30 12.72 14.14 14.56 15.98 16.40 17.82 18.24

###### My testing and sets: ##################

7.13 7.81 8.49 9.17 10.53 12.56 16.98 18.24
// Default, but biggest setting (value 8) reduced
// Steps between 4-5 and 5-6 too much; value 1 too small

7.81 8.49 9.17 10.53 12.00 12.56 15.98 18.24
// eliminated value 1 and tweaked the upper middle field

What I'm happy with for now:
7.81 8.49 9.17 10.00 11.33 12.00 14.56 17.82
// further tweaking from middle upwards to smoothen steps


Also interesting read plus cheat sheet to steal more working values from:
https://www.mobileread.com/forums/showpost.php?p=3089345&postcount=42
Thanks to odamizu, who also explained a bit there how these values are calculated in order to actually work.

More detail about how the kindle values are calculated explained by tono1020:
https://www.mobileread.com/forums/sho...5&postcount=54
// it's a good read for the non-metrics especially. For my testing I found my way easier to handle, though less accurate than tono1020's.

[ecc29]

Originally Posted by PRS-T2

##### Default values are: #################
7.13 7.81 8.49 9.17 10.53 12.56 16.98 29.2

This translates to height in px:
19.2; 21.1; 23; 24.7; 28.6; 33.9; 45.8; 78.9

How? FONT_RAMP value * 2.7 = height in px

Sorry I still don't understand how did you get that value 2.7 on a 300DPI screen. If those values in FONT_RAMP file are 1/100 inch, then convert 1/100 inch to mm: 29.2/100*25.4 = 7.42mm, not 6.68mm.

[PRS-T2]

Originally Posted by ecc29

Sorry I still don't understand how did you get that value 2.7 on a 300DPI screen. If those values in FONT_RAMP file are 1/100 inch, then convert 1/100 inch to mm: 29.2/100*25.4 = 7.42mm, not 6.68mm.

Hey ecc29 sorry for the late answer, had a rough week :-)

In post #22 tono1020 posted the default values and their equivalent in px. That's where I took the multiplier 2.7 from. Since the outcome is height in px, not mm or inch, it's not a value specific for either of the screen resolutions. I was looking for an easy way to calculate pixel sizes and go device/resolution specific in a later step, because I'm using a PW2 and a PW3.

[odamizu]

I received a PM asking for values for a PW2. Since I don't have a PW2, I can only take a stab at some numbers:

10.32 11.26 12.19 13.13 14.07 15.01 15.95 16.88

If anyone with a PW2 cares to offer a better set, please do.

To the person who PM'd me, you can really pick any numbers you like. If no one offers a better set, start with the above then adjust the numbers up or down to your liking.

[kaznelson]

For java professionals - file "ReaderSDK-impl-sq.jar" contains non-bytecode sources in "ReaderResources.java.src" etc...

[byzkarl]

Can anyone confirm whether this still works on 5.7.3? I can't see any difference.

[NiLuJe]

Unless you tweak the bytecode yourself, of course not, this is highly FW-specific, and mixing libraries from different FW versions is a very neat way to shoot yourself in the foot.

[shalym]

Originally Posted by NiLuJe

Unless you tweak the bytecode yourself, of course not, this is highly FW-specific, and mixing libraries from different FW versions is a very neat way to shoot yourself in the foot.

Actually, it does still work--it's worked just fine with no modifications through all of the updates since 5.6.1.0.5 I'm on 5.7.3 on my Voyage and the FONT_RAMP still works just fine.

Shari

[eschwartz]

I think NiLuJe was (erroneously) thinking of kaznelson's modified jars...

Happens to the best of us.

[NiLuJe]

Ooh, we were talking about the FONT_RAMP thing?

My bad, yeah, given the thread, I thought this was still about the margins ;p.

Let's blame it on: Yesterday, 05:28 ^^.

[knc1]

Originally Posted by eschwartz

I think NiLuJe was (erroneously) thinking of kaznelson's modified jars...

Happens to the best of us.

So was I.

If people would just give us a bit more context when they ask a question. . . .

[byzkarl]

Originally Posted by shalym

Actually, it does still work--it's worked just fine with no modifications through all of the updates since 5.6.1.0.5 I'm on 5.7.3 on my Voyage and the FONT_RAMP still works just fine.

Shari

It doesn't appear to change anything for me. I put a FONT_RAMP file in with all the same numbers just to make sure it wasn't my eyes, and it didn't change anything.

I'm open to the possibility that I'm doing something wrong, but I had it working before the update.

[shalym]

Originally Posted by byzkarl

It doesn't appear to change anything for me. I put a FONT_RAMP file in with all the same numbers just to make sure it wasn't my eyes, and it didn't change anything.

I'm open to the possibility that I'm doing something wrong, but I had it working before the update.

It works for me on KF8 format books, but not on .mobi or the KFX (the new "enhanced" format.

Then again, it only ever worked on KF8, so nothing has changed.

Shari