Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
wants to merge 2 commits into from

Conversation

prsadhuk
Copy link
Contributor

@prsadhuk prsadhuk commented Dec 4, 2020

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
Copy link

bridgekeeper bot commented Dec 4, 2020

👋 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
Copy link

openjdk bot commented Dec 4, 2020

@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.

@openjdk openjdk bot added the swing client-libs-dev@openjdk.org label Dec 4, 2020
@openjdk openjdk bot added the rfr Pull request is ready for review label Dec 4, 2020
@mlbridge
Copy link

mlbridge bot commented Dec 4, 2020

Webrevs

@@ -2862,18 +2862,15 @@ ImageIcon getImage(URL base) {
lengthMapping.put("cm", 28.3464f);
lengthMapping.put("pc", 12f);
lengthMapping.put("in", 72f);
int res = 72;
try {
res = Toolkit.getDefaultToolkit().getScreenResolution();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

@mperktold mperktold Dec 9, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@bridgekeeper
Copy link

bridgekeeper bot commented Jan 6, 2021

@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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rfr Pull request is ready for review swing client-libs-dev@openjdk.org
3 participants