IE6+/Win problem with the scaling enabled by UseHR=1 and DPI>96

In all the following test cases there are some consecutive floats (with alternating red and green background) inside a container (with blue background) whose width is exactly the sum of the floats’ widths. The container encloses the floats since it is floated itself (the floats containing method is irrelevant to the problem discussed here.) The floats should all be in one row, filling exactly the container (no floats drops, no gaps.) This usually works in all browsers, including IE/Win.

Problems arise in IE/Win when the scaling for higher DPI screen is enabled. The scaling is implemented in a way that produces, depending on the widths, either float drops or gaps.

As a simple example, consider the fifth test case below, in a configuration with 120 dpi and scaling enabled. The scaling factor is 120/96=1.25. There are three 150px wide floats in a 450px container. Each float should have a scaled width of 150px×1.25=187.5px, which is rounded to 188px. The container should have a scaled width of 450px×1.25=562.5px, which is rounded to 563px. So, after the scaling is applied, there are three 188px wide floats in a 563px wide container. But 188px×3=564px, which is greater than 563px, so a float drop occurs. Examples of layouts suffering a float drop when viewed in IE/Win 120 dpi, scaling enabled: piefecta, jello piefecta, pmob 2 columns simple, layout gala n.7 three fixed columns.

Conclusions

When the IE/Win scaling for higher DPI screen is enabled, rounding errors may occur that break pixel precise floats layouts. This is the same problem usually seen when working with percentage widths, the scaling makes it occur even when the widths are expressed in pixels and the maths is absolutely correct. Possible workarounds are, of course, to make the width of the container few pixels greater than the sum of the floats widths, or (better) to add some negative “backside” margin on the “last” float for a given direction.