Question

I am creating an ePub reader on IOS. Basically, I use uiwebview to load the xhtml files.
Every time page turn， I need to load the file with uiwebview then call javascript to scroll to the right offset. Here is a problem, some xhtml file is big (like > 2MB) that it cost too much time to load. Thus the page turn animation is not so smooth.
So I am thinking I could load the xhtml once with uiwebviewA , and each time page turn, I create another uiwebviewB and grab the needed html content(like second page) from uiwebviewA. In this way, I could limite the html into small size and the page turn animation should be smooth.
My question is that is there any open source javascript library can do the job?
Any comments is appreciated!!

Answer 1

There is no meaningful, well-defined way to split an HTML document in the way you seem to be describing. You are confusing two very different things: (1) splitting the rendering into page-sized chunks, and (2) splitting the HTML source. To put it a different way, there is no algorithm I can imagine that would split an HTML file into pieces, such that the sequential composition of the rendered pieces was identical to the rendering of the original HTML file. In other words, in order to figure out how to split the HTML, assuming it is even possible, you’d have to do much or all of the work involved in rendering the page, which would defeat the entire purpose.

You should abandon the notion of splitting the HTML. Ebook readers all paginate by essentially rendering the entire HTML document once, then “windowing” and “clipping” and “offsetting” or, in some cases, using CSS regions.

There are a couple of alternatives I can think of, if I understand what you are trying to do.

1. Reduce the size of the input HTML files by pre-splitting them earlier in the
   workflow. For instance, in one project I know, the source (X)HTML files have bits of additional markup that tell a pre-processor where split them into individual files if desired, which in this case is a work-around for ebook readers that don’t honor CSS page-break-* properties properly.

2. Pre-compute the rendering for next page as a graphic and
   use it for the page turning.

3. As already discussed, rethink your architecture of reloading the entire HTML document for every page in your book. If it is merely page turning effects that
   lead you to want to do that, then give them up.

4. Consider that many ebook readers provide a scrolling mode that does
   not require pagination, and some (eg Himawari Reader) provide only
   scrolling mode, which is actually something that some readers prefer.
   You can put out your scrolling version, and then do pagination in version 2.