RFR: 8185261: Font fallback sometimes doesn't work in Swing text components [v2]
Dmitry Batrak
dbatrak at openjdk.java.net
Mon Apr 18 10:00:39 UTC 2022
On Tue, 1 Feb 2022 21:40:53 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:
>> The proposed fix makes fonts with and without fallback components distinguishable (in terms of `equals` method), so that
>> font metrics cache (and other similar code) can handle them separately. This is achieved by adding a new boolean field
>> to `Font` class, specifically denoting fonts with fallback components. The latter ones don't need to pretend to be
>> 'created' fonts anymore, to preserve their `Font2D` handle.
>> It's not possible to use the existing `createdFont` field in `equals` implementation, as JCK requires a 'real' created
>> font (the one obtained using `Font.createFont` method) to be equal to the same font after serialization and
>> deserialization.
>
> Dmitry Batrak has updated the pull request incrementally with one additional commit since the last revision:
>
> remove 'headful' requirement from test case
Still waiting for a response.
If you're not comfortable with changing `Font.equals` behaviour, let's introduce some other public method, which can be used to distinguish fonts with and without fallback components. I believe, it should be in public API, as the issue isn't just about JEditorPane (etc) implementation. Even though it's not a documented feature, client code can easily construct a font with fallback components using existing public API - one should just use `new javax.swing.text.StyleContext().getFont(family, style, size)` instead of `new java.awt.Font(family, style, size)`.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7313
More information about the client-libs-dev
mailing list