[Booki-dev] [Booki and Objavi Development] #9: Fix page-break rules in webkit or gecko

[Mushon Zer-Aviv]

Comment:
>   Mushon: JS hackery won't work because javascript doesn't know where the
>   page breaks are.
>    
I know, my suggestion (though I admit I don't really know how it works) 
is this:

   1. Send html to be PDFed the way we do it now
   2. Gather the paging from the PDF in a similar way to how we do it
      now for the TOC:
      This is a big "if" - can we get a report about where the page
      breaks after breaking it? Can the script that draws the TOC be
      made sophisticated enough to know what is the last word on every page?
   3. Use the page break report to create a new html including <span
      class="pagebreak"></span> elements where appropriate, maybe even
      wrapping whole pages in Divs <div id="p24" class="page right-page
      section-4 chapter-15"> ... </div>
   4. Send the html to be PDFed again, this time making sure CSS & JS
      know what's going on.
   5. Success!

Hacky? I know...
Prone to fail? probably...
Worth considering? maybe...

Thanks,

M.
>   The way browsers deal with pagination is they lay out the whole page in
>   one big ribbon, executing all the javascript and css as they do so.  Only
>   after it is all laid out do they cut the ribbon into page sized pieces.
>   Basically, they don't think about print at all and treat it as a strange
>   kind of scrollbar.
>
>   A group of Google Chrome engineers are working to fix this upstream in
>   Webkit, but they have not finished, and we haven't merged their efforts
>   into the version of webkit that we use (which is wkhtmltopdf-qt, forked
>   from qt-webkit, forked from an older version of mainstream webkit).  I am
>   going to try to apply some of the new patches to our webkit and get them
>   accepted into wkhtmltopdf.
>
>   The good news is that FM books are very simple html, with only one column,
>   no sidebars, no floating bits, etc, so CSS layout might work for us even
>   while it remains broken in the general case.
>
>    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.flossmanuals.net/pipermail/booki-dev-flossmanuals.net/attachments/20100708/cb55ccd6/attachment-0001.htm>