FontManager

Referenced by code in the JDK which wants to test for the maximum char code for which layout may be required. Note this does not account for supplementary characters where the caller interprets 'layout' to mean any case where one 'char' (ie the java type char) does not map to one glyph

Referenced by code in the JDK which wants to test for the minimum char code for which layout may be required. Note that even basic latin text can benefit from ligatures, eg "ffi" but we presently apply those only if explicitly requested with TextAttribute.LIGATURES_ON. The value here indicates the lowest char code for which failing to invoke layout would prevent acceptable rendering.

This method is provided for internal and exclusive use by Swing.

This method is provided for internal and exclusive use by Swing. It may be used in conjunction with fontSupportsDefaultEncoding(Font) In the event that a desktop properties font doesn't directly support the default encoding, (ie because the host OS supports adding support for the current locale automatically for native apps), then Swing calls this method to get a font which uses the specified font for the code points it covers, but also supports this locale just as the standard composite fonts do. Note: this will over-ride any setting where an application specifies it prefers locale specific composite fonts. The logic for this, is that this method is used only where the user or application has specified that the native L&F be used, and that we should honour that request to use the same font as native apps use. The behaviour of this method is to construct a new composite Font object that uses the specified physical font as its first component, and adds all the components of "dialog" as fall back components. The method currently assumes that only the size and style attributes are set on the specified font. It doesn't copy the font transform or other attributes because they aren't set on a font created from the desktop. This will need to be fixed if use is broadened. Operations such as Font.deriveFont will work properly on the font returned by this method for deriving a different point size. Additionally it tries to support a different style by calling getNewComposite() below. That also supports replacing slot zero with a different physical font but that is expected to be "rare". Deriving with a different style is needed because its been shown that some applications try to do this for Swing FontUIResources. Also operations such as new Font(font.getFontName(..), Font.PLAIN, 14); will NOT yield the same result, as the new underlying CompositeFont cannot be "looked up" in the font registry. This returns a FontUIResource as that is the Font sub-class needed by Swing. Suggested usage is something like : FontUIResource fuir; Font desktopFont = getDesktopFont(..); // NOTE even if fontSupportsDefaultEncoding returns true because // you get Tahoma and are running in an English locale, you may // still want to just call getCompositeFontUIResource() anyway // as only then will you get fallback fonts - eg for CJK. if (FontManager.fontSupportsDefaultEncoding(desktopFont)) { fuir = new FontUIResource(..); } else { fuir = FontManager.getCompositeFontUIResource(desktopFont); } return fuir;

If there is anything in the text which triggers a case where char->glyph does not map 1:1 in straightforward left->right ordering, then this method returns true. Scripts which might require it but are not treated as such due to JDK implementations will not return true. ie a 'true' return is an indication of the treatment by the implementation. Whether supplementary characters should be considered is dependent on the needs of the caller. Since this method accepts the 'char' type then such chars are always represented by a pair. From a rendering perspective these will all (in the cases I know of) still be one unicode character -> one glyph. But if a caller is using this to discover any case where it cannot make naive assumptions about the number of chars, and how to index through them, then it may need the option to have a 'true' return in such a case.

Used by windows printing to assess if a font is likely to be layout compatible with JDK TrueType fonts should be, but if they have no GPOS table, but do have a GSUB table, then they are probably older fonts GDI handles differently.