Re: RFR JDK-8244324: RTFEditorKit does not display some of Japanese characters correctly

[Sergey Bylokhov]

+1

On 6/25/20 4:24 am, Prasanta Sadhukhan wrote:

Since we are not able to test other CJK locale locally, I think it's better to 
commit this fix in early phase of jdk16 so that it is allowed to bake and also 
allow other CJK locale customer to test it out.

Anyways, it seems to work for default cases in Font2DTest.

If there are no objections, I will sponsor this as I am ok with this fix.

Regards
Prasanta
On 15-May-20 12:34 PM, Prasanta Sadhukhan wrote:


Thanks Vyom. You could have proposed the patch yourself only...

Anyways, I have tested with Font2DTest with all unicodes for default Latin and 
it seems ok. Will you be able to test in other CJK locales (as  I am not sure 
of the unicodes being displayed correctly) just to ensure they are not 
adversely affected?

Regards
Prasanta
On 14-May-20 9:01 PM, Vyom Tiwari wrote:

Hi prasanta,

Code changes look OK to me, although I am not a expert in this area, but  the 
same patch resolves the issue at our end.
Thanks,
Vyom

On Thu, May 14, 2020 at 4:20 PM Prasanta Sadhukhan mailto:prasanta.sadhuk...@oracle.com>> wrote:

Hi All,

Please review a fix for an issue seen whereby RTFEditorKit used to read 
Japanese characters reads some garbage characters.

The default character set used for the RTF document is set to "ansi" in our 
RTFReader.java.
And share/classes/javax/swing/text/rtf/charsets/ansi.txt code table has undefined 
values , i.e., 91-98 and A0 are "0". According to 
javax/swing/text/rtf/RTFParser.java, If the ch is 0, handleText() is not called

As per http://www.biblioscape.com/rtf15_spec.htm#Heading8,

/RTF file includes the following Character set in its header : //
// //
// (\ansi | \mac | \pc | \pca)? \ansicpgN? //
//Where, //
//\ansicpgN This keyword represents the default ANSI code page used to 
perform the *Unicode to ANSI conversion* when writing RTF text. N represents 
the code page in decimal. This is typically set to the default ANSI code page 
of the run-time environment (for example, \ansicpg1252 for U.S. Windows). The 
reader can use the same ANSI code page to convert ANSI text back to Unicode. 
This keyword should be emitted in the RTF header section right after the \ansi, 
\mac, \pc or \pca keyword. /

Possible values include those in the following table.We can make use of 
ansicpgN (can switch ANSI text to Unicode), define it to refer to the 
latin1TranslationTable [RTFParser inherits it from AbstractFilter] which does 
not include undefined areas instead of ansi's translationTable which has 
undefined areas as seen above.

Bug: https://bugs.openjdk.java.net/browse/JDK-8244324

webrev: http://cr.openjdk.java.net/~psadhukhan/8244324/webrev.0/

Note: I am not able to create a testcase for this as it involves reading 
from rtf file which probably is copyrighted and inserting Japanese characters 
as a string (instead of rtf file) was not working.



--
Thanks,
Vyom



--
Best regards, Sergey.

Re: RFR 8245921:Minor copy/paste issue in BasicScrollBarUI

[Sergey Bylokhov]

Hi, Prasanta.

The change looks fine, but can you please attach to the bug report the images
before/after the fix. Just to be sure that it will look good.

On 6/25/20 4:23 am, Prasanta Sadhukhan wrote:

Hi All,

Please review a small fix for a minor copy/paste error in 
javax.swing.plaf.basic.BasicScrollBarUI.installDefaults()

if ("large".equals(scaleKey)){
 scrollBarWidth *= 1.15;
 incrGap *= 1.15;
 decrGap *= 1.15;
 } else if ("small".equals(scaleKey)){
 scrollBarWidth *= 0.857;
 incrGap *= 0.857;
 decrGap *= 0.714;
 } else if ("mini".equals(scaleKey)){
 scrollBarWidth *= 0.714;
 incrGap *= 0.714;
 decrGap *= 0.714;
 }

In the "small" case, decrGap is multiplied by 0.714 instead of 0.857.

This code snippet has been added as part of the enhancement to support Nimbus L in 
JDK-6591875. 

In SynthScrollBarUI.java which is also added as part of above JBS, the correct 
value is used 
http://hg.openjdk.java.net/jdk/client/annotate/43e06bc950ec/jdk/src/share/classes/javax/swing/plaf/synth/SynthScrollBarUI.java#l116

Bug: https://bugs.openjdk.java.net/browse/JDK-8245921

diff -r b1bd79b486bc 
src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java
--- 
a/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java 
Wed Jun 10 12:43:22 2020 +0530
+++ 
b/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java 
Thu Jun 25 12:57:37 2020 +0530
@@ -270,7 +270,7 @@
  } else if ("small".equals(scaleKey)){
  scrollBarWidth *= 0.857;
  incrGap *= 0.857;
-    decrGap *= 0.714;
+    decrGap *= 0.857;
  } else if ("mini".equals(scaleKey)){
  scrollBarWidth *= 0.714;
  incrGap *= 0.714;

Regards
Prasanta



--
Best regards, Sergey.

Re: RFR: 8197560: test javax/swing/JTree/8003400/Test8003400.java fails

[Sergey Bylokhov]

The change looks fine, but please confirm that the test will fail on the build 
before JDK-8003400 was fixed.
BTW the new bugid in the @bug tag is not necessary.

On 6/26/20 12:01 pm, Pankaj Bansal wrote:

Hi Sergey/Prasanta,

I have made changes to the test to work on all platforms. I have also made changes 
to run it on all installed look and feels on the platforms. The test is passing on 
all L on all platforms. Link in the JBS.

webrev: http://cr.openjdk.java.net/~pbansal/8197560/webrev01/ 



Regards,

Pankaj


On 26/06/20 9:39 PM, Sergey Bylokhov wrote:

On 6/25/20 9:27 pm, Prasanta Sadhukhan wrote:

sting only in windows, then probably we need to move the bugfix to 
WindowsTreeUI before changing the test to windows-only.


I think that even if the fix could be moved to WindowsTreeUI, the use case
which caused the bug is not windows specific, and could potentially exist
on other L and platforms. SO it is better to update the test to work on all
platforms/L






--
Best regards, Sergey.

Re: No action events in Toolkit when triggering JButton

[Sergey Bylokhov]

Hi, Mark.

Looks like it was just overlooked, I suggest to file a bug:
https://bugreport.java.com/bugreport

On 6/22/20 2:46 pm, Mark Staller wrote:

It doesn't seem like java.awt.Toolkit receives any
java.awt.AWTEvent.ACTION_EVENT_MASK or ActionEvent.ACTION_PERFORMED
when triggering a javax.swing.JButton.

Toolkit.getDefaultToolkit()
     .addAWTEventListener(
     event -> {
     System.out.println(event);
     },
     AWTEvent.ACTION_EVENT_MASK | AWTEvent.MOUSE_EVENT_MASK |
ActionEvent.ACTION_PERFORMED);

I get the java.awt.event.MouseEvent (MOUSE_MOVED, MOUSE_CLICKED) from
javax.swing.JButton, but no action events. I do get the action events
from java.awt.Button though.

Is this normal, expected behavior? Would have been nice to also get
action events from swing components.



--
Best regards, Sergey.