[Nook Touch General] jeff_kz:
For those who don't feel like taking apart the apk, the lines referenced are:

.field public static final FONT_SIZE_1:D = 7.0
.field public static final FONT_SIZE_2:D = 8.5
.field public static final FONT_SIZE_3:D = 9.75
.field public static final FONT_SIZE_4:D = 11.0
.field public static final FONT_SIZE_5:D = 13.0
.field public static final FONT_SIZE_6:D = 20.0
.field public static final FONT_SIZE_7:D = 27.0

Which looks like a pretty reasonable place to make the changes, right?

To understand why this doesn't work, you need to know a little bit more about the Java compiler, specifically what it means to declare a value as static final.

Consider the following Java code:

private static final double TEST = 9.75;

private static void test() {
double myVal;
myVal = 1.23;

if (myVal != TEST)
myVal = TEST;
}

Since you've flagged the TEST value as static final, you're making a promise to the compiler. And that promise is: "I promise to never, ever change the value of TEST. It's 9.75 now and it's going to be 9.75 every time you run this program no matter what."

When the compiler hears you make that promise, it's just going to go ahead and substitute the value 9.75 every single time it comes across a reference to TEST.

So, to the compiler, the above code "pre-compiles" to:

private static final double TEST = 9.75;

private static void test() {
double myVal;
myVal = 1.23;

if (myVal != 9.75)
myVal = 9.75;
}

which we can verify against the resulting smali code:

# static fields
.field private static final TEST:D = 9.75

.method private static test()V
.registers 4

.prologue
.line 6
const-wide v0, 0x3ff3ae147ae147aeL

.line 8
.local v0, myVal:D
const-wide v2, 0x4023800000000000L

cmpl-double v2, v0, v2

if-eqz v2, :cond_13

.line 9
const-wide v0, 0x4023800000000000L

.line 10
:cond_13
return-void
.end method

(0x4023800000000000L is the hexadecimal representation of the double value 9.75)

Notice that there is still a static definition of TEST as 9.75. But in the code, there are no more references to TEST, just references to the value of TEST at the time the code was compiled.

In this example, if you were trying to replace 9.75 with 12.0, you would need to find the value 0x4023800000000000L and replace it with 0x4023800000000000L each place in the code. Of course, you need to be careful: since the constant labels have been stripped, you have no way of knowing if the original code referenced TEST, or 9.75 or OTHER_DEFINITION that also happened to be 9.75 and you don't want to change it in places where it may be referring to 9.75 as the price of a book instead of 9.75 as the size of a font.

Fortunately, 9.75 is a pretty unique value so a quick search through the Reader code results in only one result:

D:\nook\Reader>grep -ir 0x4023800000000000 *
smali/com/bn/nook/reader/commonui/ReaderCommonUIConstants$5.smali: const-wide v1, 0x4023800000000000L

Looking at the file, we can see in the Init() function is basically preparing a hashmap with the following values

1 => 0x401c (7.0)
2 => 0x4021 (9.0)
3 => 0x4023800000000000L (9.75)
4 => 0x4026 (11.0)
5 => 0x402a (13.0)
6 => 0x4034 (20.0)
7 => 0x403b (27.0)

Which is funny, because it's actually using 9.0 instead of 8.5 as the second font size despite the defined value and all of the values except 9.75 are defined as integers rather than Doubles. It looks like some B&N programmer ignored the FONT_SIZE_X definitions and just hard coded the values herself. Anyhow, this creates that mapping that is (most likely) used internally by the reader to find the proper sizing to use for each of the 7 font size options.

I don't have Reader.apk installed on my Nook so I can't actually test this out. But I'm pretty sure if you change the values in ReaderCommonUIConstants$5.smali you'll end up with the results you want.

If that doesn't work, let me make a plug for Cool Reader, which among many other advantages versus the stock Reader has a much larger range of font sizes to choose from.