<Swing Dev> RFR: 8231286: HTML font size too large with high-DPI scaling and W3C_LENGTH_UNITS

[Prasanta Sadhukhan]

On Wed, 27 Jan 2021 12:06:43 GMT, Alexey Ivanov <aivanov at 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>
>
> You should edit the title of the PR to be the same as the subject of the bug in JBS:
> 8231286: HTML font size too large with high-DPI scaling and W3C_LENGTH_UNITS
> 
> Please also provide the additional information in the description from the PR #2223.

It seems for screen with low resolution, this change might cause some failure as can be seen in the testcase attached in JBS Test.java.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2256