8231286: HTML font size too large with high-DPI scaling and W3C_UNIT_LENGTHS#1628
8231286: HTML font size too large with high-DPI scaling and W3C_UNIT_LENGTHS#1628prsadhuk wants to merge 2 commits into
Conversation
|
👋 Welcome back psadhukhan! A progress list of the required criteria for merging this PR into |
| lengthMapping.put("in", 72f); | ||
| int res = 72; | ||
| try { | ||
| res = Toolkit.getDefaultToolkit().getScreenResolution(); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
| * @bug 8231286 | ||
| * @key headful | ||
| * @summary Verifies if HTML font size too large with high-DPI scaling and W3C_UNIT_LENGTHS | ||
| * @run main/othervm -Dsun.java2d.uiScale=1.0 HtmlFontSizeTest |
There was a problem hiding this comment.
Can we skip this flag and additionally check the multi screen configuration in the test?
|
@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! |
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
Issue
Download
$ git fetch https://git.openjdk.java.net/jdk pull/1628/head:pull/1628$ git checkout pull/1628