Why can't I highlight individual words but instead have to highlight entire verses?

Being able to highlight individual words is on our suggestion list, but it's harder than you think. Let me just throw out a few issues off the top of my head. I'm not inviting discussion or solutions; I'm just giving you an idea of why it's complicated.

In order to highlight individual words, we need to be able to identify each word. The obvious solution is to call the first word in the verse "1", the second "2", etc. Complication #1: What about footnotes? These are encoded in-line with the text. If you count the words in a footnote, then suppress (hide or collapse) the notes, there's not an easy way for the program to know what the word count should be for the first word that follows the footnote (because the note is not there to include in the count).

To store highlights in a database, you have to decide between at least three solutions: 1) Store the verse and word number where the highlight begins and the verse and word number where the highlight ends along with the highlight color in one record; 2) store the "transitions" -- that is, store the verse and word number where the highlight starts in one record, then, in another record, store the verse and word number where the normal background color resumes (for a total of two records per highlight); or 3) store the verse and word number along with the highlight color for each word that is highlighted (for a total of one record per word).

Complication #2: Size of the database. If you use option 1 and only highlight one word at a time, the start and end word numbers are the same (and thus redundant) but they have to be stored, making each record bigger. If you choose option 2, each record is small, but there are two records per highlight (which is actually more space in the database than putting the same information in one record). Option 3 is optimized for highlighting single words, but if you highlight an entire verse it creates one record per word. So if you highlight the entire Bible in one color, option 1 gives you one large record, option 2 gives you two small records, and option 3 gives you over 700,000 small records. If you highlight every verse a different color, option 1 gives you 31,102 large records, option 2 gives you 31,103 small records, and option 3 still gives you over 700,000 small records. If you highlight every other verse, option 1 gives you 15,551 large records, option 2 gives you 31,102 small records, and option 3 gives you over 350,000 small records. Storing one highlight record per verse gives you a size that is never worse than any of these three options but can be as much as 95% smaller.

Complication #3: Access speed. You have to ask the database to tell you the color of every word in every verse you display. This means doing at least one and potentially more database queries per word that is displayed. Since there are about 25 words per verse on average, the time it takes to highlight a verse is as much as 96% faster if you highlight by verse instead of by word. If it currently takes about a half second to display a page of text, that means it could take 10-12 seconds to display a page if we have to look up the color of every word.

Complication #4: Different platforms use different display technology. In the old days (up to and including PocketBible for iOS) we used an HTML rendering engine I wrote. My rendering engine is very tightly integrated with our LBK files and our user-data databases (notes, highlights, and bookmarks). I can very easily associate a word number with each word I display. (That's why early versions of PocketBible (Windows CE and Windows Mobile) could offer word-by-word highlighting.) MyBible for Palm OS had a unique display engine and couldn't access our LBK files at all. The Bibles in MyBible did not go through the same process (BookBuilder) as our books for other platforms. Therefore there was not necessarily a connection between word numbers in the NIV in MyBible and the NIV in PocketBible for Windows CE. Today, our Java version of PocketBible for Android and the Objective-C version of PocketBible for Mac OS X both use the built-in HTML rendering engine and CSS to display the text. It has ready access to our LBK files and user-data databases, but it has to "decorate" the HTML it sends to the built-in rendering engine with tags to mark every word with its word number. This dramatically inflates the size of the HTML we send to the viewer (at least tripples it in size) and increases the parsing and rendering time. PocketBible on Windows Phone and Windows RT has to translate the HTML in our LBK files to XAML or some such thing -- I didn't write it and don't understand it -- and the problems are similar... adding the mark-up required to indicate word numbers would just slow it down.

Complication #5: Determining the range of selected text. On some platforms, it is virtually impossible to connect selected text in whatever rendering/viewing object we're using with a particular verse and word. On platforms like Android, it can be easily determined on some devices from some manufacturers running some versions of the OS, but the same method doesn't work with the same version of the OS on a different device, even a different device from the same manufacturer.

Complication #6: Determining the color of a particular word. It is difficult, if not impossible, to determine the color of a given word if we store start verse/word and end verse/word (options 1 or 2). There are Bibles in which the verses are numbered 1, 5, 2, 4, 3 in a chapter. A highlight that STARTS at verse 4 and ENDS at verse 3 would appear to be invalid (since verse 4 comes AFTER verse 3 in most Bibles). But in this Bible, not only is it valid, but it implies that verse 4 is also highlighted.

Complication #7: Synchronization. The solution you choose for your database schema also needs to take into account synchronization across platforms. If you use one of the start/end solutions (options 1 or 2, above) it is VERY complicated to figure out how to synchronize highlights. Imagine if you highlight verses 3-5 in pink on one device, then highlight verses 1-7 in blue on another device, then delete the highlight on 3-5 on the first device. If you then sync both of those devices with the server, what color should verse 4 be? I can argue that it should not be highlighted (because the pink highlight was deleted after the blue highlight) or I can argue that it should be blue (since the pink highlight was removed). This is different than, say, notes. If you write a note on verse 4 on the first device, then write a note on verse 4 on the second device, then delete the note on verse 4 from the first device, then sync, the note will be deleted because the last thing you did on verse 4 was delete its note. The reason it's different than highlights is that you can end up with "holes" in your highlighting which, while correct, are weird and it's obvious they're weird.

Very few Bible software companies these days, especially those that try to maintain your data across platforms and across Bibles, offer word-level highlighting. Those that do have easily observable bugs in the display and synchronization of their highlights. These are only a few of the reasons why. Hope this helps.

Can't Find an Answer?

Send us an email with complete details of your problem and we'll do our best to help. Contact us at support@laridian.com.