Windows and Linux: Physical font does not have fallback fonts.

[Philip Race]

Right. This is on purpose.  We do not want to change that behaviour.
A font should not lie about what glyphs it contains and provide no way 
for apps
to know if that is REALLY from this font. Proper text rendering is not 
possible
if you lie to the app.

JDK on MacOS does things differently because that's the implementation 
we unfortunately inherited
from Apple. It is a real pain.

Swing implements an implicit fall back for most uses by controls where 
it is safer to assume
they just want to display some glyph, but a change to do that globally 
for Java 2D is not going to be accepted,
and even the Swing one causes some problems as there's no way to tell it 
has a fall back.

The fall back to "Dialog" if a font is not found cannot be changed. It 
is specified.

https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/Font.html#%3Cinit%3E(java.lang.String,int,int)

"If the|name|parameter represents something other than a logical font, 
i.e. is interpreted as a physical font face or family, and this cannot 
be mapped by the implementation to a physical font or a compatible 
alternative, then the font system will map the Font instance to 
"Dialog", such that for example, the family as reported by|getFamily| 
<https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/Font.html#getFamily()>will 
be "Dialog".

-phil.


On 1/12/24 4:56 AM, 林kurn wrote:
> Hi everyone,
>
> I am doing GUI development based on Java on Ubuntu, and I find some 
> problems in it.
> Would it be possible for me to discuss with you?
>
> 1. There is no fallback font on Windows and Linux when using physical 
> fonts.
> The FileFont class does not implements FontSubstitution interface, so 
> there are no substituting glyphs from another font at render time(in 
> GlyphLayout::layout).
> For example, when "jTextField.setFont(new Font("Ubuntu Mono", 
> Font.PLAIN, 20))" on Ubuntu, all the CJK characters will show as tofu 
> in this jTextField. Almost every font does not contain all possible 
> inputs, adding some fallbacks font may help those who don't just use 
> one language.
>
> 2. The fonts that JDK does not found are mapped to the “Dialog” font.
> As 
> https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/Font.html#%3Cinit%3E(java.lang.String,int,int) 
> shows, If the name parameter represents something other than a logical 
> font, i.e. is interpreted as a physical font face or family, and this 
> cannot be mapped by the implementation to a physical font or a 
> compatible alternative, then the font system will map the Font 
> instance to "Dialog".
> On Linux, get map fonts by fontconfig may be more flexible, more 
> configurable.
>
> For the two questions above, I have a preliminary patch.
>
> I added a new fallback form “FONTCONFIGURATION_FALLBACK” 
> and implemented it for Linux system, it creates a composite font by 
> obtaining map fonts info for the specified name and style through 
> fontconfig.
> And I make the FileFont class implement the FontSubstitution 
> interface, reuse the FONTCONFIGURATION_FALLBACK code.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20240112/30a4c7d7/attachment.htm>