Quote:
Originally Posted by jbjb
Do you actually know that is the case, or are you just assuming it?
There are many feasible implementations which would make it harder to add intermediate sizes. For example, the font selection code could return an enumeration from a fixed set, where the actual numerical values of that enumeration are arbitrary - adding a new value to that set would involve adding code at every place where that enumeration was used. Or, it could return an index into an array of font descriptors, and other code may make assumptions about the size of that array. Or, any of many other ways. Even if it does return a number which maps directly to the numerical size of the font, it could be that the units of that number are such that it doesn't have the resolution to represent intermediate sizes.
I'm not saying it isn't as you describe, just that unless you have actual inside knowledge of the code, you can't assume that it is - there are many other ways of doing it.
/JB
|
Kobo works that way because when we change the numbers, we also get font sizes with those new numbers. So yes, it does work that way. If you give the a number in the code of the eBook, it works that way. So unless someone says it doesn't work that way, there's no proof it doesn't work that way. Why would it work allowing a number to be passed from the eBook to the system for a font size and not work that way for the font size selection? That's just stupid. Sony Readers starting with the T1 also worked that way as the fixed font sizes in the selector was a number passed to the system for the font size. So why would Amazon do it a much harder way? They would not. But they are too lazy to give more choices.