We’re currently using Prince to generate PDFs of medical documents.

Take a look at the included documents; the difference between the two is that the “bad” document contains a “div” within a “span”. In this document, the surrounding span’s overriding of the default font to 32px isn’t being applied to the “SOME TEXT” text. If that “div” isn’t there (or any other block level element), “SOME TEXT” is in the correct, overridden font size.

I know that block level elements inside inline level elements are technically illegal, but this particular effect seems strange. Does anyone know why this might be happening with Prince?

- Tim

1. finalDoc.bad.html‎ 1.3 kB
2. finalDoc.good.html‎ 1.3 kB

We will investigate this issue, but yes strange things can happen when blocks are inside spans.

Thanks! The issue is noticeable by users, as browsers (or at least Chrome) render it correctly despite the illegal HTML construct; when they then print it, they see the difference, and make a complaint.

- Tim

Hello there again...

Any discoveries about what might be causing this?

- Tim

The way we split inline elements containing blocks is causing it, but that's something we probably can't change in a hurry, I'm afraid.

Thanks for your reply; just curious, but our having a support contract with you folks won't make a difference in how fast this might be fixed?

- Tim

I can't answer your question (you may wish to email mikeday@yeslogic.com directly about that) but there are tools around such as the 'tidy' package on Debian that can do quite a good job of repairing non-compliant HTML. I'm not sure whether this is possible in your situation, but perhaps you are able to run the input through one of these tools before sending it to Prince? If you run the "bad" document through 'tidy' before Prince it gets the correct font size to the latter part of the span.

Thanks for the suggestions - unfortunately, that won't help us; the HTML we're generating is non-compliant ON PURPOSE. I know that's not the best solution, but it was what we had to do at the time (we were using the GWT RichTextArea component for customer documents, which is very limited). We're now using much better tools, so could modify how things work so that all HTML we generate is compliant; since we now have millions of user documents in this format, however, that's quite a task in itself (we'd need to fix all existing documents, which isn't that simple since this is a system-of-record for medical software).

We do a LOT of processing and scrubbing to corral documents into a format that's at least more compliant (since users are allowed to paste in arbitrary HTML copied from other sites); but block-elements-inside-inline-elements are part of the document structure and can't be changed currently.

I'll talk to the folks here who deal with our support contracts to see what the next steps will be. Thanks again for your suggestions.

- Tim