8231286: HTML font size too large with high-DPI scaling and W3C_UNIT_LENGTHS

[prsadhuk]

Issue is when using a JEditorPane to render HTML views with W3C_UNIT_LENGTHS enabled, font-sizes set using CSS are much larger than the same font size outside the HTML.
It's because CSS LengthUnit uses screen resolution to calculate units so for hidpi screens, the html font size is bigger.
Fix is to calculate the units based on the CSS absolute length mentioned in https://drafts.csswg.org/css-values-3/#absolute-lengths so hidpi scaling is not applied twice in CSS and again by Java.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Issue

• JDK-8231286: HTML font size too large with high-DPI scaling and W3C_UNIT_LENGTHS

Download

$ git fetch https://git.openjdk.java.net/jdk pull/1628/head:pull/1628
$ git checkout pull/1628

[bridgekeeper]

👋 Welcome back psadhukhan! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@prsadhuk The following label will be automatically applied to this pull request:

• swing

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 00: Full (00ea1b4)

[mrserb]

Are you sure that you can get the exact values of these absolute lengths without using a DPI of the screen? I mean that these values can be measured with a ruler on the screen and they must correspond to "cm" is one centimeter, and "in" is one "inch" etc.

BTW how the browsers handle that?

[mperktold]

I opened this issue and suggested this fix because it is in line with how px were handled already, and fixes convertions between the various units.

Are you sure that you can get the exact values of these absolute lengths without using a DPI of the screen?

It depends on how Java handles hi-DPI awareness in general, which I am not aware of.
Looking at the sources again, I've found java.awt.GraphicsConfiguration#getDefaultTransform() and java.awt.GraphicsConfiguration#getNormalizingTransform(), both of which are apparently related to hi-DPI awareness.

I think getDefaultTransform is usually used by the Runtime, and getNormalizingTransform is what we are looking for, acording to its JavaDoc:

Returns an AffineTransform that can be concatenated with the default AffineTransform of a GraphicsConfiguration so that 72 units in user space equals 1 inch in device space. [...]

I was quite happy with the results without considering getNormalizingTransform, but maybe I was just lucky that it corresponds to the identity transformation for my setup.

BTW how the browsers handle that?

Browsers have a devicePixelRatio indicating how many native device pixels form one CSS pixel (i.e. px).
On hi-DPI device, this value is greater than 1, e.g. 2, otherwise it is 1. It depends on the pixel density as well as on the usual viewing distance of the device.
The convertion between the various units is always a constant factor. Units such as cm or in are never precise, and thus not widely used.

[mrserb]

Can we skip this flag and additionally check the multi screen configuration in the test?

[bridgekeeper]

@prsadhuk This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!