1. 0
  1. 1

    Reading the sample and it looks like the PDF was generated without regard to where pages would break. It would be difficult to read on an e-reader, especially.

    1. 1

      Improving page breaks is on my list of things to do. It requires both figuring out and using whatever CSS DocRaptor (i.e., Prince) supports, and massaging the content to hit the page breaks nicely.

      Did you try it on an e-reader?

      1. 2

        No I didn’t. My Kindle Paperwhite makes reading normal-sized PDFs difficult. Are you planning epub/mobi formats as well?

        1. 1

          I designed the PDF so it would be usable on a large range of device sizes. The secret is that I don’t use a normal page size, opting for 396x596pt with a 36pt margin.

          I rate the experience on Kindle as “usable, but not ideal.” In portrait mode, the text is a little bit smaller than the size I usually read with. In landscape mode, the page is split vertically in thirds, but it shows the full text width and the text appears to be full size. Since the PDF has a proper table of contents, Go To works properly. I tested using my Kindle Voyage (6inch, 300ppi) and 3G (6inch, 167ppi).

          For reference, I rate the experience on my iPhone 3g (3.5inch, 163ppi) as “usable in a pinch.”

          I will be exploring producing epub and mobi formats. I’m already part of the way there as I’m using HTML/CSS and my page size constraints limit the size of difficult-or-impossible-to-reflow components such as code, graphics, and tables.