Ixtab,
About the hyphenation, I have realized that my corrections also bring some unconveniences: the no-hyphenization of certain words. You may, please, roll back to the all-original hyphenation file for portuguese, even if it is not perfect (as you say, if there is not a dictionary, it can't be perfect).

Ixtab,
About the hyphenation, I have realized that my corrections also bring some unconveniences: the no-hyphenization of certain words. You may, please, roll back to the all-original hyphenation file for portuguese, even if it is not perfect (as you say, if there is not a dictionary, it can't be perfect).

Thanks!

Hmmm... so you're saying, reset the pt localization to the initial version? Well ok, if you say so...

Hmmm... so you're saying, reset the pt localization to the initial version? Well ok, if you say so...

Unfortunately, that is the case. It is better to have a little imperfection than not having some hyphenation (and I don't know how/if it is possible to do the thing other than by a clunky word-by-word basis).

To explain, in portuguese the syllables for these words are:
"quin-ta"
"qui-na"

The original hyphenation file makes it:
"qu-in-ta"

My correction adressed it and makes the right "quin-ta", but then it also does not allow the hyphen of "quina".

Well, that's it. Maybe it's just a matter of taste, but I prefer the original, even with that little flaw. I'll let everybody know if I discover something.

Last edited by Antoinekamel; 01-05-2013 at 11:33 PM.
Reason: Modified the example.

Setting font size to 15 does not work with .azw3 book (while 14 or 16 is OK).
I cant' figure out why!

The .azw3 files display is handled by a native application (webreader), not in Java, so I cannot really control what is happening there. That is also the reason why the hyphenation patch doesn't work for .azw3 files.

That said, what do you mean by "does not work"? Does it crash the device? Does it display naked women? Does it show nothing at all?

So, here's version 3.1.0 - both for the Touch, and for the Paperwhite.

This version now includes all available Paperwhite patches, and a few (small) improvements affecting the framework itself, and the overhauled patches.

In one sentence: whether you use JBPatch on the Touch or on the PW: update to 3.1.0

Yay works good. Upgraded from 3.0.0 and it even remembered all the settings. The first time I opened a book it showed an error message. Try again, good. It was that same error message you get when you try to start an invalid app. Works now, so all good.

Yay works good. Upgraded from 3.0.0 and it even remembered all the settings. The first time I opened a book it showed an error message. Try again, good. It was that same error message you get when you try to start an invalid app. Works now, so all good.

edit: The error was on PW, so not sure if that matters.

Got same error, but KT and with version 3.0.0
After clean install 3.0.0 copied new com.mobileread.ixtab.patch.dictionaries.jar (pre 3.1.0), then (I'm not restarted my devise) used dictionary lookup -> more -> back button -> error. It appears only one time and after that, not get that error (tryed repeat) anymore. Book was azw3 and same what give me "download again" error previously, when margin patch was active.

FWIW, I also got a similar error "the content could not be opened" or so right after updating my Kindle Touch to version 3.1.0. Rebooting the device seems to have fixed that, too, and it never reappeared.

As hard as I try, I can't come up with an explanation, let alone a solution. JBPatch patches do exactly one thing: modify java bytecode after it was read from a file, but before it is actually interpreted as bytecode by the JVM. These modifications are deterministic - either they don't happen at all, or they happen in the exact same way, every time. In other words: if a patch was the culprit, then it would either fuck up every time, or never.

The only thing that I can think of which might influence the whole procedure (attention: wild speculations ahead!) is the /var/local/java/default folder, which seems to contain cached(?) copies of some java classes. I never figured out what that folder is good for. And the Java VM that the Kindles use seems to be closed source, i.e., cvm isn't documented (AFAIK; but I dimly recall that either twobob or knc1 had at least a bit more insight into where it comes from).

Continuing with the wild speculation: it might be that the VM tries to use a cached class together with a "newly patched" one. And it might be that a restart (or actually, a crash which is noticed by whatever caches things, and then tells the cache to empty itself for the next reboot) fixes these issues.

I don't know... I honestly don't know what the Kindles are doing. All that I know is that the JBPatch framework, and the individual patches which are released, are 100% compliant with the JVM specification, and correctly do what they're supposed to do. Why the framework around them is crashing is beyond me.

Sad but true: the "Windows approach" seems to help - "If it doesn't work, reboot. If it still doesn't work, reboot again."