Imaginea long article or blog post that requires a lot of vertical scrolling to read, especially on a small mobile device. What I would like to do is break the long page into multiple full-screen sections, allowing the user to use left/right navigation arrows and/or the swipe gesture to "page" through the article.
There are many JS libraries available that can create a "slide show" or "carrousel" of pre-defined slides (using divs or other container elements). But I want the text and html content to dynamically re-flow to fit any device viewport and still be readable... just like an epub/ebook user interface, like the Kindle app or iBooks. So, for the same article, there would be many more "pages" on a phone than there would be on a tablet or desktop viewport, and those "pages" would need to be dynamically created/adjusted if/when the viewport size changes (like switching from portrait to landscape on a mobile device).
... notice the responsive behavior. When you resize your viewport, all the text re-flows to fit the available space, increasing or decreasing the total number of "pages". The problem is that epub.js requires an .epub file as its source.
I realize that I could use a conversion script to convert my html page into an .epub file, and then use epub.js to render that file within the browser, but that seems very round-about and clunky. It would be so much better to mimic or simulate the .epub reader user experience with html as the direct source, rendering/mimicking a client side responsive ebook user experience.
The crucial functionality is the dynamic/responsive text-reflow. When the viewport dimensions are reduced, the text/content needs to reflow to the next "page" to avoid any need for vertical scrolling. I don't know how to do this efficiently. If I were to code it myself, I might use something like the jQuery Columnize plugin, setting all columns to width: 100vw; height: 100vh, so that each column is like a "page", and then figuring out how to create a swipe UI between those "pages".
This becomes very difficult if the html page is complex, eg with precisely positioned elements or images. However if (as in the epub.js example) the content consists only of headings and paragraphs, it is achievable.
The basic idea is to progressively add content until just before the page overflows. By keeping track of where we start and stop adding content, clicking to the next page is a case of changing the page start to the previous page end (or vice versa if you're going back).
Let's assume you have all your content in one long string. Begin by splitting all the content into an array of words and tags. It's not as easy as splitting by whitespace as whitespace between should be ignored (you want to keep classnames etc within each tag). Also tags should be separated as well, even if there is no whitespace between the tag and a word.
Beginning at the index in pageStart you add elements from the array as content to the page, checking after each add whether or not the contents overflow. When they do overflow you take the index you're up to, minus 1, as the index for pageEnd.
Now if all's ticketyboo then this should fill the page pretty well. When you want to go to the next page set your new pageStart as pageEnd + 1 and repeat the process. However there are some issues that you may want to fix.
Firstly, what happens if the page overflows in the middle of a paragraph? Strictly speaking the closing tag, , is not required in HTML, so we don't need to worry about it. But what about the start of the next page? It will be missing an opening tag and that is a major problem. So we have make sure we check if the page's content begins with a tag, and if it doesn't then we get the closest opening tag prior to the current pageStart (just step back along the array from pageStart) and add it in before the rest of the content.
Secondly, as shown in the example, if a paragraph continues onto the next page, the last line of the current page is still justified. You need to check if pageEnd is in the middle of a paragraph and if so add syle="text-align-last:justify;" to the opening tag of that paragraph.
The HTML page contains all content in one long element. The content is taken directly from the container #page and reformed into pages, depending on the size of #page. I have't implemented justifying the last line if a page break occurs within a paragraph. Resize the #page element in the css and see how the content resizes itself - note that since the page size is fixed you'll have to use click forward and back to trigger a recalculation. Once you bind the page size to the window size, recalculating pages on the fly simply involves adding a resize event listener to the window that calls fillPage.
No doubt there are numerous bugs, indeed it will sometimes display things incorrectly (eg skipping or repeating words at the beginning or end of a page), but this should give you an idea of where to start.
#displayer will have css overflow:hidden. So when the site loads, it will only show the first page, because the rest of the #epub_container will be hidden.Then you need a page navigator to increment/decrement the page number. When the page number changes, we will move the top offset of the #epub_container based on that.
I created a plugin that handles this perfectly. It has features like dark mode, font changing, line height adjustment, select chapter in a side nav menu, save and restore scrolling/reading position. You can find it for free on git hub at -TechDev/Html-Book-Reader
This post is about the baffling world of ebook formats, and what I learned while wrangling my book into shape. Partly so I remember next time I need to build a revision, but also because this stuff took me some time to figure out, and if it helps someone else that would be excellent. If you have also been through this, or know about converting from other formats, please add your advice in the comments.
Having created a first draft I used the compilation functionality in Scrivener to send a first draft to contributors and people who were reviewing the book, and then made any changes in Scrivener. It was at this point that all the fun started.
Scrivener can output to HTML, and the EPUB and MOBI formats are HTML, so it made sense to compile my book as an HTML document and work from there, finding a way to create all three formats out of the HTML. I could then keep my HTML copy in source control, make any changes as I needed to and rebuild the book formats when I felt an update was required.
I tackled EPUB first, I had read a post on the Puppetlabs site about how they created the formats for their ebook. This led me to pandoc, an excellent document converter that can transform a number of formats into other formats.
Pandoc will use your HTML (or Markdown) heading levels to create the chapters and outline for your book. Level 1 headings will become chapters. Pandoc can then create you a table of contents for the epub, displaying your tree as deep as you like. This means that you need to make sure that your document is well structured in your HTML or Markdown.
I encountered a bug in pandoc where it did not read my custom CSS file, I found a discussion on this and it seems that this is a bug and if you run into it, adding your CSS file named epub.css into a hidden directory .pandoc in my home folder (I had to create this directory) fixes the issue.
The second issue becomes a problem in the next stage, in that if you have a title in your HTML document as well as in the meta xml file, you get two titles and creating your MOBI will fail. I just removed the title from the HTML document.
If you are having issues or just want to poke around your EPUB, then it is simply an archive with .epub extension. I found that BetterZip on the Mac allowed me to open the archive and have a look at the contents. I have seen suggestions that some tools will require you to change the extension to .zip before they will open it.
As if by magic a MOBI file appears! The only issue I had was with my duplicate titles as mentioned above, however the error messaging from the KindleGen tool was pretty good and I was able to figure out the issue.
I should note that the less you mess about with formatting for the Kindle the better. I eventually ended up using different stylesheets for the EPUB that I shipped and for the EPUB I used to create the MOBI. The Kindle does a pretty nice job of making readable books, the less we mess with it the better.
This all seemed to be working nicely enough, until I realised that the PDF that was being generated was 180MB. I tried some options, tried to compress the PDF via various means, with no results. A quick Google confirmed I was not the only person with this issue.
A non-giant PDF will appear! Having confirmed it would work I then purchased a license, the site does not deliver licenses immediately so I was faced with a 48 hour delay. Knowing that Jonathan Snook had a copy I send him a begging email to see if he would generate my PDF for me, which he very kindly did.
Jonathan also helped me out with a CSS snippet that would create numbering and improved page sizes in my PDF, as my license for Prince came through overnight I was able to quickly rebuild the PDF to take advantage of that before launching the book. I can recommend the A List Apart article Building Books with CSS if you are using Prince and want to take advantage of the Paged Media spec that Prince supports.
To respond on your own website, enter the URL of your response which should contain a link to this post's permalink URL. Your response will then appear (possibly after moderation) on this page. Want to update or remove your response? Update or delete your post and re-enter your post's URL again. (Learn More)
PRC is a generic format, calibre supports PRC files with TextRead and MOBIBook headers.PDB is also a generic format. calibre supports eReader, Plucker (input only), PML and zTxt PDB files.DJVU support is only for converting DJVU files that contain embedded text. These are typically generated by OCR software.MOBI books can be of two types Mobi6 and KF8. calibre fully supports both. MOBI files often have .azw or .azw3 file extensions.DOCX files from Microsoft Word 2007 and newer are supported.
3a8082e126