Gospel Library "Real Page" formatting

I think a lot of people like the integrity of physical scriptures but long for the versatility of digital. How many times, when in a discussion about the Book of Mormon have you heard "I don't remember which verse it is, but it's on the left page, right column, about half way down." and they were able to find the verse they were looking for.

I would like to see the scriptures in a two-page, landscape view on a 10" tablet (one-page, portrait could work for 7" tablets) formatted exactly as they would be on a physical copy of the scripture (ex. Alma 13:14 is on the left page, left column, bottom verse of physical scriptures. Alma 13:31 is on the bottom of the right page, right column. They should be in exactly the same place on the tablet screen), but with the features currently on the app: highlighting, footnote links, etc...

What do you guys think? I've got some more ideas for navigating and such, but as far as the base ideas go, what are your thoughts?

To add to the concept but still make the text easy to read on small screen formats a view option to toggle between small screen format and page width format or even full page format, as in print copy, would cater to both needs. Without the small screen format capability there would be frustrated small screen users. Reading would require not only up and down scrolling but left and right scrolling. Left and right scrolling can make reading difficult if not distracting and frustrating.

The page width format is the same view option available in word processing programs. The page fills the screen left to right but may require vertical scrolling to see an entire page. Depending on screen orientation, portrait or landscape, and overall screen size, the font size could be a problem.

Full page width format is again the same view option as used in word processing programs. The side effect of full page is font size changes that could make the page unreadable due to quite small font size. This may not be a problem with larger screen tablets, but font size would be quite small on small screen mobile devices.

Overall the idea has merit. But development is done for operating systems and not necessarily by device. So tablet users may not have problems with the number of screen views available. Small screen users may not see an advantage to the variety of screen views.

I envisioned this to be a 10" tablet interface because that is about the size of a Book of Mormon. 7" devices wouldn't be too hard if they only displayed one page portrait, but the idea would be frustrating for smaller screen sizes. The toggle option would definitely make the app more accessible for all users.

Here are some of my thoughts about the interface.
As I stated, the main view of the interface would look exactly like 2 pages of the Book of Mormon. At the top left and top right of the screen is the page reference. When pressed a drop down menu appears with each book of the Book of Mormon which when individually pressed will then show a menu for Chapters, and so on for verses.
When pressed the page numbers in the center of the screen drop down a 10 keypad for entering a page number.
All footnotes are shown at the bottom of the page just as they are on a real Book of Mormon and when pressed open up their link.
Page scrolling would work the same as gospel library except that if you swipe your finger across the screen but keep your finger on the screen, it will continue turning pages quickly.

Probably the best thing you are going to find for the functionality you are looking for in the near term is to go to LDS.org and download the PDF version of the scriptures. You can then utilize Adobe Reader to view the scriptures. Same page layout and everything and in reader you can usually zoom and choose to have side by side layout if the screen is large enough.

Speaking for the Android app, it really isn't being looked at to have a "native" layout of the content. Maybe as mobile technology matures and developers have time, this might be a possibility. It won't happen soon though unless somebody with the time and ability starts to work on it on their own.

A PDF version is a good suggestion for formatting, but I think the request is to have the formatting while still having the functionality of the Gospel Library App.

jasonhyer wrote:Speaking for the Android app, it really isn't being looked at to have a "native" layout of the content. Maybe as mobile technology matures and developers have time, this might be a possibility. It won't happen soon though unless somebody with the time and ability starts to work on it on their own.

I think this is what landonhale is hoping. This is the Ideas and Suggestions section of the forum. I really like the idea of "real page" formatting. I'd work on it myself, but I don't have any way to work on it for the forseeable future. Maybe you're right and it won't be touched for a while, however, I still think we could have a good discussion on how this could work.

I see this going two ways right now. Either this layout would be implemented into the options of the Gospel Library app, or it could branch off of the Gospel library and become a separate app of only the Standard works. That way we could alter the GUI and formatting of the app, but still maintain some of the backend, for instence how highlighted scriptures are synced with one's LDS account.

I would absolutely love this. Any word on anything that's been done since the original post?

I love that page numbers have been added to the Scriptures in Gospel Library (I am on Android Version). I wish there was another mark that identified the end of the first column on each page. If we had that, at least someone could easily identify the top and bottom of each column.

If we had this, you could tell someone "the verse is half-way down the left column" and they should be able to find it.

Page formatting identical to the paper version isn't just a "nice feature" request. It's essential. Many of us have experienced diminished value of scripture study, particularly with retention, after using the electronic version. Recent research has demonstrated that this is true. We retain information better when we have spatial indicators. Left and right pages, left and right column, and position within the book, are all spatial indicators. With our software, we have an opportunity to potentially create more spatial indicators than with paper, but currently we have much less. I've gone back to paper.

The scripture database that is accessible to the public is html files in a sqlite database. I'm thinking about how to reformat the files. My first thought is to have unclosed <div> statements in each file. The next chapter will close the <div> statements. The software will have to read a file and count the <div>'s. It may need to read the chapter before and/or the chapter after in order to fill the page. At least four distinct <div>'s are needed for text only: Left page, left column; Left page, right column; Right page, left column; Right page, right column. Footnotes will require more <div>'s, but that can be postponed because they are not part of the chapter files. The software will have to generate a new html file from a combination of multiple files.

It will be tedious to modify the database. It probably should be done with a long script, partly because it will be easier, and partly because the database will likely not be redistributable due to licensing. Each user will have to run the script to modify their own copy of the database. At some point, the Church may adopt the modified database or their own variant and allow it to be redistributed, but we can't count on that yet.

The Church may have an easier way of regenerating the database, but I'm not sure of that. This may be tedious for anyone.

Absolutely portable. Maybe ncurses to begin with and Kivy or Xamarin in the long term. I'd prefer python, which implies Kivy, but someone with more experience with multiple cross platform development environments could convince me otherwise as long as it is easily portable and fast. I'm not willing to invest time in a single platform.

I'm thinking open source.

I'm an engineer, not a computer scientist, which means I tend to plow forward with something that should work, but may not be the latest and best method. I would be happy if someone has suggestions for a better way. Thinking long term, more spatial indicators could imply 3D rendering, page turning, views of the entire book of Isaiah showing where your markings are, length of each chapter in the book of Isaiah in column format, and anything else you can imagine. So it should be fast and efficient so as to minimally drain the battery of portable devices. The object is to provide more spatial indicators, rather than less, to facilitate learning and retention.

Spatial indicators would definitely be a great step forward, but "page formatting identical to the paper version" is not the last word on spatial indicators. In a few generations hardly anyone will remember what the paper version looked like. Hopefully they'll have new spatial indicators that are appropriate for the new medium.

Instead of open/close <div> tags, which could cause problems in other places, you could use <hr> tags or something similar to act as a break. Like,

Wherefore, it came to pass that my father, Lehi, as he went forth prayed unto the Lord, yea, even <hr type="column-break" page="2" column="1" />with all his heart, in behalf of his people.

The <hr> tag could be set to "display: none;" for reading without page/column breaks.

https://github.com/bradporter/OpenSticks

It works for scroll format on linux. I use it in Sunday School.

Real Page formatting was the goal. There was a snag when the new database format came out last year. Some html tags in the new database were switched around and it broke the conversion program. Easily fixable, but this is going to require some coordination with Church developers as to what will change and what will not so the conversion program will only have to be written once. Alternately, it would be amazing if there was a convenient way for them to add the required div's since the current method in bomconv.txt is rather tedious. (There might be some code out there that already knows where the column breaks are??).

The scriptures content isn't marked up with column breaks, but it does have page breaks marked, because they're used to show page numbers in the right margin. You can see how it's marked up by going to this page and using the browser inspector to see the code for the page numbers (for example, the "2" in the right margin): https://www.lds.org/languages/eng/conte ... ofm/1-ne/1
You could get an approximation of column breaks by dividing the content between the page breaks in half, to the nearest word or verse. Is that how you're currently setting the column breaks?

sbradshaw wrote: You could get an approximation of column breaks by dividing the content between the page breaks in half, to the nearest word or verse. Is that how you're currently setting the column breaks?

No, I was generating a script to modify the database by adding div open and close in a modified database on a per column basis. This script does not use the pagebreak span class. Using the pagebreak span class instead would still seem to be a considerable effort. Paragraphs would have to be closed prior the <span class='pageBreak' ...> I think bodyBlock would also have to be closed and reopened after the pageBreak. Probably, the span should be changed to a <div id="columns_2" ...> and then closed just before the next pageBreak tag, with column_2 being just #columns_2 { columns: 2 8em; }. Sometimes it appears inside the heading instead of the bodyBlock, a separate challenge. It might be difficult to get the chapter summary, which is in the heading, as part of the 2column format. I'm not sure it would be much easier than what I am doing and might be less similar, aside from whether the column break is in exactly the right place. I'll give it a little more thought.

Did anything ever come of this? I agree that it is essential

Yes. I did take sbradshaw's advice to use page breaks and basically gutted the previous method. I made significant progress a few years ago on a cross country flight, but did not pick it up again until a few months ago. There is still at least one bug (who knows). I think it might be close. I should post what I have on github. I think it's really not that hard, just hard to to find time to focus on it.

When the tech dept asked for feedback in an email last year, I sent back the following in their form as a feature request. I didn't hear anymore.

***********************
Time stamp on text file backup is Feb. 2, 2025, which is presumably the date I submitted the form ***********************
...

The following links are useful for the remaining notes.

https://www.psychologytoday.com/us/blog ... -e-readers
https://www.taylor.com/blog/printed-boo ... prehension
https://www.techlearning.com/news/ebook ... -takeaways

Scriptures in two column per page, left/right pages, with the same page breaks as the standard works print edition. Spatial indicators assist in memory recall. The common "scroll" format loses an important spatial indicator. This is a trivial matter if reading a novel which will never be read again, but with books which will be studied for a lifetime, page breaks are needed which are consistent with the printed version. An electronic book should be an opportunity to provide more spatial indicators, rather than less, to facilitate learning, searching, and retention. "An Ebook Can Outperform Print Version with the Right Enhancements" (https://www.techlearning.com/news/ebook ... -takeaways)

CSS Images to illustrate book gutter, column partitions, and page edges. "Reading from a printed page provides spatial and tactile cues that help the reader process the words, allowing for better concentration and understanding. One study showed that 92% of those surveyed found it easier to concentrate when reading print." (https://www.taylor.com/blog/printed-boo ... prehension)

Additional spatial indicators can be imagined, for example:
Edge of page markers which change size depending on how far along in the book you are, to simulate the feel of "half way through." Book tabs.
Flipping page turning.
User defined outline markers which may add a character, or optionally show the text in scroll format with indentation and outline headings.
Showing the entire book (Isaiah, for example) in tiny print, one chapter per column, showing where user specific markings are and/or user specified outline indicators.

Date stamp for highlighting, and selectable dates for showing highlights (a lifetime of highlights).

Addition of large notes to the database with added footnotes at the bottom of the page or as links. Could be
Javascript sticky notes in the margins. "As one example of focused engagement, readers of the printed page often write notes in the margin as they go." (https://www.taylor.com/blog/printed-boo ... prehension)
These "sticky notes" and other markings should be stored in the cloud only as an option. A local database should also contain these notes with the option to back them up in the cloud, but not necessarily. Scripture study is a very personal activity for some.

Needs to be easy to add new references to existing footnotes in addition to creating new footnotes.

Margin symbols to identify topics. (Temple, family, love, obedience, etc.)

Integration with a timeline app (to create your own timeline for personal study).
Javascript which could work on mobile devices: https://timeline.knightlab.com/docs/ins ... eline.html
Desktop python which works best as a stand alone app: https://www.maketecheasier.com/python-t ... tor-linux/

Please see:
Gospel Library "Real Page" formatting
viewtopic.php?t=16391

This discussion encouraged me to start writing some code which I published at
https://github.com/bradporter/OpenSticks

I have abandoned the method I started at the github link based on comment number 12 of
viewtopic.php?t=16391
Samuel Bradshaw offered some advice which I took. I last worked on it when I had a few focused hours on an cross country flight 5 years ago. I was encouraged, by the request for feedback, to open it up again today and made some good progress. Basically, the pagebreaks in the html database are searched for and used rather than the tedious task of telling it where the page breaks are.

A number of the requests above may not be so hard, like css additions of a book outline and page flipping. Others are very likely beyond the time I have to develope alone. That's not really the point I wanted to make though. It would be nice if I could interest others in an open source project, but the reality is that very few people will use it. I believe the main church app needs these enhancements. It's a tall order to overcome the disadvantages of eBooks in learning. I don't know if can even be done. Maybe. "An Ebook Can Outperform Print Version with the Right Enhancements" (https://www.techlearning.com/news/ebook ... -takeaways).

I have recently heard that seminary students are now required to bring scriptures to class, at least in my area of Utah. I'm doubting that is going to work out so well, and wondering if it is really an optimal solution. Maybe we can provide them with a better solution.

Finally, it would really be great if other books in the library, including the conference ensign, could also be marked up in the same way, with all the pagebreaks and multi-columns that the print versions have. All that is needed are page break markers in the databases.

********************