JDK-8356812 : Create an automated version of TextLayout/TestControls
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: 2d
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2025-05-12
  • Updated: 2025-05-30
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
Description
The java/awt/font/TextLayout/TestControls.java test can be partially automated.

The test paints different control characters and their widths. The width has to be zero.

The fact whether the width of a control character is zero or not is easily verifiable in an automated test.

If the TextLayout/TestControls.java test had been automated, we would've noticed the problem in JDK-8356803 sooner.

The manual test can exist along side to verify that all the characters are rendered as expected.
Comments
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/25560 Date: 2025-05-30 23:40:22 +0000
30-05-2025

It should be pretty easy to incorporate this into `test/jdk/java/awt/font/TextLayout/FormatCharAdvanceTest.java`: - Update test font to include glyphs for U+0020, U+0009, U+000A, U+000D, U+2028, U+2029 - Add calls to `new TextLayout(s, font, frc).draw(g2d, x, y)` in `testChar(...)` - Add tests in `testChars(...)` for U+0009, U+000A, U+000D, U+2028, U+2029, U+206A, U+206B, U+206C, U+206D, U+206E, U+206F We just need some clarity in JDK-8356803 on how we actually want to handle some of these characters first.
26-05-2025