RFR: JDK-8328750: [TestBug] Improve Stub Font Support

[Marius Hanl]

On Fri, 22 Mar 2024 22:32:25 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> In https://github.com/openjdk/jfx/pull/1405, I identified some shortcomings of the stub font implementation. As I don't want to clutter the PR with that, I decided to cherrypick the improvements I did to a new ticket and PR.
>> 
>> The current implementation has the following shortcomings:
>> - It does not reliable detect the System Font, as a consequence, tests in TableColumnHeaderTest.java are failing on my local machine
>> - Another consequence of this is, that the font size is always estimated with 0, as it is not detected
>> - One shortcoming currently is, that the stub font siie estimate is not considering bold fonts. That would improve writing tests for some scenarios, e.g. for TableColumnHeader, where we would expect that the size of the header is bigger since it is bold
>> 
>> Some tests were failing for the following reasons:
>> - `AreaChartTest.java` - `expected -30.0, was -30.00000000004` - I added ceiling to the data.
>> - `StackedBarChartTest.java` - since we now calculate correctly, the path changed
>> - A test tried to load `Helvetica`, which is not supported in the stub font loader. I changed it
>> - The default System font is considered a `Regular` one (style)
>> 
>> I wrote tests and documented the stub behaviour.
>> I did some minor changes here:
>> - System font is now detected, also in bold and italic
>> - A bold font will be calculated with a little bit more width (1px). Checkout the test as well for that
>> 
>> Note: This only changes test setup, no 'production' code.
>
> modules/javafx.graphics/src/test/java/test/com/sun/javafx/pgstub/StubFontLoader.java line 76:
> 
>> 74:                     FontHelper.setNativeFont(font, nativeFont, font.getName(), "Amble LtCn", "Regular");
>> 75:             case "amble light condensed italic" ->
>> 76:                     FontHelper.setNativeFont(font, nativeFont, font.getName(), "Amble LtCn", "Italic");
> 
> does it make sense to handle/log the default case, or this is indeed the desired code (i.e. a no-op)?

Right now, if we try to load a font that is not known by the test setup, the font will not have a 'native font' since no branch will get executed. With that, the width calculation will return 0.

Just checked the Prism font code, there the code will fallback to the system font if it can not load the specified font (family). 
That would also be an idea here, not sure if it will have consequences on some tests. Also okay for me. What do you think?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1422#discussion_r1538339248