Hi

I'm making a documentation editor application where users can customize the look and contents of the documentation they create (including headers and footers).

I show the users what their content looks like in HTML and prince kindly converts it into a PDF.

The only problem I'm having is showing the user what their headers and footers look like in the HTML version.

It seems Prince uses a table 'like' structure for these areas i.e. cells which intelligently resize to fit the content. The top center could be 60% wide and the left and right would shrink to 20% each.

However in my HTML version my header elements (which are taken from the document and given to prince) can't be defined as a table and cells because prince only works with blocks.

I could define them as floated blocks but then I'd have to give them explicit widths (33%) which is ok in most cases but in the case above of a 60% wide center heading would cause ugly line wrapping.

Is there an 'elegant' way to match princes handling of the footer and headers in html?

If the HTML that you display in the browser is different to the HTML that you convert to PDF with Prince, can you use a table in the browser?

Hi Mike,

I'm trying to keep the HTML for both brower and pdf as close as possible because I want to allow users with html and css skills to create their own themes. The close my themes are as examples the less work they have to do to get started (i.e. learning about prince etc).

I've just tried experimenting with divs with their display set to 'table-cell'. Prince seems to be handling this fine. Is that expected? Your docs seems to suggest otherwise however.

That should work fine; the docs may be outdated, which ones are you looking at?

The main docs titled "User Guide for Prince 9.0"

it says

"Page margin box content may be taken from the document itself. Any block-level element can be removed from the normal flow and placed in a page margin box."

I'm not skilled at css so perhaps a table-cell defined div is still a block level element, in which case I'd say the docs are fine as is. If technically it's no longer a block level element then perhaps a heads up in the docs would be useful.

Thanks for your help

Adam.

Hmm, I guess that is a little ambiguous! Table cells count as block-level for some purposes, but not all. And in many cases a table cell on its own will be automatically wrapped up in a table row and table box, making it block-level in the end anyway.