There appears to be an issue with the XHTML engine of Prince.
Block borders systematically invade the space of floated <dt> definition terms.

Here is an example web page, and the PDF output with Prince.

On the top of page 4 "Reinstalling GRUB", the borders of the code blocks (which do not belong to the <dd> definition data) invade the backround space of the floated <dt> definition term (which contains a partially transparent image). The same behaviour can also be noted at different places in this document, as well as in other documents on my web page.

However, this behaviour is typically not seen with any ordinary web browser.

Here is the link to the pertaining CSS.
The original HTML source for printing (with white instead of coloured background) and above mentioned CSS file are also attached to this bug report.

1. print.css‎ 6.1 kB ‎
   CSS
2. same_pc.new_hd.a4.xhtml‎ 16.1 kB ‎
   XHML source

To simplify debugging, I am attaching an archive which contains the XHTML and all CSS files in a folder with the correct relative paths.

1. dt.tar.gz‎ 2.1 MB ‎
   Archive containing all files

Hi, thanks for creating that zip file! This is a peculiar issue. You are right it doesn't happen in web browsers, however if you remove all the overflow:auto instructions applied to the PRE element and the overflow-x:auto applied to div.sourceCode you will see exactly the same rendering in browsers!

This probably has something to do with clearing floats with overflow but I don't understand the CSS intricacies involved. Those older articles is about applying overflow to a *parent* of the floated elements. It's a mystery to me why applying an overflow style to the sibling of an ancestor of the floated element should change the rendering in this way..

I wrote a test case based on your code and added it here:
https://github.com/yeslogic/miscellaneous-testcases/blob/master/layout/floating-dt-next-to-element-with-border-001.htm
I hope this helps the YesLogic devs fix it

Announcement: repos for tests/utils

Edited 12 Nov 2016 by hallvord

@hallvord Thanks for condensing my zip file to a nice little test case. That sure will speed up debugging!

Hi, sorry for the delay in responding. In order for the border not to overlap the float the div needs to establish a new block formatting context. One way to do that is to have a value other than 'visible' for the overflow property, which explains why adding/removing overflow:auto changes the browser behaviour.

Prince only accepts the 'visible' and 'hidden' values for this property (the 'auto' value requires the agent to provide scrolling, which only makes sense for a browser); declarations with any other values will be ignored. You can instead achieve the desired result in Prince by using overflow:hidden, or establishing a new formatting context another way, such as by making the element a table cell.

Mark

EDIT: We plan to add support for the 'auto' and 'scroll' values in a future release. Either of these values will cause a new block formatting context to be created, so as to do the right thing in this and other cases, but will otherwise act as 'visible' so far as clipping is concerned.

Edited 19 Feb 2020 by markbrown

Hi,

We've just released Prince 13.4, available here, which supports the additional values for overflow. This should address the above issue.

Mark

Nice work @markbrown, I confirm this build works fine with the test case and the web page.

Announcement: repos for tests/utils