On Fri, 29 Jan 2021 19:45:27 GMT, Alexey Ivanov <aiva...@openjdk.org> wrote:
>> This PR supersedes #2223. >> The original PR was created from master, whereas this PR is created from a >> fresh branch. >> >> Below is a copy of the original description, but as @mrserb correctly >> [pointed >> out](https://github.com/openjdk/jdk/pull/2223#issuecomment-767048399), there >> is actually no relevant change from CSS 2.1 to CSS 2.2, so I <strike>striked >> out</strike> that part. >> >> ### Original Description >> >> @prsadhuk asked me to take over his pull request #1628, since I filed the >> bug an suggested this fix. >> >> I thought the current behavior would be buggy, but actually the units are >> quite precise. I checked the size of a text in font-size of 1 in, and it >> really was approximately 1 inch. The problem is just that browsers behave >> differently. >> >> <strike> >> Swing follows the CSS 2.1 spec: >> https://www.w3.org/TR/CSS21/syndata.html#length-units. >> But in CSS 2.2, length units where redefined: >> https://www.w3.org/TR/CSS22/syndata.html#length-units. >> Now px is also an absolute unit, and there are constant conversion factors >> between all absolute units. >> >> The CSS 2.2 spec includes the following two notes regarding this change: >> >> Note that if the anchor unit is the pixel unit, the physical units might >> not match their physical measurements. Alternatively if the anchor unit is a >> physical unit, the pixel unit might not map to a whole number of device >> pixels. >> >> Note that this definition of the pixel unit and the physical units >> differs from previous versions of CSS. In particular, in previous versions >> of CSS the pixel unit and the physical units were not related by a fixed >> ratio: the physical units were always tied to their physical measurements >> while the pixel unit would vary to most closely match the reference pixel. >> (This change was made because too much existing content relies on the >> assumption of 96dpi, and breaking that assumption breaks the content.) >> >> So the spec changed the behavior to better support high-DPI devices with >> existing content, and that is exactly my intention with this PR as well. >> </strike> > > test/jdk/javax/swing/text/html/HtmlFontSizeTest.java line 98: > >> 96: String str = String.format("%.1g%n", ratio); >> 97: if (str.compareTo(String.format("%.1g%n", 1.3f)) != 0) { >> 98: throw new RuntimeException("HTML font size too large with >> high-DPI scaling and W3C_LENGTH_UNITS"); > > The test passes for me with the fresh build of JDK, even without the fix > applied. > Indeed, I get the same frame dimensions in both cases: 150×42. > > However, the test fails when run with JDK 11.0.10 or JDK 15, the dimension of > `htmlPane` is 409×76. > > The formatted string, `str`, contains only the number before the decimal > point. I mean for `1.3f`, the formatted string is `"1"`. I'd expect the > formatted string to have at least one digit after the decimal point but > there's none. > > Does > if ("1.3".equals(String.format("%1.1", ratio)) > look clearer? > > > I guess the test does not fail if the system scaling (of the main monitor) is > set to 100% because `res` value read from > `Toolkit.getDefaultToolkit().getScreenResolution()` is 96/72 which is 1.3. > > In my testing, `sun.java2d.uiScale` has no effect on the result. I propose to move the test into CSS folder, and probably to create its own folder, `8231286` or 'font-size`. ------------- PR: https://git.openjdk.java.net/jdk/pull/2256
