highlight search terms in flipbook links

I spoke with Todd about this and have a few notes about where the relevant files are, but we should discuss it with him again if we can.

I made some progress on this today with help from Steve, Raj, and Hank. Current plan:

1) Get search term parameter in flipbook.php and pass it to interface.js initialization routine. This is working in my test setup and the search term highlights but it sometimes causes undesired navigation inside the flipbook.

2) Find some way to stop the undesired navigation. (Or in the underwear gnome biz plan, "2. ????").

3) Firebug reports an error due to a 404 from a missing reviews url. Not sure what's up with this. Nothing visibly bad happens on the screen.

4) The server side flipbook search creates a lot of yellow tabs on other pages where the search term occurs. This at first sounded like a good idea but if the term occurs a lot, then it clutters up the display, so maybe they should be suppressed somehow.

5) Get the displayed page numbers in the search results to be actual page numbers rather than leaf numbers or spread numbers. One way to do this is rebuild the pagetext SE index so that the correspondence is included in the search result. Another is for flipbook itself to do the mapping, using a mechanism that I think exists but maybe doesn't fully work at the moment. Doing the mapping in flipbook is maybe conceptually cleaner, but might be trickier to do without more flipbook knowledge. So this is an open question for the moment.

Search highlighting now works in the development cgi, except it bypasses the openlibrary.org/details framing page, so the browser points to the internal frame page which has the actual node number and a complex url including the spread number and search terms. The spread number is still erroneously labelled as a leaf number. It looks like some occurrences of search terms in the book text are missed in the SE. Also some of the SE hits actually occur on the found page, but fail to highlight. I'm not sure what the cause is of these problems but would consider them non-critical.

>Search highlighting now works in the development cgi ...

How does one access the development cgi?

Replied to webchick by email.

All of the above hacks are obsolete because of Raj's cool new book reader which will handle highlighting parameters more straightforwardly. Separately we will figure out how to set up a search API so the new book reader can call solr instead of grepping the djvu txt for user searches.

can we close this one out?

This will be possible once we have the new URL syntax for the GnuBook book reader. Currently AFAIK there is no way to pass in the search terms.

It's up to you. I left it open on the theory that the fix is to switch to the new book reader, so we should close it after the switch. We could instead interpret it as a bug in the old flipbook and close it as "won't fix" (since we are going to replace the old flipbook rather than fix it).

This is the pretty permalink URL feature request in GnuBook: https://bugs.launchpad.net/openlibrary/+bug/302656

I cross-linked that bug so it appears in both projects. I haven't seen a way to make a bug depend on another one.

GnuBook now has pretty permalink, it doesn't yet have a way to pass in search terms to highlight, it shouldn't be difficult to implement.

* Adding /search/cats to the book URL should trigger a search for "cats"
* /search/cats should appear in the URL when that term is highlighted on the current page (1up) or either page in view (2up)
  * The search terms should not appear in the URL when you move to a new page that does not have the search terms on it
* Adding /search/cats+dogs to the URL should trigger a search for "cats dogs"
* The search term entered in the URL should also appear in the search text box

Here's an example: http://www-mang.archive.org/stream/photographyinstu00estauoft#page/86/mode/2up/search/green

Not working in IE7/XP. Is working in IE8/XP.

Fixed on IE7. Doesn't like trailing comma in object property definitions.

All of the items in #12 are true on all systems. I tried many modes and combos.

I did see some strange search stickiness in Vista/IE7 but not XP/IE7 nor IE8. It seemed the behavior was this:

In Vista/IE7 I would search on a term, and *if* the term appeared on the current spread, everything rendered fine.

If the term existed but did not appear in the current spread, I could flip to a page where the term appeared and see it highlighted, but
the sidebar would continue to display "Searching..." indefinitely and did not present the results. Nor would the /search/term/ appear in the URL.

Perhaps it's related to the speed and/or this particular Vista machine, but this did not happen in Vista FF or XP (VMware on another machine) IE7.