Java 2D provides several logical font families that are always present (eg SansSerif,
Serif) and these may be implemented as composites of several physical fonts.
The fonts that are used to implement the logical fonts are selected by the JRE to
be good choices for the platform using criteria such as quality, code point coverage,
expectation of being availabile (installed) and usage by the native desktop so that
the fonts are familiar.

For many applications this is simple and sufficient. However some applications
will prefer to use a specific physical font, perhaps even one created via
Font.createFont(). However it is unlikely that any single physical font will have
the same code point coverage as composite fonts, so in these cases the application
needs a way to specify that some particular font (or fonts) may be used for
additional fallbacks. This is sometimes called "font linking".

One approach to this might be to transparently always imply a composite font
as a fallback to any physical font. However there are semantic questions about
this. For example what should Font.canDisplay() return when the code point is
actually located in a fallback?

It is not clear that Java 2D at the pure Graphics layer should apply such fallbacks
without input from the application.

Perhaps this could be as simple as an API call on a "Font" instance to add
a fallback font, perhaps meaning some default fallback. Whether that is simple
or practical in implementation terms is TBD, and also TBD is whether there are
issues such as if that is propagated to some place where the pure physical font
was expected.

For cases such as Swing, where it is probably desirable, perhaps the toolkit could
specify this on its Fonts so most applications would not need to do anything.

Perhaps rather than adding to an existing Font, which may be disruptive to code
that was not expecting the Font to be "augmented", we could add new Font constructors
or deriveFont() methods, which may take explicit Font parameters or a new
TextAttribute which references a fallback.

This highlights that are also semantic issues in constructing a new Font instance
where applications may be accustomed to just asking for the string name of a font
and constructing a new Font with the same name and expect it to have the same
behaviour except for perhaps a different size.
Applications which treated a font as fully described by its string name would
not be able to leverage these behaviours, however such applications are already
overlooking many attributes of a font.