RFR: 8185261: Font fallback sometimes doesn't work in Swing text components

[Dmitry Batrak]

On Tue, 1 Feb 2022 19:50:47 GMT, Sergey Bylokhov <serb 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.
>
> src/java.desktop/share/classes/java/awt/Font.java line 464:
> 
>> 462:      * should be copied to derived fonts.
>> 463:      */
>> 464:     private transient boolean withFallback;
> 
> I wonder how it will work if the Font was read from the system, then serialized/deserialized and then used?

Not sure I fully understand the question. `Font` object cannot have both `createdFont` and `withFallback` fields set, at least in the current implementation.
If we're talking about 'created' fonts (created from a file), the fix doesn't change anything with regard to their behavior - after serialization/deserialization the font might not work, I guess, if it's not registered using `GraphicsEnvironment.registerFont`. In any case, it will lose it's 'created' status, and will change behavior correspondingly.
If we're talking about 'fonts with fallback' (like the ones `JEditorPane` creates under the hood), they will lose their fallback components after serialization/deserialization. But that's also how it worked before the proposed change. I'm not going to address that problem in this PR.

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

PR: https://git.openjdk.java.net/jdk/pull/7313