In the test
56 textPane.setFont(new java.awt.Font("Arial", Font.PLAIN, 12));
you should use a font you know exists. If the idea is that this test is just
for windows, then @requires windows ?
And
94 System.setProperty( "sun.java2d.uiScale", "1.5" );
should be set as a command line property to the test since that is what we do
elsewhere, then you can have the test run several times at different scales.
Also currently 1.5 is truncated to 1 except on Windows ...
If you want to test on Linux or Mac you need 2.
Another reason to use the command line way of doing it.
-phil
On 4/16/20, 3:16 AM, Prasanta Sadhukhan wrote:
Hi All,
Please review a fix for an issue where it is seen that, with a screen
resolution higher than 100% and then clicking in a JTextPane, the
caret (insertion point) is not aligned with the cursor.
The issue seems to stem from the fact that caret position calculation
in DefaultCaret class utilises API that uses integer calculation than
floating point calculations.
This issue is in continuation to the fix done for JDK-8199441 where
the issue was fixed for JTextArea.
[http://hg.openjdk.java.net/jdk/jdk/rev/480c2ae4d031]
The code flow for JTextArea was
DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.viewToModel=>CompositeView#viewToModel=>WrappedPlainView#viewToModel=>Utilities.getTabbedOffset
whereas for JTextPane it it is
DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.viewToModel=>CompositeView#viewToModel=>GlyphPainter1#viewToModel=>Utilities.getTabbedOffset
Now, getTabbedOffset utilises FontMetrics.charsWidth() which uses
integer arithmetic to get the caret position.
The same getTabbedOffset uses Font.getStringBounds() which uses
floating point arithmetic via Rectangle2D.Float.
Proposed fix is to make sure proper floating point getTabbedOffset API
is used so that floating point calculations is done for char width.
Bug:https://bugs.openjdk.java.net/browse/JDK-8232243
webrev: http://cr.openjdk.java.net/~psadhukhan/8232243/webrev.0/
Regards
Prasanta
