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.
