On Wed, 3 Feb 2021 09:55:33 GMT, Prasanta Sadhukhan
wrote:
>>>
>>>
>>> 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 y
On Wed, 3 Feb 2021 09:17:44 GMT, Matthias Perktold
wrote:
>
>
> > 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 us
On Tue, 2 Feb 2021 21:01:09 GMT, Kevin Rushforth wrote:
>
>
> 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
> "ma
On Wed, 3 Feb 2021 08:36:30 GMT, Matthias Perktold
wrote:
>
>
> > I think we should hard-code 96. Does JDK treat 93/94/95 differently? Does
> > it change font size in any other place but CSS with W3C_LENGTH_UNITS?
>
> But isn't that precesily the only situation in which the old length mappin
On Tue, 2 Feb 2021 21:35:00 GMT, Alexey Ivanov wrote:
> I think we should hard-code 96. Does JDK treat 93/94/95 differently? Does it
> change font size in any other place but CSS with W3C_LENGTH_UNITS?
But isn't that precesily the only situation in which the old length mappings
were correct al
On Tue, 2 Feb 2021 20:32:46 GMT, Alexey Ivanov 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
On Tue, 2 Feb 2021 15:16:35 GMT, Matthias Perktold
wrote:
> 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
> po
On Tue, 2 Feb 2021 20:51:26 GMT, Alexey Ivanov 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 hardco
On Tue, 2 Feb 2021 15:16:35 GMT, Matthias Perktold
wrote:
>
> 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
On Tue, 2 Feb 2021 15:16:35 GMT, Matthias Perktold
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
On Tue, 2 Feb 2021 12:29:00 GMT, Prasanta Sadhukhan
wrote:
>>>
>>>
>>> > 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 o
On Tue, 2 Feb 2021 06:20:44 GMT, Prasanta Sadhukhan
wrote:
>> Changes requested by aivanov (Reviewer).
>
>>
>>
>> > 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
On Mon, 1 Feb 2021 18:15:13 GMT, Alexey Ivanov wrote:
> 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 r
On Mon, 1 Feb 2021 23:03:30 GMT, Alexey Ivanov wrote:
>> Matthias Perktold has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Link to CSS 2.2 spec from length mapping comments
>
> Changes requested by aivanov (Reviewer).
>
>
> > It seems
On Mon, 1 Feb 2021 12:01:58 GMT, Matthias Perktold
wrote:
>> 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](https://github
On Mon, 1 Feb 2021 12:06:16 GMT, Matthias Perktold
wrote:
>
>
> > 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_LEN
On Fri, 29 Jan 2021 19:47:03 GMT, Alexey Ivanov wrote:
>> Matthias Perktold has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Link to CSS 2.2 spec from length mapping comments
>
> Changes requested by aivanov (Reviewer).
>
>
> It seems
On Mon, 1 Feb 2021 12:28:32 GMT, Matthias Perktold
wrote:
> > Does
> > ```java
> > 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 a
On Sat, 30 Jan 2021 16:22:17 GMT, Alexey Ivanov wrote:
>>> 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
On Fri, 29 Jan 2021 14:16:46 GMT, Alexey Ivanov wrote:
>> src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2870:
>>
>>> 2868: w3cLengthMapping.put("cm", 37.7952f); //96px/2.54
>>> 2869: w3cLengthMapping.put("pc", 16f); //1/6 of 1in
>>> 2870:
> 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](https://github.com/openjdk/jdk/pull/2223#issuecomment-767048399), there
> is actu
21 matches
Mail list logo
