8231286: HTML font size too large with high-DPI scaling and W3C_LENGTH_UNITS #2256

mperktold · 2021-01-27T11:40:10Z

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, there is actually no relevant change from CSS 2.1 to CSS 2.2, so I ~~striked out~~ 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.

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

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_LENGTH_UNITS

Reviewers

Alexey Ivanov (@aivanov-jdk - Reviewer)
Prasanta Sadhukhan (@prsadhuk - Reviewer) ⚠️ Review applies to ce2500c

Download

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

Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk@users.noreply.github.com>

… separate lines

bridgekeeper · 2021-01-27T11:44:17Z

👋 Welcome back mperktold! 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 · 2021-01-27T11:45:39Z

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

aivanov-jdk · 2021-01-27T12:06:43Z

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.

mlbridge · 2021-01-27T12:29:57Z

Webrevs

prsadhuk · 2021-01-27T12:42:56Z

src/java.desktop/share/classes/javax/swing/text/html/CSS.java

-            w3cLengthMapping.put("cm", res / 2.54f);
-            w3cLengthMapping.put("pc", res / 6f);
-            w3cLengthMapping.put("in", (float) res);
+            // mapping according to the CSS2.2 spec


Should we not put the latest CSS link here in addition/instead of in JEditorPane?

prsadhuk · 2021-01-29T15:54:32Z

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.

aivanov-jdk · 2021-01-29T14:06:15Z

src/java.desktop/share/classes/javax/swing/text/html/CSS.java

-            w3cLengthMapping.put("cm", res / 2.54f);
-            w3cLengthMapping.put("pc", res / 6f);
-            w3cLengthMapping.put("in", (float) res);
+            // mapping according to the CSS2.2 spec


Should we not put the latest CSS link here in addition/instead of in JEditorPane?
I agree the link to Length Units should also be added here:

Suggested change

// mapping according to the CSS2.2 spec

// Mapping according to the CSS2.2 spec

// https://www.w3.org/TR/CSS22/syndata.html#length-units

Or https://www.w3.org/TR/CSS22/syndata.html#x39 which leads directly to Absolute length units.

aivanov-jdk · 2021-01-29T14:15:13Z

src/java.desktop/share/classes/javax/swing/text/html/CSS.java

+            w3cLengthMapping.put("pt", 1.3f); //1/72 of 1in
+            w3cLengthMapping.put("px", 1f); //1/96 of 1in
+            w3cLengthMapping.put("mm", 3.77952f); //1/10 of 1cm
+            w3cLengthMapping.put("cm", 37.7952f); //96px/2.54
+            w3cLengthMapping.put("pc", 16f); //1/6 of 1in
+            w3cLengthMapping.put("in", 96f); //96px


I suggest adding a space after //.
Align the comments?

As for px, CSS defines, “1px is equal to 0.75pt”, then 1pt is 4/3px — this is where 1.3f comes from (=96/72).

Copyright year in CSS.java needs updating to 2021 too.

As for px, CSS defines, “1px is equal to 0.75pt”, then 1pt is 4/3px — this is where 1.3f comes from (=96/72).

This makes sense.

What makes me wonder is why the length mappings for px and pt without W3C_LENGTH_UNITS are exactly the opposite. In particular, it means that with W3C, 1pt > 1px, while without W3C 1px > 1pt.
That seems odd.

On the other hand, I don't know what the goal of those length mappings is, and they are not the sope of this PR.

As for px, CSS defines, “1px is equal to 0.75pt”, then 1pt is 4/3px — this is where 1.3f comes from (=96/72).

This makes sense.

What makes me wonder is why the length mappings for px and pt without W3C_LENGTH_UNITS are exactly the opposite. In particular, it means that with W3C, 1pt > 1px, while without W3C 1px > 1pt.
That seems odd.

On the other hand, I don't know what the goal of those length mappings is, and they are not the sope of this PR.

It's for historical reasons, I believe. JDK considers 1pt = 1px, as if the default screen resolution was 72dpi rather than 96dpi.

aivanov-jdk · 2021-01-29T18:12:22Z

test/jdk/javax/swing/text/html/HtmlFontSizeTest.java

+            frame.setVisible(true);
+            frame.setLocationRelativeTo(null);
+
+            return frame.getBounds();


frame is redundant, htmlPane.getPreferredSize() does the job.

aivanov-jdk · 2021-01-29T18:14:59Z

test/jdk/javax/swing/text/html/HtmlFontSizeTest.java

+        float ratio = (float)w3cFrameSize.width / (float)stdFrameSize.width;
+        System.out.println("w3cFrameSize.width/stdFrameSize.width " + ratio);


Shall the ratio be (float)w3cFrameSize.height / (float)stdFrameSize.height?
You measure the font size so height seems a better candidate. However, the width does change as well.

The problem with height is that the values are much smaller so they lead to higher rounding errors, and we do not achieve a 1.3 ratio. To account for that, we would need to either accept a wider range of ratios (e.g. everything between 1.15 and 1.45) or increase the font size.
I went with width for now, but I can change to height and, say, double the font size if you prefer.

aivanov-jdk · 2021-01-29T19:45:27Z

test/jdk/javax/swing/text/html/HtmlFontSizeTest.java

+        String str = String.format("%.1g%n", ratio);
+        if (str.compareTo(String.format("%.1g%n", 1.3f)) != 0) {
+            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`.

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.

JDK-8257664: HTMLEditorKit: Wrong CSS relative font sizes
has changed the behaviour. With the fix reverted, I get frame size of 409×76 as in previous versions.

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.

JDK-8257664: HTMLEditorKit: Wrong CSS relative font sizes
has changed the behaviour. With the fix reverted, I get frame size of 409×76 as in previous versions.

I have submitted JDK-8260687: Inherited font size is smaller than expected when using StyleSheet to add styles.

I suggest declaring the font-size property on the <body> element in style attribute.

Does

if ("1.3".equals(String.format("%1.1", ratio))

look clearer?

I went with something similar to this now. Unfortunately, I also needed to use Locale.ENGLISH explicitely to get a dot as the decimal separator.

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.

To be honest, this is unclear to me as well, I just copied what @prsadhuk had. When testing with older JDKs, I got some different dimensions, but at least now with the fix applied it doesn't seem to change anything.

I propose to move the test into CSS folder, and probably to create its own folder, 8231286 or 'font-size`.

Done, moved into ./CSS/8231286.

I suggest declaring the font-size property on the <body> element in style attribute.

Done.

Does

if ("1.3".equals(String.format("%1.1", ratio))

look clearer?

I went with something similar to this now. Unfortunately, I also needed to use Locale.ENGLISH explicitely to get a dot as the decimal separator.

Interesting. With Locale.ENGLISH, it will be more robust.

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.

To be honest, this is unclear to me as well, I just copied what @prsadhuk had. When testing with older JDKs, I got some different dimensions, but at least now with the fix applied it doesn't seem to change anything.

It is likely because sun.java2d.uiScale gets applied to both frames. If the font size is the same, 2d surface gets scaled up to the same level, which results in the same size of the frames.

Yet the calculations of the conversion ratios in CSS depend only on the resolution of the main screen. If the main screen resolution is 96dpi (100% scaling), the font size will be the same as after your fix.

It is likely because sun.java2d.uiScale gets applied to both frames. If the font size is the same, 2d surface gets scaled up to the same level, which results in the same size of the frames.

Yet the calculations of the conversion ratios in CSS depend only on the resolution of the main screen. If the main screen resolution is 96dpi (100% scaling), the font size will be the same as after your fix.

That makes sense.

What should we do about it? Is there a way to inject a different screen resolution for testing?
And should I remove sun.java2d.uiScale from the doc?

What should we do about it? Is there a way to inject a different screen resolution for testing?

I do not know. You can change the scale factor on your main display, the Toolkit.getScreenResolution() will return the new value.

And should I remove sun.java2d.uiScale from the doc?

I think so. It does not affect the test in any way.

aivanov-jdk · 2021-02-01T21:20:34Z

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.

I'm afraid we can't make 72pt be exactly 96px because of the nature of floating point calculations which are not precise.
The font size for 72pt is 94px instead of the expected 96px, the line height is 120px instead of 123px.

What we can do to improve the accuracy is not to hard-code the constant as suggested at the moment but put 96/72 to map 'pt' unit to pixels.

So 1.3 * 72 = 93.6 which is rounded to 94. Then 1.33 * 72 = 95.76 which is rounded to 96; 1.333 * 72 = 95.976 and so on. If 96/72 is stored as float, we'll have the most precise value.

However, I'm pretty sure there are size / unit combinations which could make your test fail. But still, it's a good way to estimate the accuracy. Shall we add it as another test for this issue?

If you disable, W3C_LENGTH_UNITS, you'll get a dramatic difference: 72pt = 72px, line height 92px but 'font-size: 96px' results in font size of 125px and line height of 159.

Before @mperktold's fix is applied, the difference in size with W3C_LENGTH_UNITS is also significant, the letter 'C' is twice as small as the other letters; the two letters are rendered on the second line. In this case 72pt = 192px and line height of 244px, but 'font-size: 96px' has the expected size of 96px and line height of 123 px.

aivanov-jdk · 2021-02-01T23:02:05Z

test/jdk/javax/swing/text/html/CSS/8231286/HtmlFontSizeTest.java

+            frame.setVisible(true);
+            frame.setLocationRelativeTo(null);
+
+            return htmlPane.getPreferredSize();


I meant you don't need frame at all. You can remove the frame variable.

prsadhuk · 2021-02-02T06:20:44Z

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.

I'm afraid we can't make 72pt be exactly 96px because of the nature of floating point calculations which are not precise.
The font size for 72pt is 94px instead of the expected 96px, the line height is 120px instead of 123px.

What we can do to improve the accuracy is not to hard-code the constant as suggested at the moment but put 96/72 to map 'pt' unit to pixels.

So 1.3 * 72 = 93.6 which is rounded to 94. Then 1.33 * 72 = 95.76 which is rounded to 96; 1.333 * 72 = 95.976 and so on. If 96/72 is stored as float, we'll have the most precise value.

However, I'm pretty sure there are size / unit combinations which could make your test fail. But still, it's a good way to estimate the accuracy. Shall we add it as another test for this issue?

If you disable, W3C_LENGTH_UNITS, you'll get a dramatic difference: 72pt = 72px, line height 92px but 'font-size: 96px' results in font size of 125px and line height of 159.

Before @mperktold's fix is applied, the difference in size with W3C_LENGTH_UNITS is also significant, the letter 'C' is twice as small as the other letters; the two letters are rendered on the second line. In this case 72pt = 192px and line height of 244px, but 'font-size: 96px' has the expected size of 96px and line height of 123 px.

Yes, it seems right to not hardcode and use 96/72f for "pt". I guess this needs to be fixed as this test is part of our regression test and that will fail after this fix, if not taken care and it will be considered as regression.
I will also prefer that JDK-8260687 is also fixed as part of this PR as that also concerns JEditorPane.W3C_LENGTH_UNITS property.

…recision

openjdk · 2021-02-03T17:43:07Z

⚠️ @mperktold This pull request contains merges that bring in commits not present in the target repository. Since this is not a "merge style" pull request, these changes will be squashed when this pull request in integrated. If this is your intention, then please ignore this message. If you want to preserve the commit structure, you must change the title of this pull request to Merge <project>:<branch> where <project> is the name of another project in the OpenJDK organization (for example Merge jdk:master).

kevinrushforth · 2021-02-03T17:54:03Z

This looks OK now (from a commit history point of view).

As for the above Skara message:

these changes will be squashed when this pull request in integrated. If this is your intention, then please ignore this message.

Yes, you can ignore it.

openjdk · 2021-02-04T09:54:09Z

@mperktold This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

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

Reviewed-by: aivanov, psadhukhan

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 56 new commits pushed to the master branch:

fac3c2d: 8254702: jpackage app launcher crashes on CentOS
7a6c176: 8260736: Shenandoah: Cleanup includes in ShenandoahGC and families
4a89733: 8261198: [macOS] Incorrect JNI parameters in number conversion in A11Y code
4a1814c: 8261179: Norwegian Bokmål Locale fallback issue
0218917: 8258732: runtime/cds/appcds/dynamicArchive/DynamicArchiveRelocationTest.java fails
f9df366: 8242300: SystemDictionary::resolve_super_or_fail() should look for the super class first
43ae0cf: 8261167: print_process_memory_info add a close call after fopen
48f5220: 8260369: [PPC64] Add support for JDK-8200555
224c166: 8261213: [BACKOUT] MutableSpace's end should be atomic
3495feb: 8260296: SA's dumpreplaydata fails
... and 46 more: https://git.openjdk.java.net/jdk/compare/91e6c755f32dada6c62bad4ff4221aed75a0ccc2...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@aivanov-jdk, @prsadhuk) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

prsadhuk · 2021-02-04T10:12:09Z

/issue add JDK-8260687

openjdk · 2021-02-04T10:12:26Z

@prsadhuk Only the author (@mperktold) is allowed to issue the /issue command.

aivanov-jdk · 2021-02-04T11:10:19Z

I have written automatic test for JDK-8260687: Inherited font size is smaller than expected when using StyleSheet to add styles. You can find it in my JDK-8260687 branch:
https://github.com/aivanov-jdk/jdk/commits/JDK-8260687
There's also a commit which modifies the test from JDK-8257664 to run in two modes with and without W3C_LENGTH_UNITS.

We have several options:

As this PR contains the fix for JDK-8260687, you can cherry-pick the test into your branch.
I can create a new JBS issue to add the test for JDK-8260687 separately.
You can revert the fix in your PR, and I'll add it to the test and then raise a new PR to resolve JDK-8260687.

I have no strong preference for any of the options.

prsadhuk · 2021-02-04T11:34:26Z

I have written automatic test for JDK-8260687: Inherited font size is smaller than expected when using StyleSheet to add styles. You can find it in my JDK-8260687 branch:
https://github.com/aivanov-jdk/jdk/commits/JDK-8260687
There's also a commit which modifies the test from JDK-8257664 to run in two modes with and without W3C_LENGTH_UNITS.

We have several options:
1. As this PR contains the fix for JDK-8260687, you can cherry-pick the test into your branch.

2. I can create a new JBS issue to add the test for JDK-8260687 separately.

3. You can revert the fix in your PR, and I'll add it to the test and then raise a new PR to resolve JDK-8260687.
I have no strong preference for any of the options.

My preference will be

if @mperktold can pick the test from aivanov-jdk@6d0b40d and add into this PR
else 2)
@mperktold can you also issue this comment "/issue add JDK-8260687" once @aivanov-jdk approves this PR.

aivanov-jdk · 2021-02-04T11:59:29Z

My preference will be

1. if @mperktold can pick the test from [aivanov-jdk@6d0b40d](https://github.com/aivanov-jdk/jdk/commit/6d0b40db4400dac03567b5cab4ad45b103ea94d0) and add into this PR
   else 2)
   @mperktold can you also issue this comment "/issue add JDK-8260687" once @aivanov-jdk approves this PR.

Good!

The only thing is that the test file has three commits now:
aivanov-jdk/jdk@6d0b40d, aivanov-jdk/jdk@b50d650, aivanov-jdk/jdk@f9e99777
The final version of the test file BodyInheritedFontSize.java.

Then this PR would include the fixes for two issues, thus the command
/issue add JDK-8260687
would add another resolved bug to the commit.

Optionally, issuing the following commands:
/contributor add psadhukhan
/contributor add aivanov
will add Prasanta and myself as contributors.

aivanov-jdk · 2021-02-04T20:58:43Z

It seems Toolkit.getDefaultToolkit().getScreenResolution() can return 93/94/95 instead of 96 in mac/linux in internal mach5 testing systems causing failure in this test Test.java. Probably we need to make the testcase hardcoded to 96

I guess so.
Where does this Test.java come from?
I also suggest fixing JDK-8260687 to not use font inherit for W3C_LENGTH_UNIT case
--- a/src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java
+++ b/src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java
@@ -2823,7 +2823,7 @@ public class StyleSheet extends StyleContext {
         }

         Object doGetAttribute(Object key) {
-            if (key == CSS.Attribute.FONT_SIZE && !isDefined(key)) {
+            if (key == CSS.Attribute.FONT_SIZE && !isDefined(key) && !isW3CLengthUnits()) {
                 // CSS.FontSize represents a specified value and we need
                 // to inherit a computed value so don't resolve percentage
                 // value from parent.
Does such a fix not bring back the problem with relative units for the case where W3C_LENGTH_UNIT is enabled?
I guess no as this code is recently introduced by JDK-8257664 and I have verified with this testcase and other jtreg regression tests. But if you have a better fix, then please suggest.

Indeed, it does. Why will it not? The modified TestWrongCSSFontSize.java (regression test for JDK-8257664) fails when W3C_LENGTH_UNIT is enabled with the proposed fix: the font size gets bigger than it should as 150% scale gets applied twice to this fragment:

<h2>Foo</h2>

The test uses body { font-size: 14 } rule in its <style>. But it fails the same way if this is replaced with the correct units:

        editor.setText(TEXT.replace("$FONT_SIZE",
                                    w3cUnits ? "14px" : "14pt"));

Since this is the case, I suggest reverting the proposed fix for JDK-8260687. The modified test passes successfully in both modes when the proposed fix is reverted.

test/jdk/javax/swing/text/html/CSS/8231286/HtmlFontSizeTest.java

This reverts commit ce2500c.

Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk@users.noreply.github.com>

mperktold · 2021-02-05T13:02:22Z

Since this is the case, I suggest reverting the proposed fix for JDK-8260687. The modified test passes successfully in both modes when the proposed fix is reverted.

OK I did that now.

So, I take it I should't add issue JDK-8260687 then.
Should I still add you two as contributors though? Or was that just for the other issue?

aivanov-jdk · 2021-02-05T13:45:35Z

So, I take it I should't add issue JDK-8260687 then.

No, you shouldn't. JDK-8260687 remains unresolved.

Should I still add you two as contributors though? Or was that just for the other issue?

No, it was for JDK-8260687 where @prsadhuk suggested the fix and where I contributed a test.

mperktold · 2021-02-05T18:30:06Z

/integrate

openjdk · 2021-02-05T18:30:38Z

@mperktold
Your change (at version 1925b2a) is now ready to be sponsored by a Committer.

aivanov-jdk · 2021-02-08T14:31:10Z

/sponsor

openjdk · 2021-02-08T14:32:28Z

@aivanov-jdk @mperktold Since your change was applied there have been 74 commits pushed to the master branch:

dbc35f6: 8261094: Open javax/swing/text/html/CSS/4765271/bug4765271.java
db0ca2b: 8261161: Clean up warnings in hotspot/jtreg/vmTestbase tests
2c28e36: 8237352: Update DatagramSocket to add support for joining multicast groups
d0a8f2f: 8260593: javac can skip a temporary local variable when pattern matching over a local variable
deb0544: 8261251: Shenandoah: Use object size for full GC humongous compaction
d45343e: 8260899: ARM32: SyncOnValueBasedClassTest fails with assert(is_valid()) failed: invalid register
9d59dec: 8248876: LoadObject with bad base address created for exec file on linux
aa5bc6e: 8258953: AArch64: move NEON instructions to aarch64_neon.ad
c5ff454: 8250989: Consolidate buffer allocation code for CDS static/dynamic dumping
0e18634: 8261270: MakeMethodNotCompilableTest fails with -XX:TieredStopAtLevel={1,2,3}
... and 64 more: https://git.openjdk.java.net/jdk/compare/91e6c755f32dada6c62bad4ff4221aed75a0ccc2...master

Your commit was automatically rebased without conflicts.

Pushed as commit 48c932e.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Matthias Perktold and others added 8 commits January 25, 2021 13:57

Fix JDK-8231286

1eac7e2

Convert tabs to spaces

1d37c75

Removed unnecessary imports

6a2b4ef

Fixed jcheck

7c29cfa

Spaces around / operator

bcd7dba

Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk@users.noreply.github.com>

Space after comma in argument lists

7b4e87e

Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk@users.noreply.github.com>

Corrected copyright year

d10824f

Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk@users.noreply.github.com>

Make fields volatile since changed from other thread, and put them on…

159cc9f

… separate lines

openjdk bot added the swing client-libs-dev@openjdk.org label Jan 27, 2021

mperktold changed the title ~~Supersede #2223 - 8231286: HTML font size too large with high-DPI scaling and W3C_LENGTH_UNITS~~ 8231286: HTML font size too large with high-DPI scaling and W3C_LENGTH_UNITS Jan 27, 2021

openjdk bot added the rfr Pull request is ready for review label Jan 27, 2021

prsadhuk reviewed Jan 27, 2021

View reviewed changes

aivanov-jdk suggested changes Jan 29, 2021

View reviewed changes

Matthias Perktold added 7 commits February 1, 2021 12:24

Fix ratio formatting

c33ac93

Measure preferredSize of htmlPane instead of frame bounds

a134c67

Move StyleSheet rule into body tag

835dfcd

Aligned length mapping comments with space after //

0172c25

Updated copyright year of CSS.java

d52b490

Moved HtmlFontSizeTest into ./CSS/8231286

29f236a

Link to CSS 2.2 spec from length mapping comments

9560d9c

aivanov-jdk suggested changes Feb 1, 2021

View reviewed changes

Matthias Perktold added 2 commits February 2, 2021 09:34

Calculate conversion factors rather than hardcoding them for better p…

d178dbc

…recision

Remove unnecessary JFrame creation

3bce002

Fix JDK-8260687: don't use font inherit for W3C_LENGTH_UNIT

ce2500c

prsadhuk approved these changes Feb 4, 2021

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Feb 4, 2021

aivanov-jdk suggested changes Feb 4, 2021

View reviewed changes

test/jdk/javax/swing/text/html/CSS/8231286/HtmlFontSizeTest.java Outdated Show resolved Hide resolved

Matthias Perktold and others added 2 commits February 5, 2021 13:14

Revert "Fix JDK-8260687: don't use font inherit for W3C_LENGTH_UNIT"

a520bee

This reverts commit ce2500c.

Remove "@key headful" from test doc

1925b2a

Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk@users.noreply.github.com>

openjdk bot added the sponsor Pull request is ready to be sponsored label Feb 5, 2021

openjdk bot added sponsor Pull request is ready to be sponsored and removed sponsor Pull request is ready to be sponsored labels Feb 5, 2021

aivanov-jdk approved these changes Feb 5, 2021

View reviewed changes

openjdk bot closed this Feb 8, 2021

openjdk bot added integrated Pull request has been integrated and removed sponsor Pull request is ready to be sponsored ready Pull request is ready to be integrated rfr Pull request is ready for review labels Feb 8, 2021

	// mapping according to the CSS2.2 spec
	// Mapping according to the CSS2.2 spec
	// https://www.w3.org/TR/CSS22/syndata.html#length-units

		float ratio = (float)w3cFrameSize.width / (float)stdFrameSize.width;
		System.out.println("w3cFrameSize.width/stdFrameSize.width " + ratio);

8231286: HTML font size too large with high-DPI scaling and W3C_LENGTH_UNITS #2256

8231286: HTML font size too large with high-DPI scaling and W3C_LENGTH_UNITS #2256

Conversation

mperktold commented Jan 27, 2021 • edited by openjdk bot Loading

Original Description

Progress

Issue

Reviewers

Download

bridgekeeper bot commented Jan 27, 2021

openjdk bot commented Jan 27, 2021

aivanov-jdk commented Jan 27, 2021

mlbridge bot commented Jan 27, 2021 • edited Loading

Webrevs

Choose a reason for hiding this comment

prsadhuk commented Jan 29, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mperktold Feb 1, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aivanov-jdk commented Feb 1, 2021

Choose a reason for hiding this comment

prsadhuk commented Feb 2, 2021

openjdk bot commented Feb 3, 2021

kevinrushforth commented Feb 3, 2021

openjdk bot commented Feb 4, 2021 • edited Loading

prsadhuk commented Feb 4, 2021

openjdk bot commented Feb 4, 2021

aivanov-jdk commented Feb 4, 2021

prsadhuk commented Feb 4, 2021

aivanov-jdk commented Feb 4, 2021

aivanov-jdk commented Feb 4, 2021

mperktold commented Feb 5, 2021

aivanov-jdk commented Feb 5, 2021

mperktold commented Feb 5, 2021

openjdk bot commented Feb 5, 2021

aivanov-jdk commented Feb 8, 2021

openjdk bot commented Feb 8, 2021

mperktold commented Jan 27, 2021 •

edited by openjdk bot

Loading

mlbridge bot commented Jan 27, 2021 •

edited

Loading

mperktold Feb 1, 2021 •

edited

Loading

openjdk bot commented Feb 4, 2021 •

edited

Loading