highlight search terms in flipbook links

Bug #126611 reported by Aaron Swartz
18
Affects Status Importance Assigned to Milestone
Open Library
Fix Released
Low
Unassigned

Bug Description

As long as we're modifying the flipbook, it'd be nice if we could feed it a query and have it highlight search terms and other pages and so on.

See also bug 121623

Revision history for this message
solrize (solrize) wrote :

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.

Aaron Swartz (aaronsw)
Changed in openlibrary:
assignee: nobody → solrize
importance: Undecided → High
status: New → Confirmed
solrize (solrize)
Changed in openlibrary:
status: Confirmed → In Progress
Revision history for this message
solrize (solrize) wrote :

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.

Revision history for this message
solrize (solrize) wrote :

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.

Revision history for this message
webchick (webchick) wrote :

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

How does one access the development cgi?

Revision history for this message
solrize (solrize) wrote :

Replied to webchick by email.

Revision history for this message
solrize (solrize) wrote :

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.

Revision history for this message
Matt Work (mwork) wrote :

can we close this one out?

Revision history for this message
mangtronix (mang) wrote :

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.

Revision history for this message
solrize (solrize) wrote :

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).

Revision history for this message
mangtronix (mang) wrote :

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.

Changed in gnubook:
assignee: nobody → mang
importance: Undecided → Medium
status: New → Confirmed
George (george-archive)
Changed in openlibrary:
status: In Progress → Confirmed
Revision history for this message
Edward Betts (edwardbetts) wrote :

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.

George (george-archive)
Changed in openlibrary:
importance: High → Low
mangtronix (mang)
Changed in gnubook:
milestone: none → 0.9.16
Revision history for this message
mangtronix (mang) wrote :

* 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

Changed in gnubook:
assignee: mangtronix (mang) → Bonnie Real (bonnie-archive)
status: Confirmed → Triaged
tags: added: needs-qa
Revision history for this message
mangtronix (mang) wrote :

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

Revision history for this message
mangtronix (mang) wrote :

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

Revision history for this message
Bonnie Real (bonnie-archive) wrote :

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.

tags: added: qa-verified
removed: needs-qa
Changed in gnubook:
assignee: Bonnie Real (bonnie-archive) → mangtronix (mang)
Changed in openlibrary:
assignee: solrize (solrize) → Edward Betts (edwardbetts)
mangtronix (mang)
Changed in gnubook:
status: Triaged → Fix Released
Changed in openlibrary:
assignee: Edward Betts (edwardbetts) → nobody
Changed in openlibrary:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.