Re: [OpenJDK 2D-Dev] RFR: 6573239: Typo in jfc text file
1) I think this should be sent to the swing list, swing-dev since these
are swing demos AND there's a change in Swing product code.
2) Please *subscribe* to the lists before posting, else your mail will
be blocked
3) Please sign and return the OCA to make contributions.
These changes are trivial enough that probably isn't needed if this is
one-off, but
(a) it does touch a good number of places, and
(b) your contributions before signing it DO NOT COUNT towards anything
... so you may not get credit.
-phil.
On 6/6/19, 12:46 PM, Andrey Turbanov wrote:
Hello.
I would like to contribute a small patch for bug:
https://bugs.openjdk.java.net/browse/JDK-6573239
Please review and sponsor.
Index: src/demo/share/jfc/SwingSet2/resources/tree.txt
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- src/demo/share/jfc/SwingSet2/resources/tree.txt(revision
d538ae95ed30e4f055e6395455c57b0d23ee8e95)
+++ src/demo/share/jfc/SwingSet2/resources/tree.txt(date 1559849949548)
@@ -8,7 +8,7 @@
# A = Artist/ Composer
#
# R = Record/ Style
#
# S = Song Name / Composition
#
-# C = Catagory
#
+# C = Category
#
#
#
C Classical
Index:
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/tree/resources/tree.txt
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
---
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/tree/resources/tree.txt
(revision d538ae95ed30e4f055e6395455c57b0d23ee8e95)
+++
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/tree/resources/tree.txt
(date 1559849949512)
@@ -8,7 +8,7 @@
# A = Artist/ Composer
#
# R = Record/ Style
#
# S = Song Name / Composition
#
-# C = Catagory
#
+# C = Category
#
#
#
C Classical
Index:
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/tree/TreeDemo.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
---
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/tree/TreeDemo.java
(revision d538ae95ed30e4f055e6395455c57b0d23ee8e95)
+++
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/tree/TreeDemo.java
(date 1559849949535)
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2007, 2016, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2007, 2019, Oracle and/or its affiliates. All rights reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -83,7 +83,7 @@
private JTree createTree() {
DefaultMutableTreeNode top = new
DefaultMutableTreeNode(resourceManager.getString("TreeDemo.music"));
-DefaultMutableTreeNode catagory = null;
+DefaultMutableTreeNode category = null;
DefaultMutableTreeNode artist = null;
DefaultMutableTreeNode record = null;
@@ -103,12 +103,12 @@
char linetype = line.charAt(0);
switch (linetype) {
case 'C':
-catagory = new
DefaultMutableTreeNode(line.substring(2));
-top.add(catagory);
+category = new
DefaultMutableTreeNode(line.substring(2));
+top.add(category);
break;
case 'A':
-if (catagory != null) {
-catagory.add(artist = new
DefaultMutableTreeNode(line.substring(2)));
+if (category != null) {
+category.add(artist = new
DefaultMutableTreeNode(line.substring(2)));
}
break;
case 'R':
Index: src/demo/share/jfc/SwingSet2/TreeDemo.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- src/demo/share/jfc/SwingSet2/TreeDemo.java(revision
d538ae95ed30e4f055e6395455c57b0d23ee8e95)
+++ src/demo/share/jfc/SwingSet2/TreeDemo.java(date 1559849949524)
@@ -1,6 +1,6 @@
/*
*
- * Copyright (c) 2007, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2007, 2019 Oracle and/or its affiliates. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
[OpenJDK 2D-Dev] RFR: 6573239: Typo in jfc text file
Hello.
I would like to contribute a small patch for bug:
https://bugs.openjdk.java.net/browse/JDK-6573239
Please review and sponsor.
Index: src/demo/share/jfc/SwingSet2/resources/tree.txt
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- src/demo/share/jfc/SwingSet2/resources/tree.txt(revision
d538ae95ed30e4f055e6395455c57b0d23ee8e95)
+++ src/demo/share/jfc/SwingSet2/resources/tree.txt(date 1559849949548)
@@ -8,7 +8,7 @@
# A = Artist/ Composer
#
# R = Record/ Style
#
# S = Song Name / Composition
#
-# C = Catagory
#
+# C = Category
#
#
#
C Classical
Index:
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/tree/resources/tree.txt
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
---
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/tree/resources/tree.txt
(revision d538ae95ed30e4f055e6395455c57b0d23ee8e95)
+++
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/tree/resources/tree.txt
(date 1559849949512)
@@ -8,7 +8,7 @@
# A = Artist/ Composer
#
# R = Record/ Style
#
# S = Song Name / Composition
#
-# C = Catagory
#
+# C = Category
#
#
#
C Classical
Index:
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/tree/TreeDemo.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
---
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/tree/TreeDemo.java
(revision d538ae95ed30e4f055e6395455c57b0d23ee8e95)
+++
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/tree/TreeDemo.java
(date 1559849949535)
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2007, 2016, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2007, 2019, Oracle and/or its affiliates. All rights reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -83,7 +83,7 @@
private JTree createTree() {
DefaultMutableTreeNode top = new
DefaultMutableTreeNode(resourceManager.getString("TreeDemo.music"));
-DefaultMutableTreeNode catagory = null;
+DefaultMutableTreeNode category = null;
DefaultMutableTreeNode artist = null;
DefaultMutableTreeNode record = null;
@@ -103,12 +103,12 @@
char linetype = line.charAt(0);
switch (linetype) {
case 'C':
-catagory = new
DefaultMutableTreeNode(line.substring(2));
-top.add(catagory);
+category = new
DefaultMutableTreeNode(line.substring(2));
+top.add(category);
break;
case 'A':
-if (catagory != null) {
-catagory.add(artist = new
DefaultMutableTreeNode(line.substring(2)));
+if (category != null) {
+category.add(artist = new
DefaultMutableTreeNode(line.substring(2)));
}
break;
case 'R':
Index: src/demo/share/jfc/SwingSet2/TreeDemo.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- src/demo/share/jfc/SwingSet2/TreeDemo.java(revision
d538ae95ed30e4f055e6395455c57b0d23ee8e95)
+++ src/demo/share/jfc/SwingSet2/TreeDemo.java(date 1559849949524)
@@ -1,6 +1,6 @@
/*
*
- * Copyright (c) 2007, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2007, 2019 Oracle and/or its affiliates. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
@@ -74,7 +74,7 @@
public JScrollPane createTree() {
DefaultMutableTreeNode top = new
DefaultMutableTreeNode(getString("TreeDemo.music"));
-DefaultMutableTreeNode catagory = null ;
+DefaultMutableTreeNode category = null;
DefaultMutableTreeNode artist = null;
DefaultMutableTreeNode record = null;
@@ -94,12 +94,12 @@
char linetype = line.charAt(0);
switch(linetype) {
case 'C':
- catagory = new DefaultMutableTreeNode(line.substring(2));
- top.add(catagory);
+
Re: [OpenJDK 2D-Dev] [13] RFR JDK-8225368:broken links in java.desktop files
You should be able to link to public API in other modules.
There was an issue with hard-coded '` links when javadoc
added the extra level of module directory into the output hierarchy, but
those issues have now been sorted out.
-- Jon
On 06/06/2019 05:31 PM, Sergey Bylokhov wrote:
On 06/06/2019 12:50, Jonathan Gibbons wrote:
You should be able to use {@link} to refer to other Java elements;
It is possible even across the different modules?(I remember there was
some related issue)
-- Jon
On 06/06/2019 12:46 PM, Sergey Bylokhov wrote:
Hi, Prasanta.
Can you please double check is it possible to use {@link } instead
of in the java files?
For example in
src/java.desktop/share/classes/javax/print/attribute/package-info.java
Note that some of these docs use 80 chars per line alignment, please
use the same style.
On 06/06/2019 11:34, Prasanta Sadhukhan wrote:
Hi All,
Please review a doc-fix to fix broken links in java.desktop files
Bug: https://bugs.openjdk.java.net/browse/JDK-8225368
webrev: http://cr.openjdk.java.net/~psadhukhan/8225368/webrev.0/
Regards
Prasanta
Re: [OpenJDK 2D-Dev] [13] RFR JDK-8225368:broken links in java.desktop files
On 06/06/2019 12:50, Jonathan Gibbons wrote:
You should be able to use {@link} to refer to other Java elements;
It is possible even across the different modules?(I remember there was some
related issue)
-- Jon
On 06/06/2019 12:46 PM, Sergey Bylokhov wrote:
Hi, Prasanta.
Can you please double check is it possible to use {@link } instead of in
the java files?
For example in
src/java.desktop/share/classes/javax/print/attribute/package-info.java
Note that some of these docs use 80 chars per line alignment, please use the
same style.
On 06/06/2019 11:34, Prasanta Sadhukhan wrote:
Hi All,
Please review a doc-fix to fix broken links in java.desktop files
Bug: https://bugs.openjdk.java.net/browse/JDK-8225368
webrev: http://cr.openjdk.java.net/~psadhukhan/8225368/webrev.0/
Regards
Prasanta
--
Best regards, Sergey.
Re: [OpenJDK 2D-Dev] RFR: 8217731: Font rendering and glyph spacing changed from jdk-8 to jdk-11
On 6/6/19 9:12 AM, Phil Race wrote: On 6/6/19 9:11 AM, semyon.sadet...@oracle.com wrote: On 6/5/19 6:43 PM, Philip Race wrote: On 6/5/19, 4:18 PM, Semyon Sadetsky wrote: On 6/5/19 2:11 PM, Phil Race wrote: It *can* make a difference and in fact we have a regression test that now passes with this fix which tests different rendering modes. Which test is it? Why you didn't mark it with the bug id? See https://bugs.openjdk.java.net/browse/JDK-8199529 I only located this bug and verified this "resolves" it after sending out the review but it "resolves" it due to luck as much as anything definite, so I don't think it is required to link this as "solving" that. Nice that you made this discovery. Though it was more or less obvious. So, now you can remove jtreg-hard label from the bug and provide the reg-test. Again, no. Why? The test is not hard. However that is not a direct test for this potential difference. You cannot say that this change *must* make a difference, it just does. Sometimes. That's what we need to avoid regression again when fonts are updated. Font appearance directly affects user experience. Fortunately this happens not so often but we definitely need a test that will indicate such changes before the bug is reported externally like it recently happened. I thin everyone agrees that we should not repeat this omission once again. You misunderstand. There was no regression. Then why is the bug marked as regression? Not by me. But it is subjective. Then you need to remove the label and update evaluation accordingly. There was a change in behaviour which is completely allowable, and can happen all the time and is sensitive to so many things. So there was no omission. Ok, then why do we need this fix? To try to improve compatibility of rendering in 13 with what it was like in 8. No guarantees but people have reported they prefer it. Can you argument your position? For me it is a bug. Nothing can be tested and asserted to be right or wrong. And the algorithms used are outside of our control. Was it external change in Windows OS that caused the issue? If so, the bug was incorrectly evaluated. Can you update JBS with the correct one. No, it was the removal of T2K and the switch to freetype. I'm confused again, why it is not our regression? --Semyon -phil. But there is still value in the change to see if more people are happy with the alternative rendering. --Semyon -phil --Semyon -phil. On 6/5/19 1:40 PM, semyon.sadet...@oracle.com wrote: Can you clarify does the change affects font metrics? I see that it is a sub-pixel difference for each single glyph but if a long line of text can accumulate a notable difference the reg test can be provided. --Semyon On 6/5/19 11:43 AM, Phil Race wrote: bug: https://bugs.openjdk.java.net/browse/JDK-8217731 webrev: http://cr.openjdk.java.net/~prr/8217731/ This is intended to "help" but cannot completely cure, with some of the rendering differences in JDK11 vs JDK 8. In a typical Swing app on Windows using LCD rendering it manifests as subtle adjustments in the spacing between glyphs. There isn't an easy regression test for this, and it is subjective as to how bad it was before and how much this improves it, even if you were to accept that 8 is "better" .. and not just different .. -phil.
Re: [OpenJDK 2D-Dev] [13] RFR JDK-8225368:broken links in java.desktop files
Sergey, Prasanta,
You should be able to use {@link} to refer to other Java elements; you
cannot (yet) use {@link} to link to user-defined anchors in other files
(but it's on the list)
-- Jon
On 06/06/2019 12:46 PM, Sergey Bylokhov wrote:
Hi, Prasanta.
Can you please double check is it possible to use {@link } instead of
in the java files?
For example in
src/java.desktop/share/classes/javax/print/attribute/package-info.java
Note that some of these docs use 80 chars per line alignment, please
use the same style.
On 06/06/2019 11:34, Prasanta Sadhukhan wrote:
Hi All,
Please review a doc-fix to fix broken links in java.desktop files
Bug: https://bugs.openjdk.java.net/browse/JDK-8225368
webrev: http://cr.openjdk.java.net/~psadhukhan/8225368/webrev.0/
Regards
Prasanta
Re: [OpenJDK 2D-Dev] [13] RFR JDK-8225368:broken links in java.desktop files
Hi, Prasanta.
Can you please double check is it possible to use {@link } instead of in
the java files?
For example in
src/java.desktop/share/classes/javax/print/attribute/package-info.java
Note that some of these docs use 80 chars per line alignment, please use the
same style.
On 06/06/2019 11:34, Prasanta Sadhukhan wrote:
Hi All,
Please review a doc-fix to fix broken links in java.desktop files
Bug: https://bugs.openjdk.java.net/browse/JDK-8225368
webrev: http://cr.openjdk.java.net/~psadhukhan/8225368/webrev.0/
Regards
Prasanta
--
Best regards, Sergey.
[OpenJDK 2D-Dev] [13] RFR JDK-8225368:broken links in java.desktop files
Hi All, Please review a doc-fix to fix broken links in java.desktop files Bug: https://bugs.openjdk.java.net/browse/JDK-8225368 webrev: http://cr.openjdk.java.net/~psadhukhan/8225368/webrev.0/ Regards Prasanta
Re: [OpenJDK 2D-Dev] RFR: 8217731: Font rendering and glyph spacing changed from jdk-8 to jdk-11
On 6/6/19 9:11 AM, semyon.sadet...@oracle.com wrote: On 6/5/19 6:43 PM, Philip Race wrote: On 6/5/19, 4:18 PM, Semyon Sadetsky wrote: On 6/5/19 2:11 PM, Phil Race wrote: It *can* make a difference and in fact we have a regression test that now passes with this fix which tests different rendering modes. Which test is it? Why you didn't mark it with the bug id? See https://bugs.openjdk.java.net/browse/JDK-8199529 I only located this bug and verified this "resolves" it after sending out the review but it "resolves" it due to luck as much as anything definite, so I don't think it is required to link this as "solving" that. Nice that you made this discovery. Though it was more or less obvious. So, now you can remove jtreg-hard label from the bug and provide the reg-test. Again, no. However that is not a direct test for this potential difference. You cannot say that this change *must* make a difference, it just does. Sometimes. That's what we need to avoid regression again when fonts are updated. Font appearance directly affects user experience. Fortunately this happens not so often but we definitely need a test that will indicate such changes before the bug is reported externally like it recently happened. I thin everyone agrees that we should not repeat this omission once again. You misunderstand. There was no regression. Then why is the bug marked as regression? Not by me. But it is subjective. There was a change in behaviour which is completely allowable, and can happen all the time and is sensitive to so many things. So there was no omission. Ok, then why do we need this fix? To try to improve compatibility of rendering in 13 with what it was like in 8. No guarantees but people have reported they prefer it. Nothing can be tested and asserted to be right or wrong. And the algorithms used are outside of our control. Was it external change in Windows OS that caused the issue? If so, the bug was incorrectly evaluated. Can you update JBS with the correct one. No, it was the removal of T2K and the switch to freetype. -phil. But there is still value in the change to see if more people are happy with the alternative rendering. --Semyon -phil --Semyon -phil. On 6/5/19 1:40 PM, semyon.sadet...@oracle.com wrote: Can you clarify does the change affects font metrics? I see that it is a sub-pixel difference for each single glyph but if a long line of text can accumulate a notable difference the reg test can be provided. --Semyon On 6/5/19 11:43 AM, Phil Race wrote: bug: https://bugs.openjdk.java.net/browse/JDK-8217731 webrev: http://cr.openjdk.java.net/~prr/8217731/ This is intended to "help" but cannot completely cure, with some of the rendering differences in JDK11 vs JDK 8. In a typical Swing app on Windows using LCD rendering it manifests as subtle adjustments in the spacing between glyphs. There isn't an easy regression test for this, and it is subjective as to how bad it was before and how much this improves it, even if you were to accept that 8 is "better" .. and not just different .. -phil.
Re: [OpenJDK 2D-Dev] RFR: 8217731: Font rendering and glyph spacing changed from jdk-8 to jdk-11
On 6/5/19 6:43 PM, Philip Race wrote: On 6/5/19, 4:18 PM, Semyon Sadetsky wrote: On 6/5/19 2:11 PM, Phil Race wrote: It *can* make a difference and in fact we have a regression test that now passes with this fix which tests different rendering modes. Which test is it? Why you didn't mark it with the bug id? See https://bugs.openjdk.java.net/browse/JDK-8199529 I only located this bug and verified this "resolves" it after sending out the review but it "resolves" it due to luck as much as anything definite, so I don't think it is required to link this as "solving" that. Nice that you made this discovery. Though it was more or less obvious. So, now you can remove jtreg-hard label from the bug and provide the reg-test. However that is not a direct test for this potential difference. You cannot say that this change *must* make a difference, it just does. Sometimes. That's what we need to avoid regression again when fonts are updated. Font appearance directly affects user experience. Fortunately this happens not so often but we definitely need a test that will indicate such changes before the bug is reported externally like it recently happened. I thin everyone agrees that we should not repeat this omission once again. You misunderstand. There was no regression. Then why is the bug marked as regression? There was a change in behaviour which is completely allowable, and can happen all the time and is sensitive to so many things. So there was no omission. Ok, then why do we need this fix? Nothing can be tested and asserted to be right or wrong. And the algorithms used are outside of our control. Was it external change in Windows OS that caused the issue? If so, the bug was incorrectly evaluated. Can you update JBS with the correct one. But there is still value in the change to see if more people are happy with the alternative rendering. --Semyon -phil --Semyon -phil. On 6/5/19 1:40 PM, semyon.sadet...@oracle.com wrote: Can you clarify does the change affects font metrics? I see that it is a sub-pixel difference for each single glyph but if a long line of text can accumulate a notable difference the reg test can be provided. --Semyon On 6/5/19 11:43 AM, Phil Race wrote: bug: https://bugs.openjdk.java.net/browse/JDK-8217731 webrev: http://cr.openjdk.java.net/~prr/8217731/ This is intended to "help" but cannot completely cure, with some of the rendering differences in JDK11 vs JDK 8. In a typical Swing app on Windows using LCD rendering it manifests as subtle adjustments in the spacing between glyphs. There isn't an easy regression test for this, and it is subjective as to how bad it was before and how much this improves it, even if you were to accept that 8 is "better" .. and not just different .. -phil.
