FontUtilities.java revision 3171
2362N/A * Copyright (c) 2008, Oracle and/or its affiliates. All rights reserved. 1687N/A * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. 1687N/A * This code is free software; you can redistribute it and/or modify it 1687N/A * under the terms of the GNU General Public License version 2 only, as 2362N/A * published by the Free Software Foundation. Oracle designates this 1687N/A * particular file as subject to the "Classpath" exception as provided 2362N/A * by Oracle in the LICENSE file that accompanied this code. 1687N/A * This code is distributed in the hope that it will be useful, but WITHOUT 1687N/A * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 1687N/A * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License 1687N/A * version 2 for more details (a copy is included in the LICENSE file that 1687N/A * You should have received a copy of the GNU General Public License version 1687N/A * 2 along with this work; if not, write to the Free Software Foundation, 1687N/A * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. 2362N/A * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA 2362N/A * or visit www.oracle.com if you need additional information or have any 1687N/A * A collection of utility methods. 1687N/A // This static initializer block figures out the OS constants. 1687N/A * Referenced by code in the JDK which wants to test for the 1687N/A * minimum char code for which layout may be required. 1687N/A * Note that even basic latin text can benefit from ligatures, 1687N/A * eg "ffi" but we presently apply those only if explicitly 1687N/A * requested with TextAttribute.LIGATURES_ON. 1687N/A * The value here indicates the lowest char code for which failing 1687N/A * to invoke layout would prevent acceptable rendering. 1687N/A * Referenced by code in the JDK which wants to test for the 1687N/A * maximum char code for which layout may be required. 1687N/A * Note this does not account for supplementary characters 1687N/A * where the caller interprets 'layout' to mean any case where 1687N/A * one 'char' (ie the java type char) does not map to one glyph 1687N/A * Calls the private getFont2D() method in java.awt.Font objects. 1687N/A * @param font the font object to call 1687N/A * @return the Font2D object returned by Font.getFont2D() 1687N/A * If there is anything in the text which triggers a case 1687N/A * where char->glyph does not map 1:1 in straightforward 1687N/A * left->right ordering, then this method returns true. 1687N/A * Scripts which might require it but are not treated as such 1687N/A * due to JDK implementations will not return true. 1687N/A * ie a 'true' return is an indication of the treatment by 1687N/A * Whether supplementary characters should be considered is dependent 1687N/A * on the needs of the caller. Since this method accepts the 'char' type 1687N/A * then such chars are always represented by a pair. From a rendering 1687N/A * perspective these will all (in the cases I know of) still be one 1687N/A * unicode character -> one glyph. But if a caller is using this to 1687N/A * discover any case where it cannot make naive assumptions about 1687N/A * the number of chars, and how to index through them, then it may 1687N/A * need the option to have a 'true' return in such a case. 1687N/A /* This is almost the same as the method above, except it takes a 1687N/A * char which means it may include undecoded surrogate pairs. 1687N/A * The distinction is made so that code which needs to identify all 1687N/A * cases in which we do not have a simple mapping from 1687N/A * char->unicode character->glyph can be be identified. 1687N/A * For example measurement cannot simply sum advances of 'chars', 1687N/A * the caret in editable text cannot advance one 'char' at a time, etc. 1687N/A * These callers really are asking for more than whether 'layout' 1687N/A * needs to be run, they need to know if they can assume 1->1 1687N/A /* If the character code falls into any of a number of unicode ranges 1687N/A * where we know that simple left->right layout mapping chars to glyphs 1687N/A * 1:1 and accumulating advances is going to produce incorrect results, 1687N/A * we want to know this so the caller can use a more intelligent layout 1687N/A * approach. A caller who cares about optimum performance may want to 1687N/A * check the first case and skip the method call if its in that range. 1687N/A * Although there's a lot of tests in here, knowing you can skip 1687N/A * CTL saves a great deal more. The rest of the checks are ordered 1687N/A * so that rather than checking explicitly if (>= start & <= end) 1687N/A * which would mean all ranges would need to be checked so be sure 1687N/A * CTL is not needed, the method returns as soon as it recognises 1687N/A * the code point is outside of a CTL ranges. 1687N/A * NOTE: Since this method accepts an 'int' it is asssumed to properly 1687N/A * represent a CHARACTER. ie it assumes the caller has already 1687N/A * converted surrogate pairs into supplementary characters, and so 1687N/A * can handle this case and doesn't need to be told such a case is 1687N/A // Trigger layout for combining diacriticals 0x0300->0x036f 1687N/A // No automatic layout for Greek, Cyrillic, Armenian. 1687N/A return false;
// Syriac and Thaana 1687N/A // if Indic, assume shaping for conjuncts, reordering: 1687N/A // 0E00 - 0E7F if Thai, assume shaping for vowel, tone marks 3171N/A else if (
code <=
0x0fff) {
// U+0F00 - U+0FFF Tibetan 3171N/A else if (
code <
0x11ff) {
// U+1100 - U+11FF Old Hangul 1687N/A else if (
code <=
0x17ff) {
// 1780 - 17FF Khmer 1687N/A else if (
code >=
0x202a &&
code <=
0x202e) {
// directional control 1687N/A else if (
code >=
0x206a &&
code <=
0x206f) {
// directional control 1687N/A // The following methods are used by Swing. 1687N/A /* Revise the implementation to in fact mean "font is a composite font. 1687N/A * This ensures that Swing components will always benefit from the 1687N/A * This method is provided for internal and exclusive use by Swing. 1687N/A * It may be used in conjunction with fontSupportsDefaultEncoding(Font) 1687N/A * In the event that a desktop properties font doesn't directly 1687N/A * support the default encoding, (ie because the host OS supports 1687N/A * adding support for the current locale automatically for native apps), 1687N/A * then Swing calls this method to get a font which uses the specified 1687N/A * font for the code points it covers, but also supports this locale 1687N/A * just as the standard composite fonts do. 1687N/A * Note: this will over-ride any setting where an application 1687N/A * specifies it prefers locale specific composite fonts. 1687N/A * The logic for this, is that this method is used only where the user or 1687N/A * application has specified that the native L&F be used, and that 1687N/A * we should honour that request to use the same font as native apps use. 1687N/A * The behaviour of this method is to construct a new composite 1687N/A * Font object that uses the specified physical font as its first 1687N/A * component, and adds all the components of "dialog" as fall back 1687N/A * The method currently assumes that only the size and style attributes 1687N/A * are set on the specified font. It doesn't copy the font transform or 1687N/A * other attributes because they aren't set on a font created from 1687N/A * the desktop. This will need to be fixed if use is broadened. 1687N/A * Operations such as Font.deriveFont will work properly on the 1687N/A * font returned by this method for deriving a different point size. 1687N/A * Additionally it tries to support a different style by calling 1687N/A * getNewComposite() below. That also supports replacing slot zero 1687N/A * with a different physical font but that is expected to be "rare". 1687N/A * Deriving with a different style is needed because its been shown 1687N/A * that some applications try to do this for Swing FontUIResources. 1687N/A * Also operations such as new Font(font.getFontName(..), Font.PLAIN, 14); 1687N/A * will NOT yield the same result, as the new underlying CompositeFont 1687N/A * cannot be "looked up" in the font registry. 1687N/A * This returns a FontUIResource as that is the Font sub-class needed 1687N/A * Suggested usage is something like : 1687N/A * Font desktopFont = getDesktopFont(..); 1687N/A * // NOTE even if fontSupportsDefaultEncoding returns true because 1687N/A * // you get Tahoma and are running in an English locale, you may 1687N/A * // still want to just call getCompositeFontUIResource() anyway 1687N/A * // as only then will you get fallback fonts - eg for CJK. 1687N/A * if (FontManager.fontSupportsDefaultEncoding(desktopFont)) { 1687N/A * fuir = new FontUIResource(..); 1687N/A * fuir = FontManager.getCompositeFontUIResource(desktopFont); 1687N/A /* Swing should only be calling this when a font is obtained 1687N/A * from desktop properties, so should generally be a physical font, 1687N/A * an exception might be for names like "MS Serif" which are 1687N/A * automatically mapped to "Serif", so there's no need to do 1687N/A * anything special in that case. But note that suggested usage 1687N/A * is first to call fontSupportsDefaultEncoding(Font) and this 1687N/A * method should not be called if that were to return true. 1687N/A /* marking this as a created font is needed as only created fonts 1687N/A * copy their creator's handles. 1687N/A {
"sans-serif",
"sansserif"},
1687N/A {
"monospace",
"monospaced"}
1687N/A /* This is called by Swing passing in a fontconfig family name 1687N/A * such as "sans". In return Swing gets a FontUIResource instance 1687N/A * that has queried fontconfig to resolve the font(s) used for this. 1687N/A * Fontconfig will if asked return a list of fonts to give the largest 1687N/A * possible code point coverage. 1687N/A * For now we use only the first font returned by fontconfig, and 1687N/A * back it up with the most closely matching JDK logical font. 1687N/A * Essentially this means pre-pending what we return now with fontconfig's 1687N/A * preferred physical font. This could lead to some duplication in cases, 1687N/A * if we already included that font later. We probably should remove such 1687N/A * duplicates, but it is not a significant problem. It can be addressed 1687N/A * later as part of creating a Composite which uses more of the 1687N/A * same fonts as fontconfig. At that time we also should pay more 1687N/A * attention to the special rendering instructions fontconfig returns, 1687N/A * such as whether we should prefer embedded bitmaps over antialiasing. 1687N/A * There's no way to express that via a Font at present. 1687N/A * Used by windows printing to assess if a font is likely to 1687N/A * be layout compatible with JDK 1687N/A * TrueType fonts should be, but if they have no GPOS table, 1687N/A * but do have a GSUB table, then they are probably older 1687N/A * fonts GDI handles differently.