It really is a shame that my e-reader doesn't have an SD slot

[DuckieTigger]

Originally Posted by Rizla

Hopefully Kindles will continue to be jail-broken, otherwise they will become IMO sub-standard devices.

Unfortunately if you decide to jailbreak you are potentially limited by FW version. The risk is that the next FW version that has a feature you really really want breaks the jailbreak. So in general it is not always best to go the jailbreak route - it is a compromise.

[Rizla]

Originally Posted by DuckieTigger

Case closed? It remains hard coded. Replacing existing options does not add any more variety.

If a lone programmer went in and changed the font sizes, it seems unlikely to me that they are hard-coded.

There has never been any evidence that font-sizes are hard-coded despite the arguments of some posters on this forum who refuse to see the obvious truth that making more font-sizes is a pretty trivial adjustment to the Kindle code.

Hard-coding has merely been presented as a counter-argument to Amazon's apparent lack of interest in improving user options. There is absolutely no evidence for it and it flies in the face of good and extremely basic programming and UI design practice.

[Rizla]

Originally Posted by DuckieTigger

Unfortunately if you decide to jailbreak you are potentially limited by FW version. The risk is that the next FW version that has a feature you really really want breaks the jailbreak. So in general it is not always best to go the jailbreak route - it is a compromise.

True. And Amazon forces FW upgrades on the users. *shakes head* Perhaps there is a hack out there to stop the forced upgrade.

[JSWolf]

Originally Posted by DuckieTigger

Case closed? It remains hard coded. Replacing existing options does not add any more variety.

Case is not closed and it's not hard coded. It's not replacing, it's adding. It's adding more AA for more font sizes in between what exists. Many people say that a given size is too small and the next size up is too large. So Amazon should give a font size in between. Maybe even two font sizes in between. It's a number passed to the system to get the font size. So if Amazon was to modify the UI to add more numbers via more AA buttons, then Amazon could have more font size choices. If Amazon decided to give even more font sizes via a +/- type font setting then it's still a number passed to the system to get the font size. Because it's a number passed to the system to get the font size, then it's just UI programming to set how many font size changes there can be. The case was that some were saying things like how do you know it's a number passed on instead of something hard coded. Now I've found the proof that it is a number passed on to get the font size. Now we know it's Amazon not giving users what they want which is more font sizes in between the font sizes already given. It should not be that hard to program in another set of AA buttons with in between font sizes.

Kobo (in firmware 3.12.0) allows 40 different font sizes (and this is without being patched). Again, it's a number passed to the system.

[JSWolf]

Originally Posted by Rizla

True. And Amazon forces FW upgrades on the users. *shakes head* Perhaps there is a hack out there to stop the forced upgrade.

I don't know if there currently is such a hack, but there used to be. Others involved in hacking and/or creating the hacks for Kindles will have more info then I do on this.

I'm wondering if the font hack that was posted on MR will work on the latest working jailbreak.

[jbjb]

Originally Posted by Rizla

If a lone programmer went in and changed the font sizes, it seems unlikely to me that they hard-coded.

Just because someone can, by recompiling the firmware, change the hard-coded values doesn't mean they weren't hard-coded. In fact - if you look at the description of the modifications that the developer uploaded, you'll see his plea:

To Amazon Developers: guys, before creating a hardcode in the future products, think carefully. Thank you very much in advance.

I've not read the thread completely, but at first sight it looks like there's a hard-coded array of sizes presented by the UI, and a different hard-coded array of sizes supported by the renderer. These hard-coded sizes can clearly be changed (as detailed in the thread), but that's not the same as saying that the renderer can handle sizes specified by arbitrary numbers at runtime. (Of course, it also doesn't mean it can't!).

In any case, that's a digression - the point that several of us have been making is simply that despite the fact that it might be thought that it should be simple, and that it's 'Programming 101' , there's a great deal of professional experience (30-odd years in my case) which says that in the real world, code is frequently badly structured, badly written and an unmaintainable and unmodifiable mess.

Again, that's not to say that the Kindle firmware is such a mess, just that to assume without knowledge that it isn't is perhaps a tad optimistic.

/JB

[Rizla]

Originally Posted by JSWolf

I don't know if there currently is such a hack, but there used to be. Others involved in hacking and/or creating the hacks for Kindles will have more info then I do on this.

I'm wondering if the font hack that was posted on MR will work on the latest working jailbreak.

I don't know. But the UI and functionality hasn't changed so it might.

[Rizla]

Originally Posted by jbjb

Again, that's not to say that the Kindle firmware is such a mess, just that to assume without knowledge that it isn't is perhaps a tad optimistic./JB

There is zero evidence the Amazon code is such a mess and common-sense dictates it is not. As I said, the only argument for it is a counter to the appearance that Amazon simply can't be bothered.

Really, Amazon just can't be bothered

[twowheels]

Originally Posted by Rizla

There is zero evidence the Amazon code is such a mess and common-sense dictates it is not. As I said, the only argument for it is a counter to the appearance that Amazon simply can't be bothered.



Really, Amazon just can't be bothered

If the professional software developers in this thread are saying that most codebases are such a mess, why is it common sense to assume the kindle software is any different?

Moreover, jbjb pointed out that the person who did the hack complained about the way it was implemented, specifically using the word hardcoded.

[JSWolf]

Originally Posted by twowheels

If the professional software developers in this thread are saying that most codebases are such a mess, why is it common sense to assume the kindle software is any different?

Moreover, jbjb pointed out that the person who did the hack complained about the way it was implemented, specifically using the word hardcoded.

hardcoded in this case does not mean what you think it means. It does not mean that it's in the code. It's only hardcoded in a configuration file. It means that Amazon only gives so many sizes and those values are fixed in the configuration file. More numbers can be added and the existing numbers changed. So no, they are not hardcoded in the actual code. As I've been saying, those numbers in the configuration file get passed to the system to generate the font size. Change the numbers and you get different font sizes.

The underlying font sizing is already done. All that needs to be fixed is the UI that passed a number to the system to generate font sizes. It doesn't matter how much of a mess the Kindle code is or not. We already know that all you need do it fix the UI to add more font size choices. I cannot say how easy that is or not. But there's no need to have to do any modifying of any other code then the code that's used to pick a font size and pass the number to the system that already is in place and works.

[jbjb]

Originally Posted by JSWolf

hardcoded in this case does not mean what you think it means.

Yes it does.

It does not mean that it's in the code. It's only hardcoded in a configuration file.

Look again - it's not a configuration file - it's a Java source file decompiled from the .class file and then recompiled.

The numbers *are* hardcoded in the code (as the developer of the hack himself complained about).

/JB

[RHWright]

Originally Posted by twowheels

One of my biggest failures at work is assuming that something will be easy because it "should be". I have found, repeatedly, that it's better to assume that if something CAN be done in an overcomplicated way, it will be.

An example... a piece of code that I specified was for a temporary solution that did not need any future-proofing (it was to support a piece of legacy hardware that hadn't changed in 15 years and was being phased out) and that I felt (as one of the system designers) should have taken 25-50 lines of code to write, and a few hours... after 3 hours of meetings trying to explain it to the developer (with the title 'senior'), and three attempts on his part, it finally came back a week later as a 700+ line source file, with a 400+ line config file. I was in complete shock.

Another senior developer with many years of experience writing video games once "fixed" a bug in a medical device where measurements were off by 4. I later found a '+ 4' hidden in the code. He was fired the same day. This is the same guy who'd spent nearly 6 months working on a feature that was buggy as could be and after many months of testing cycles with bug after bug and many people trying to figure out his 50 boolean flags that were trying to keep track of all of the special cases and past history of what had happened to make it do the right thing next, and other developers trying to help fix the bugs by adding even more flags... I finally got permission to rewrite it myself and did it in less than a day, with ZERO flags to keep track (just one state variable and a simple state chart) and it had ONE tiny little bug that was found the next day where I went "doh!" and fixed it in less than 30 seconds. No bugs were ever found in that code after that.

I am not a programmer, but I deal with the results of their work on a daily basis. I swear, sometimes I think they overcomplicate things as a means of job security. If you're the only one who understands an essential system, they can't get rid of you.

I wish more developers followed your inherent philosophy of keeping it simple.

[tompe]

Originally Posted by jbjb

I've not read the thread completely, but at first sight it looks like there's a hard-coded array of sizes presented by the UI, and a different hard-coded array of sizes supported by the renderer. These hard-coded sizes can clearly be changed (as detailed in the thread), but that's not the same as saying that the renderer can handle sizes specified by arbitrary numbers at runtime. (Of course, it also doesn't mean it can't!).

In any case, that's a digression - the point that several of us have been making is simply that despite the fact that it might be thought that it should be simple, and that it's 'Programming 101' , there's a great deal of professional experience (30-odd years in my case) which says that in the real world, code is frequently badly structured, badly written and an unmaintainable and unmodifiable mess.

Again, that's not to say that the Kindle firmware is such a mess, just that to assume without knowledge that it isn't is perhaps a tad optimistic.

/JB

And this design might actually be good if all fonts do not render properly for all sizes.

[HarryT]

It's perhaps worth noting that the Kindle's font sizes aren't absolute, but rather multiples (and divisors) of the base font size of the book. Change the size of the base font in a book, and all the sizes change on the Kindle.

[jbjb]

Originally Posted by tompe

And this design might actually be good if all fonts do not render properly for all sizes.

Indeed it might.

/JB