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

Kevin Rushforth kcr at openjdk.java.net
Tue Feb 2 21:03:45 UTC 2021


On Tue, 2 Feb 2021 20:51:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> 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
>>> 
>>> ```
>>> 
>>> res = 93
>>> Font Size for InlineView #0 = 96; height = 96; element = {
>>>       <content
>>>         span=font-size=72pt 
>>>         font-size=72pt
>>>         name=content
>>>       >
>>>         [1,2][A]
>>> }
>>> [...]
>>> ----------System.err:(5/314)----------
>>> java.lang.RuntimeException: Test failed.
>>> ```
>> 
>> Sorry, but I don't understand. What do these examples represent? Are they the results of some tests you ran? Or should I encorporate them into the test somehow?
>> 
>> Also, regarding a resolution of 93/94/95, I think rather than hardcoding 96, we should ensure that the behavior is correct for various screen sizes. I don't know how to change the resolution just for the test, but if that is possible, I think we should test several values, like 96, something below that and something above.
>> 
>>> 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.
>>> ```
>> 
>> Just the be sure before I do that, are there going to be problems when I pull changes from master into this branch?
>> Or was [this bot comment](https://github.com/openjdk/jdk/pull/2223#issuecomment-766934951) just about the name of the branch, and everything should be fine?
>
>> 
>> Just the be sure before I do that, are there going to be problems when I pull changes from master into this branch?
>> Or was [this bot comment](https://github.com/openjdk/jdk/pull/2223#issuecomment-766934951) just about the name of the branch, and everything should be fine?
> 
> You can rebase your branch. It should work seamlessly.
> 
> Please close PR #2223.

Merging, rather than rebasing, is usually preferred as it doesn't involve force pushing and makes incremental reviews easier. The answer is the same, though: no, it won't cause problems. The bot comment was that you used "master" as the name of your branch for the other PR meaning it would diverge from the upstream openjdk/jdk master branch.

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

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


More information about the swing-dev mailing list