PRS+: Enhanced firmware for Sony Reader, Folders, Games & more

[Arrghus]

Originally Posted by elcreative

It's computer sorting... uppercase letters precede lower case in a straight computer sort...

Folders aren't sorted that way on my Windows XP machine. If I browse my Calibre library by folder on my computer, each author is sorted in alphanumerical order, regardless of starting case.

[elcreative]

Originally Posted by Arrghus

Folders aren't sorted that way on my Windows XP machine. If I browse my Calibre library by folder on my computer, each author is sorted in alphanumerical order, regardless of starting case.

And that's because it's been set to do that... a BASIC sort is done by ASCII code where Uppercase letters have lower ASCII numbers than the Lower case and that's how it sorts... high to low.

Since humans actually prefer a different method then the sort method is tweaked to give the results you see on your Win XP machine but I thought you were talking about your reader computer not your computer computer!!

[DoctorOhh]

Originally Posted by Arrghus

Folders aren't sorted that way on my Windows XP machine. If I browse my Calibre library by folder on my computer, each author is sorted in alphanumerical order, regardless of starting case.

elcreative is correct a straight up ASCII sort has uppercase preceding lowercase. I have run into this on my media converter box as well, the question is if there is a way to alter this within PRS+ browse folders or not.

[Mark Nord]

It is already altered.
This string-compare-code is taken from model-config.js

        compareStrings: function(a, b) {
                if (a === b) {
                        return 0;
                }
                return a > b ? 1 : -1;
        }

I suppose this was done to enable proper sorting of cyrillic titles & authors.
Simply changing

compareStrings: function(a.toUpperCase(), b.toUpperCase())

, will work for standard roman-style titles, but will break the functionality for cyrillic, as toUpperCase() will fail to return the proper uppercase character.
I think I remember that boroda (porkupan) has set up a special toUpperCase function covering cyrillic in his firmware. Maybe we can lend this code and put it in.
For strictly western-style author/title just try to use toUpperCase() and build your own installer/ your own beta-test-pack.

This may or may not be related to issue #128 on the project-page.

[jackie_w]

Originally Posted by Arrghus

When browsing by folder on my PRS-350, authors with names beginning with a lower case letter (I read lots of works published under a pseudonym or username) are pushed to the bottom of the list (i.e. An author with a name like 'acorn' would be listed below a person called 'Zelda', for instance).

As you're using Calibre you could also try modifying your Send-to-device Save Template slightly.

As a very simple example, if it was currently set to

{author_sort} - {title}

try this instead:

{author_sort:titlecase()} - {title}

[kartu]

Originally Posted by Mark Nord

I suppose this was done to enable proper sorting of cyrillic titles & authors.

Georgian as well.
Note that ignoring char case is not always desired.
Somewhat optimized "case insensitivity" is introduced in scrollbalalphabet.js.

Multi-lang support for sorting in Books is yet to be written. (check UCB.so, I don't have sources for it) Would be nice to have compilable *.c to be able to add support for more alphabets. Country specific collation would be tricky.

[soondai]

What a great project.

I just wanted to verify that this firmware does not offer additional font sizes for the PRS-300. That's my only real complaint about my reader (would love something between the small and the medium).

Saw no mention of it, but just wanted to verify. I'd flash it to check myself, but it sounds the 300 is the only machine where you cannot easily revert.

[readingglasses]

Originally Posted by kartu

readingglasses

Let's turn it into some plan for PRS+.
Drawing on the screen to find similar looking chars, while certainly possible, is highly unlikely to be implemented.

1) Keyboard + usual dictionary lookup - will certainly be implemented
2) Keyboard where multiple chars produce single one + dictionary lookup - isn't much more work to do.

Doesn't 2) also cover Chinese? Have in mind, that different lookup methods are actually different dictionaries. (by radical, by number of strokes etc)

PS
It's amazing how inefficient hieroglyphic system is, yet it is still used. Kudos to Koreans for dropping it.

Well, jumping from a request to devising a plan is kind of a leap for me. I'm currently "educating" myself on all the required skills/data. So I'll come up with some ideas but it might be a few more days.
"2" does cover Chinese and it covers at least a couple of different methods of input. But, as I'm sure you're aware, this isn't like mere combining of characters in latin character based multinational "postfix" or "prefix" notation where apostrophe + letter 'e' = acute accented e.
Again, I haven't looked at the code for the open source IME's to see an example of how they do it but there is sure to be an intermediate stage of set selection based on some kind of indexing. The input methods that currently exist just don't seem specific enough to be able to select an exact character, there always has to be a list. Even the phonetic tone notation isn't unique. There may be several characters with the pronunciation guo3 or any other sound.
So, you could have one massive set of characters with field entries (definition, pronunciation, component glyphs or radicals, even etymology of the character and anything else you can think of, applicable to any language, not just chinese). A font has the characters (w/o the definitions, obvsly.). But a "dictionary" would be defined by how that massive list is indexed or sliced up. So it isn't enough to have a dictionary for lookup, by itself. Another kind of dictionary, would be already running for the chinese input. It wouldn't have definitions but it would have, say, what kind of strokes in what position apply to some subset of the massive total list (the wubi method) or what component characters of a "chinese keyboard" might add up to a set of possible entries etc.

This could work with following multiple node "trees" of an index and set selection, leading down to a final (set of) characters.
Either as a fairly complex "table of contents" or "conditional statements" in xml or javascript (which seems to be? what the prs-plus uses)

... or, if the battery can provide the power, an sql daemon and database running. Either started up each time you are using the chinese dictionary (a slow start up, maybe have a option to start and stop it as the user wishes, not each time the chinese keyboard is invoked or the dictionary started) or running all the time (no idea if, once it's "loaded in memory" and passively waiting, it uses much memory). Also, if memory constraints/file sizes for apps are an issue, I have no idea which method is better, at this point.

Although chinese users of prs-plus (and enterprising chinese language learners) would be comfortable using such a keyboard and would likely use the entire device then as an electronic dictionary for any writing they encounter (in the street, at work, entertainment), I see little value in this method beyond being an exciting challenge to implement, if the dictionary is "meant especially for" documents on the device, where tap and automatic look up are far more convenient in the case of a touchscreen. But who says there should be limits on how a device is used?


Tap and automatic lookup could just order a set of , for example, unicode codes for each character by line number. And then a kind of process like:

go to {unicode code of tapped character == dictionary line number).

The displayed dictionary of definitions would still be either a multi level contents ebook file in that case.

Everything about an unordered (or mostly unordered) set of characters, rather than alphanumeric total ordering from alpha to omega, means that set indexing, in more than one way, must be dealt with, one way or another. We're way beyond the ascii alphanumeric dilemma above, obvsly.

A terribly inefficient thing from a programming point of view. And for writing by typing. But for readers who are good, the writing itself can be read much faster than an alphabet system. I assume, because I can only test it for the few characters I know.
The fancy writing is fun, too. And for "sloppy" cursive writing by hand (not neat printing), before computers, also faster than spelling out a word like an alphabet does.

This would be portable to japanese. And Japanese users would use it the same way. Even koreans could use it for their rarer encounters with chinese characters in older texts, names, the rare newspaper use, or a fancy sign.

It's funny to think that this might bring a japanese dictionary to a japanese product by sony. And brings up the confusing questions about open source hacking. But that's another discussion.

[readingglasses]

Obvsly, a programming benefit of keyboard input instead of tap and look up is that it builds on the existing codebase by Mr. Clemens. And who wants to replace Mark Twain?

[readingglasses]

In my usual selfishness I kept thinking only that the x50's don't have a dictionary while earlier models' dictionaries are "done". I completely forgot that complex scripts and logographic languages are not available on the earlier prs+ firmwares' dictionaries.
So, obvsly, a keyboard input is to do, in order to provide the facility for all models. And a character based one at that, for guessing/deciphering visually, not a latin alphabet, which would be irrelevant.
But a touch option should exist for the later models, at some point.

I may have said above but I'll say again as it hits me: to keep the memory footprint low, a set of indexes can refer to separate files for each field of a definition (character, meaning, pronunciation). Or one can separate sections of a dictionary (not by field but by range) into files. That is, if size is an issue for any reason.
So a "table based" input or a list based one would be the search. Once the user selects a character, then all the indexes can come into play and bring up the fields from any number of sub files of the dictionary.
Now I'll get back to "educating" myself some more.

[surquizu]

Hi Mark and Ben,

1.-The function of StandbyImage works well in books epub and pdf, but does not work in books LRF. Cover usually appears after several seconds, but only once. Sometimes twice. Then, just blank screen appears without the cover of book.

2.- Can you explain to serve the option "Dither Image"?

[Mark Nord]

surquizu

ad1) have to admit that I hadn't tested with LRF, will try to have a look.

ad2) Dither is a specific algorithm to render a full-color picture in gray-scale. Some gradients are shown a little different with/without dithering.
As the book-viewer is used to render the Standby-Image no additional dither should be required, so that it is save to set this option to OFF.
Hope this maks sense.

[VICTORSJG]

Kartu, do you know is it posible to explore pictures, and songs into browse folders, modifying this lines like on others model or is there any way to do it? In feature requests i've seen the support pictures in browse folders was done but i don't if for all models (line 16 feature requests issue done?

https://www.mobileread.com/forums/sho...&postcount=470

thanks

[kartu]

Hi Victor,

yes it is possible on all models and should already work for some models (don't remember which).

[readingglasses]

RE: east asia han character dictionary.

This is taking a long time and it's going to take me a long time. But since I'm already looking into it, I'm thinking this should be an opportunity to indeed create a more sophisticated dictionary format for prs. Not just searchable by fields but even morphology analysis.

Yes, language learners and those with difficulties immediately benefit from a simple dictionary lookup of strings as words.

But a dictionary that used some modular lists and indexes to look at more than one database has the benefit of providing an eink and ultra portable slate medium to a system, like this:

http://en.wikipedia.org/wiki/Text_Encoding_Initiative

http://www.perseus.tufts.edu/hopper/opensource

http://www.perseus.tufts.edu/hopper/...3a1999.01.0227

click on any word, you get a whole linguistic profile of that word.

Of course, battery power becomes a problem. But as a project, this interests me. Then I'll worry if it can be done without being connected to usb. And if it needs more power, just connect a battery pack over usb cable and all the troubles and workarounds needed to do so with sony prs.
who knows? maybe the T1 will allow easy usage while plugged in and it won't be problem for later models.

As for details. so far, it seems that m17n library on linux would be, in terms of programming, the easiest choice. Just to be ported to prs. My impression is that other IME graphical inputs are like "front ends" to m17n.

http://www.ibm.com/developerworks/linux/library/l-m17n/