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

[林kurn]

Thank you for your help.
I am a new hand on java, you mentioned “Swing implements an implicit fall
back for most uses by controls where it is safer to assume
they just want to display some glyph”, it means swing implicitly uses
logical font to fallback?

Philip Race <philip.race at oracle.com> 于2024年1月13日周六 03:10写道：

> 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/20240113/7306080b/attachment-0001.htm>