Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6407157

RFE: Means to specify a Font with fallbacks for additional code point coverage

    XMLWordPrintable

    Details

    • Subcomponent:
      2d
    • Understanding:
      Cause Known
    • CPU:
      generic, x86
    • OS:
      generic, linux, windows_xp

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              prr Philip Race
              Reporter:
              prr Philip Race
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Imported:
                Indexed: