Pagination worked fine for many purposes. The project with which I
used Prince included tables that extended onto new pages. They flowed
fine from page to page. The page-break CSS elements work. Prince
enables the inclusion of portrait and landscape orientation in the
same document.

However, I don't think it would be possible to do conditional page
breaking, as is possible in Prawn via grouping, or as we are aiming
for with the new delayed rendering (eg: if only one row of the table
fits on this page, move it to the next). And multi-column documents
where text flows from left column to right, and then on to the next
page, aren't achievable in HTML unless there is something I don't know
about (I haven't looked into the HTML specification for dealing with a
paginated environment).

The big win with Prince (or perhaps PDFKit) is when you need to
provide people with the ability to download a PDF version, or print a
nice version, of a page that you are already generating as XHTML +
CSS. The money saved by only needing to hire someone to write HTML +
CSS, rather than someone to write HTML + CSS and someone else to
generate the Prawn or whatever else that corresponds to the HTML + CSS
can easily surpass the $3,800 fee (which is a one-time fee, not an
annual license) for Prince XML. Especially if the appearance of those
documents is changed frequently or there are many different document
layouts. Plus, there is less room for the PDF output to stray from
what people see in the browser, which can be important to a company.

Prince XML + Princely was amazingly true to the original HTML + CSS.
The only adjustment I needed to make that was due to Prince was to
reduce the font size declared in body because printed output didn't
need as large a font as on-screen. Princely made it easy to do this
with the application of an additional stylesheet to override the
screen style.

But for the project I'm doing now, the PDF output I need cannot be
rendered in HTML, so no HTML to PDF converter would work. Prawn does.