Registered features - definitions and implementations (f – j) (OpenType 1.8.2)
a - e | f - j | k - o | p - t | u - z
Tag: “falt”
Friendly name: Final Glyph on Line Alternates
Registered by: Microsoft
Function: Replaces line final glyphs with alternate forms specifically designed for this purpose (they would have less or more advance width as need may be), to help justification of text.
Example: In the Arabic script, providing alternate forms for line final glyphs would result in better justification. eg. replacing a long tailed Yeh-with-tail with one that has a slightly longer/shorter tail.
Recommended implementation: The falt table maps line final glyphs (in isolated or final forms) to their corresponding alternate forms (GSUB lookup type 3).
Application interface: For GIDs found in the falt coverage table, the application passes a GID to the table and gets back a new GID.
UI suggestion: This feature could be made active or inactive by default, at the user’s preference.
Script/language sensitivity: Can be used in any cursive script.
Feature interaction: Would need to be applied last, only after all other features have been applied to the run.
Tag: “fin2”
Friendly name: Terminal Form #2
Registered by: Microsoft
Function: Replaces the Alaph glyph at the end of Syriac words with its appropriate form, when the preceding base character cannot be joined to, and that preceding base character is not a Dalath, Rish, or dotless Dalath-Rish.
Example: When an Alaph is preceded by a He, the Alaph would be replaced by an appropriate form.
This feature is used only for the Syriac script alaph character.
Recommended implementation: The fin2 table maps default alphabetic forms to corresponding final forms (GSUB lookup type 5).
Application interface: The application is responsible for noting word boundaries. For GIDs in the middle of words and found in the fin2 coverage table, the application passes a GID to the feature and gets back a new GID.
UI suggestion: This feature should be on by default.
Script/language sensitivity: Used only with the Syriac script.
Feature interaction: This feature may be used in combination with other substitution (GSUB) features, whose results it may override. See also 'init' and 'fina'.
Tag: “fin3”
Friendly name: Terminal Form #3
Registered by: Microsoft
Function: Replaces Alaph glyphs at the end of Syriac words when the preceding base character is a Dalath, Rish, or dotless Dalath-Rish.
Example: When an Alaph is preceded by a Dalath, the Alaph would be replaced by an appropriate form.
This feature is used only for the Syriac script alaph character.
Recommended implementation: The fin3 table maps default alphabetic forms to corresponding final forms (GSUB lookup type 5).
Application interface: The application is responsible for noting word boundaries. For GIDs in the middle of words and found in the fin3 coverage table, the application passes a GID to the feature and gets back a new GID.
UI suggestion: This feature should be on by default.
Script/language sensitivity: Used only with the Syriac script.
Feature interaction: This feature may be used in combination with other substitution (GSUB) features, whose results it may override. See also 'init' and 'fina'.
Tag: 'fina'
Note: This feature description was significantly revised in 2016.
Friendly name: Terminal Forms
Registered by: Microsoft/Adobe
Function: Replaces glyphs for characters that have applicable joining properties with an alternate form when occurring in a final context. This applies to characters that have one of the following Unicode Joining_Type property values:
- Right_Joining, if the characters are from a right-to-left script.
- Left_Joining, if the characters are from a left-to-right script.
- Dual_Joining.
Unicode Joining_Type property values are obtained from the Unicode Character Database (UCD). Specifically, Joining_Type property values are documented in the UCD file, ArabicShaping.txt, the current version of which is available at http://www.unicode.org/Public/UCD/latest/ucd/ArabicShaping.txt .
Example: In an Arabic-script font, the application would apply the 'fina' feature to the letter ARABIC LETTER WAW (U+0648 “و”) when it follows a left-joining character, thereby replacing the default “و” glyph with its right-joining, final form.
Recommended implementation: The 'fina' feature is used to map default forms to corresponding single-joining, final forms. This will usually be implemented using a single substitution (type 1) GSUB lookup, though contextual substitution GSUB lookups (types 5, 6 or 8) may also be appropriate.
Application interface: The application is responsible for parsing character strings and identifying which of the joining-related features — initial forms ('init'), medial forms ('medi'), terminal forms ('fina'), and isolated forms ('isol') — to apply to which GIDs, based on character Joining_Type properties. Additional factors, such as the presence of control characters, may also be considered. For GIDs to which the 'fina' feature is applied and that are found in the 'fina' coverage table, the application passes a GID to the lookup tables associated with the feature and gets back a new GID.
UI suggestion: In recommended usage, this feature triggers substitutions that are required for correct display of the given script. It should be applied by default in the appropriate contexts, as determined by script-specific processing. Control of the feature should not generally be exposed to the user.
Script/language sensitivity: Can be used in any script with joining behavior — that is, the scripts for which Joining_Type properties are given explicitly in ArabicShaping.txt.
Feature interaction: This feature may be used in combination with other substitution (GSUB) features, whose results it may override. See also 'init', 'isol' and 'medi'.
Tag: 'flac'
Friendly name: Flattened ascent forms
Registered by: Microsoft
Function: This feature provides flattened forms of accents to be used over high-rise bases such as capitals. This feature should only change the shape of the accent and should not move it in the vertical or horizontal direction. Moving of the accents is done by the math handling client. Accents are flattened by the Math engine if their base is higher than MATH.MathConstants. FlattenedAccentBaseHeight.
Example: Depending on the font parameters, a lowercase a with tilde may used in default form and an uppercase A with tilde may use the flattened form
Recommended implementation: Single substitution, replacing ascent glyph with its flattened form. See MATH table specification for details.
Application interface: Feature is invoked automatically by math layout handler depending on height of the base formula box.
UI suggestion: In recommended usage, this feature triggers substitutions that are required for correct display of math formula. It should be applied in the appropriate contexts, as determined by math layout handler. Control of the feature should not generally be exposed to the user.
Script/language sensitivity: Applied to math formula layout.
Feature interaction: This feature is applied to individual glyphs during layout of math formula.
Tag: 'frac'
Friendly name: Fractions
Registered by: Microsoft/Adobe
Function: Replaces figures separated by a slash with ‘common’ (diagonal) fractions.
Example: The user enters 3/4 in a recipe and gets the threequarters fraction.
Recommended implementation: The frac table maps sets of figures separated by slash or fraction characters to corresponding fraction glyphs in the font. These may be precomposed fractions (GSUB lookup type 4) or arbitrary fractions (GSUB lookup type 1).
Application interface: The application must define the full sequence of GIDs to be replaced, based on user input (i.e. user selection determines the string’s delimitation). When the full sequence is found in the frac coverage table, the application passes the sequence to the frac table and gets a new GID in return. When the frac table does not contain an exact match, the application performs two steps. First, it uses the numr feature (see below) to replace figures (as used in the numr coverage table) preceding the slash with numerators, and to replace the typographic slash character (U+002F) with the fraction slash character (U+2044). Second, it uses the dnom feature (see below) to replace all remaining figures (as listed in the dnom coverage table) with denominators.
UI suggestion: This feature should be off by default.
Script/language sensitivity: None.
Feature interaction: This feature may require the application to call the numr and dnom features. It may be used in combination with other substitution (GSUB) features, whose results it may override.
Tag: 'fwid'
Friendly name: Full Widths
Registered by: Adobe
Function: Replaces glyphs set on other widths with glyphs set on full (usually em) widths. In a CJKV font, this may include “lower ASCII” Latin characters and various symbols. In a European font, this feature replaces proportionally-spaced glyphs with monospaced glyphs, which are generally set on widths of 0.6 em.
Example: The user may invoke this feature in a Japanese font to get full monospaced Latin glyphs instead of the corresponding proportionally-spaced versions.
Recommended implementation: The font may contain alternate glyphs designed to be set on full widths (GSUB lookup type 1), or it may specify alternate (full-width) metrics for the proportional glyphs (GPOS lookup type 1).
Application interface: For GIDs found in the fwid coverage table, the application passes the GIDs to the table and gets back either new GIDs or positional adjustments (XPlacement and XAdvance).
UI suggestion: This feature would normally be off by default.
Script/language sensitivity: Applies to any script which can use monospaced forms.
Feature interaction: This feature is mutually exclusive with all other glyph-width features (e.g. tnum, halt, hwid, palt, pwid, qwid and twid), which should be turned off when it’s applied. It deactivates the kern feature.
Tag: “half”
Friendly name: Half Forms
Registered by: Microsoft
Function: Produces the half forms of consonants in Indic scripts.
Example: In Hindi (Devanagari script), the conjunct KKa, obtained by doubling the Ka, is denoted with a half form of Ka followed by the full form.
Recommended implementation: The half table maps the sequence of a consonant followed by a virama (halant) to its half form (GSUB lookup type 4).
Application interface: For substitution sequences defined in the half table, the application passes the sequence of GIDs to the table, and gets back the GID for the half form.
UI suggestion: In recommended usage, this feature triggers substitutions that are required for correct display of the given script. It should be applied in the appropriate contexts, as determined by script-specific processing. Control of the feature should not generally be exposed to the user.
Script/language sensitivity: Required in Indic scripts that show similarity to Devanagari.
Feature interaction: This feature is used in conjunction with certain other features to derive required forms of Indic scripts. The application is expected to process this feature and certain other features in an appropriate order to obtain the correct set of basic forms: nukt, akhn, rphf, rkrf, pref, blwf, half, pstf, cjct. Other discretionary features for optional typographic effects may also be applied. Lookups for such discretionary features should be processed after lookups for this feature have been processed.
Tag: “haln”
Friendly name: Halant Forms
Registered by: Microsoft
Function: Produces the halant forms of consonants in Indic scripts.
Example: In Sanskrit (Devanagari script), syllable final consonants are frequently required in their halant form.
Recommended implementation: The haln table maps the sequence of a consonant followed by a virama (halant) to its halant form (GSUB lookup type 4).
Application interface: For substitutions defined in the halant table, the application passes the sequence of GIDs to the feature (essentially the consonant and virama), and gets back the GID for the halant form.
UI suggestion: This feature should be on by default.
Script/language sensitivity: Required in Indic scripts.
Feature interaction: This feature overrides the results of all other features.
Tag: 'halt'
Friendly name: Alternate Half Widths
Registered by: Adobe
Function: Respaces glyphs designed to be set on full-em widths, fitting them onto half-em widths. This differs from hwid in that it does not substitute new glyphs.
Example: The user may invoke this feature in a CJKV font to get better fit for punctuation or symbol glyphs without disrupting the monospaced alignment.
Recommended implementation: The font specifies alternate metrics for the full-width glyphs (GPOS lookup type 1).
Application interface: For GIDs found in the halt coverage table, the application passes the GIDs to the table and gets back positional adjustments (XPlacement, XAdvance, YPlacement and YAdvance).
UI suggestion: In general, this feature should be off by default. Different behavior should be used, however, in applications that conform to Requirements for Japanese Text Layout (JLREQ) or similar CJK text-layout specifications that expect half-width forms of characters whose default glyphs are full-width. Such implementations should turn this feature on by default, or should selectively apply this feature to particular characters that require special treatment for CJK text-layout purposes, such as brackets, punctuation, and quotation marks.
Script/language sensitivity: Used only in CJKV fonts.
Feature interaction: This feature is mutually exclusive with all other glyph-height features (e.g., 'fwid', 'hwid', 'palt', 'tnum', 'twid'), which should be turned off when this feature is applied. It deactivates the 'kern' feature. See also 'vhal'.
Tag: 'hist'
Friendly name: Historical Forms
Registered by: Microsoft/Adobe
Function: Some letterforms were in common use in the past, but appear anachronistic today. The best-known example is the long form of s; others would include the old Fraktur k. Some fonts include the historical forms as alternates, so they can be used for a ‘period’ effect. This feature replaces the default (current) forms with the historical alternates. While some ligatures are also used for historical effect, this feature deals only with single characters.
Example: The user applies this feature in Adobe Jenson to get the archaic forms of M, Q and Z.
Recommended implementation: The hist table maps default forms to corresponding historical forms (GSUB lookup type 1).
Application interface: For GIDs found in the hist coverage table, the application passes the GIDs to the hist table and gets back new GIDs.
UI suggestion: This feature should be off by default.
Script/language sensitivity: None.
Feature interaction: This feature may be used in combination with other substitution (GSUB) features, whose results it may override.
Tag: 'hkna'
Friendly name: Horizontal Kana Alternates
Registered by: Adobe
Function: Replaces standard kana with forms that have been specially designed for only horizontal writing. This is a typographic optimization for improved fit and more even color. Also see vkna.
Example: Standard full-width kana (hiragana and katakana) are replaced by forms that are designed for horizontal use.
Recommended implementation: The font includes a set of specially-designed glyphs, listed in the hkna coverage table. The hkna feature maps the standard full-width forms to the corresponding special horizontal forms (GSUB lookup type 1).
Application interface: For GIDs found in the hkna coverage table, the application passes GIDs to the feature, and gets back new GIDs.
UI suggestion: This feature would be off by default.
Script/language sensitivity: Applies only to fonts that support kana (hiragana and katakana).
Feature interaction: This feature may be used with the kern feature. Since it is for horizontal use, features applying to vertical behaviors (e.g. vkna, vert, vrt2 or vkrn) do not apply.
Tag: 'hlig'
Friendly name: Historical Ligatures
Registered by: Microsoft
Function: Some ligatures were in common use in the past, but appear anachronistic today. Some fonts include the historical forms as alternates, so they can be used for a ‘period’ effect. This feature replaces the default (current) forms with the historical alternates.
Example: The user applies this feature using Palatino Linotype, and historic ligatures are formed for all long s forms, including: long s+t, long s+b, long s+h, long s+k, and several others.
Recommended implementation: The hlig table maps default ligatures and character combinations to corresponding historical ligatures (GSUB lookup type 1).
Application interface: For GIDs found in the hlig coverage table, the application passes the GIDs to the hlig table and gets back new GIDs.
UI suggestion: This feature should be off by default.
Script/language sensitivity: None.
Feature interaction: This feature overrides the results of all other features.
Tag: 'hngl' (DEPRECATED in 2016)
Friendly name: Hangul
Registered by: Adobe
Function: Replaces hanja (Chinese-style) Korean characters with the corresponding hangul (syllabic) characters. This effectively reverses the standard input method, in which hangul are entered and replaced by hanja. Many of these substitutions are one-to-one (GSUB lookup type 1), but hanja substitution often requires the user to choose from several possible hangul characters (GSUB lookup type 3).
Example: The user may call this feature to get U+AC00 from U+4F3D.
Recommended implementation: This table associates each hanja character in the font with one or more hangul characters. The manufacturer may choose to build two tables (one for each lookup type) or only one which uses lookup type 3 for all substitutions. As in any one-from-many substitution, alternates should be ordered consistently across a family, so that those alternates can work correctly when switching between family members.
Application interface: For GIDs found in the hngl coverage table, the application passes the GIDs to the table and gets back one or more new GIDs. If more than one GID is returned, the application must provide a means for the user to select the one desired. Note: This is a change of semantic value. Besides the original character codes (when entered as hanja), the application should store the code for the new character.
UI suggestion: This feature should be inactive by default. The application may note the user’s choice when selecting from multiple hangul, and offer it as a default the next time the source hanja character is encountered. In the absence of such prior information, the application may assume that the first hangul in a set is the preferred form, so the font developer should order them accordingly.
Script/language sensitivity: Korean only.
Feature interaction: This feature is mutually exclusive with all other features, which should be turned off when it’s applied, except the palt, vert and vrt2 may be used in addition.
Friendly name: Hojo Kanji Forms (JIS X 0212-1990 Kanji Forms)
Registered by: Adobe
Function: The JIS X 0212-1990 (aka, “Hojo Kanji”) and JIS X 0213:2004 character sets overlap significantly. In some cases their prototypical glyphs differ. When building fonts that support both JIS X 0212-1990 and JIS X 0213:2004 (such as those supporting the Adobe-Japan 1-6 character collection), it is recommended that JIS X 0213:2004 forms be preferred as the encoded form. The 'hojo' feature is used to access the JIS X 0212-1990 glyphs for the cases when the JIS X 0213:2004 form is encoded.
Example: The glyph 
is replaced by the glyph 
.
Recommended implementation: One-for-one substitution of JIS X 0213:2004 glyphs by the corresponding JIS X 0212-1990 glyph.
Application interface: For GIDs found in the hojo coverage table, the application passes the GIDs to the table and gets back one new GID for each.
UI suggestion: This feature should be off by default.
Script/language sensitivity: Used only with Kanji script.
Feature interaction: This feature is exclusive with jp78, jp83, jp90, nlck and similar features. It can be combined with the palt, vpal, vert and vrt2 features.
Tag: 'hwid'
Friendly name: Half Widths
Registered by: Adobe
Function: Replaces glyphs on proportional widths, or fixed widths other than half an em, with glyphs on half-em (en) widths. Many CJKV fonts have glyphs which are set on multiple widths; this feature selects the half-em version. There are various contexts in which this is the preferred behavior, including compatibility with older desktop documents.
Example: The user may replace a proportional Latin glyph with the same character set on a half-em width.
Recommended implementation: The font may contain alternate glyphs designed to be set on half-em widths (GSUB lookup type 1), or it may specify alternate metrics for the original glyphs (GPOS lookup type 1) which adjust their spacing to fit in half-em widths.
Application interface: For GIDs found in the hwid coverage table, the application passes the GIDs to the table and gets back either new GIDs or positional adjustments (XPlacement and XAdvance).
UI suggestion: This feature would normally be off by default.
Script/language sensitivity: Generally used only in CJKV fonts.
Feature interaction: This feature is mutually exclusive with all other glyph-width features (e.g. tnum, fwid, halt, qwid and twid), which should be turned off when it’s applied. It deactivates the kern feature.
Tag: 'init'
Note: This feature description was significantly revised in 2016.
Friendly name: Initial Forms
Registered by: Microsoft/Adobe
Function: Replaces glyphs for characters that have applicable joining properties with an alternate form when occurring in an initial context. This applies to characters that have one of the following Unicode Joining_Type property values:
- Right_Joining, if the characters are from a left-to-right script.
- Left_Joining, if the characters are from a right-to-left script.
- Dual_Joining.
Unicode Joining_Type property values are obtained from the Unicode Character Database (UCD). Specifically, Joining_Type property values are documented in the UCD file, ArabicShaping.txt, the current version of which is available at http://www.unicode.org/Public/UCD/latest/ucd/ArabicShaping.txt.
Example: In an Arabic-script font, the application would apply the 'init' feature to the letter ARABIC LETTER SEEN (U+0633 “س”) when it precedes a right-joining character, thereby replacing the default “س” glyph with its left-joining, initial form.
Recommended implementation: The 'init' feature is used to map default forms to corresponding single-joining, inital forms. This will usually be implemented using a single substitution (type 1) GSUB lookup, though contextual substitution GSUB lookups (types 5, 6 or 8) may also be appropriate.
Application interface: The application is responsible for parsing character strings and identifying which of the joining-related features — initial forms ('init'), medial forms ('medi'), terminal forms ('fina'), and isolated forms ('isol') — to apply to which GIDs, based on character Joining_Type properties. Additional factors, such as the presence of control characters, may also be considered. For GIDs to which the 'init' feature is applied and that are found in the 'init' coverage table, the application passes a GID to the lookup tables associated with the feature and gets back a new GID.
UI suggestion: In recommended usage, this feature triggers substitutions that are required for correct display of the given script. It should be applied by default in the appropriate contexts, as determined by script-specific processing. Control of the feature should not generally be exposed to the user.
Script/language sensitivity: Can be used in any script with joining behavior — that is, the scripts for which Joining_Type properties are given explicitly in ArabicShaping.txt.
Feature interaction: This feature may be used in combination with other substitution (GSUB) features, whose results it may override. See also 'fina', 'isol' and 'medi'.
Tag: “isol”
Note: This feature description was significantly revised in 2016.
Friendly name: Isolated Forms
Registered by: Microsoft
Function: Replaces glyphs for characters that have applicable joining properties with an alternate form when occurring in a isolate (non-joining) context. This applies to characters that have one of the following Unicode Joining_Type property values:
- Right_Joining.
- Left_Joining.
- Dual_Joining.
- Non_Joining, if the characters are from a script with joining behavior.
Unicode Joining_Type property values are obtained from the Unicode Character Database (UCD). Specifically, Joining_Type property values are documented in the UCD file, ArabicShaping.txt, the current version of which is available at http://www.unicode.org/Public/UCD/latest/ucd/ArabicShaping.txt. Scripts that have joining behavior are those scripts with character properties given explicitly in ArabicShaping.txt.
Note that, in many fonts that support the relevant scripts, this feature may not be implemented since the default forms of the relevant characters are the isolated forms. In some fonts, this feature may involve contextual substitution based on the specific, isolated context.
Example: In an Arabic-script font, the application would apply the 'isol' feature to the letter ARABIC LETTER HEH (U+0647 “ه”) when not adjacent to any joining character, thereby potentially replacing the default “ه” glyph with a special, isolated form (likely, a contextual and language-specific substitution, substituting one isolated form for another).
Recommended implementation: The 'isol' feature is used to map default forms to alternate non-joining, isolate forms. This will usually be implemented using a single substitution (type 1) GSUB lookup or, often, a contextual substitution GSUB lookup (types 5, 6 or 8).
Application interface: The application is responsible for parsing character strings and identifying which of the joining-related features — initial forms ('init'), medial forms ('medi'), terminal forms ('fina'), and isolated forms ('isol') — to apply to which GIDs, based on character Joining_Type properties. Additional factors, such as the presence of control characters, may also be considered. For GIDs to which the 'isol' feature is applied and that are found in the 'isol' coverage table, the application passes a GID to the lookup tables associated with the feature and gets back a new GID.
UI suggestion: In recommended usage, this feature triggers substitutions that are required for correct display of the given script. It should be applied by default in the appropriate contexts, as determined by script-specific processing. Control of the feature should not generally be exposed to the user.
Script/language sensitivity: Can be used in any script with joining behavior — that is, the scripts for which Joining_Type properties are given explicitly in ArabicShaping.txt.
Feature interaction: This feature may be used in combination with other substitution (GSUB) features, whose results it may override. See also fina, 'init' and 'medi'.
Tag: 'ital'
Friendly name: Italics
Registered by: Adobe
Function: Some fonts (such as Adobe’s Pro Japanese fonts) will have both Roman and Italic forms of some characters in a single font. This feature replaces the Roman glyphs with the corresponding Italic glyphs.
Example: The user would apply this feature to replace B with B.
Recommended implementation: The ital table maps the Roman forms in a font to the corresponding Italic forms (GSUB lookup type 1).
Application interface: For GIDs found in the ital coverage table, the application passes the GIDs to the table and gets back one new GID for each.
UI suggestion: When a user selects text and applies an Italic style, an application should check for this feature and use it if present.
Script/language sensitivity: Applies mostly to Latin; note that many non-Latin fonts contain Latin as well.
Feature interaction: This feature may be used in combination with other substitution (GSUB) features, whose results it may override. In CJKV fonts it should activate the kern feature (which would be on anyway in other scripts).
Tag: “jalt”
Friendly name: Justification Alternates
Registered by: Microsoft
Function: Improves justification of text by replacing glyphs with alternate forms specifically designed for this purpose (they would have less or more advance width as need may be).
Example: In the Arabic script, providing alternate forms for line final glyphs would result in better justification and reduce the use of tatweels (Kashidas). eg. replacing a Swash Kaf with an alternate form.
Recommended implementation: The jalt table maps the initial, medial, final or isolated forms to their corresponding alternate forms (GSUB lookup type 3).
Application interface: The application is responsible for noting line ends/boundaries. For GIDs found in the jalt coverage table, the application passes a GID to the feature and gets back a new GID.
UI suggestion: This feature could be made active or inactive by default, at the user’s preference.
Script/language sensitivity: Can be used in any cursive script.
Feature interaction: If the font contains init, medi, fina, isol features, these need to be called prior to calling this feature.
Tag: 'jp78'
Friendly name: JIS78 Forms
Registered by: Adobe
Function: This feature replaces default (JIS90) Japanese glyphs with the corresponding forms from the JIS C 6226-1978 (JIS78) specification.
Example: The user would invoke this feature to replace kanji character U+5516 with U+555E.
Recommended implementation: When JIS90 glyphs correspond to JIS78 forms, the jp78 table maps each of those glyphs to their alternates. While many of these substitutions are one-to-one (GSUB lookup type 1), others require a selection from a set (GSUB lookup type 3). The manufacturer may choose to build two tables (one for each lookup type) or only one which uses lookup type 3 for all substitutions.
Application interface: For GIDs found in the jp78 coverage table, the application passes the GIDs to the table and gets back one or more new GIDs. If more than one GID is returned, the application must provide a means for the user to select the one desired. The application may assume that the first glyph in a set is the preferred form, so the font developer should order them accordingly. Note: This is a change of character code. Besides the original character code, the application should store the code for the new character.
UI suggestion: This feature should be off by default.
Script/language sensitivity: Applies only to Japanese.
Feature interaction: This feature is mutually exclusive with all other features, which should be turned off when it’s applied, except the palt, vpal, vert and vrt2 features, which may be used in addition.
Tag: 'jp83'
Friendly name: JIS83 Forms
Registered by: Adobe
Function: This feature replaces default (JIS90) Japanese glyphs with the corresponding forms from the JIS X 0208-1983 (JIS83) specification.
Example: Because of the Han unification in Unicode, there are no JIS83 glyphs which have distinct Unicode values, so the substitution cannot be described specifically.
Recommended implementation: When JIS90 glyphs correspond to JIS83 forms, the jp83 table maps each of those glyphs to their alternates (GSUB lookup type 1).
Application interface: For GIDs found in the jp83 coverage table, the application passes the GIDs to the table and gets back one or more new GIDs. If more than one GID is returned, the application must provide a means for the user to select the one desired.
UI suggestion: This feature should be off by default.
Script/language sensitivity: Applies only to Japanese.
Feature interaction: This feature is mutually exclusive with all other features, which should be turned off when it’s applied, except the palt, vpal, vert and vrt2 features, which may be used in addition.
Tag: 'jp90'
Friendly name: JIS90 Forms
Registered by: Adobe
Function: This feature replaces Japanese glyphs from the JIS78 or JIS83 specifications with the corresponding forms from the JIS X 0208-1990 (JIS90) specification.
Example: The user would invoke this feature to replace kanji character U+555E with U+5516.
Recommended implementation: The jp90 table maps each JIS78 and JIS83 form in a font to JIS90 forms (GSUB lookup type 1). The application stores a record of any simplified forms which resulted from substitutions (the jp78 or jp83 features); for such forms, applying the jp90 feature undoes the previous substitution. When there is no record of a substitution, the application uses the jp90 table to get back to the default form.
Application interface: For GIDs found in the jp90 coverage table, the application passes the GIDs to the table and gets back one new GID for each. Note: This is a change of character code. Besides the original character code, the application should store the code for the new character.
UI suggestion: This feature should be off by default.
Script/language sensitivity: Applies only to Japanese.
Feature interaction: This feature is mutually exclusive with all other features, which should be turned off when it’s applied, except the palt, vpal, vert and vrt2 features, which may be used in addition.
Tag: 'jp04'
Friendly name: JIS2004 Forms
Registered by: Adobe
Function: The National Language Council (NLC) of Japan has defined new glyph shapes for a number of JIS characters, which were incorporated into JIS X 0213:2004 as new prototypical forms. The 'jp04' feature is a subset of the 'nlck' feature, and is used to access these prototypical glyphs in a manner that maintains the integrity of JIS X 0213:2004.
Example: The glyph 
is replaced by the glyph 
.
Recommended implementation: One-for-one substitution of non-JIS X 0213:2004 glyphs by the corresponding JIS X 0213:2004 glyph.
Application interface: For GIDs found in the jp04 coverage table, the application passes the GIDs to the table and gets back one new GID for each.
UI suggestion: This feature should be off by default.
Script/language sensitivity: Used only with Kanji script.
Feature interaction: This feature is exclusive with jp78, jp83, jp90, nlck and similar features. It can be combined with the palt, vpal, vert and vrt2 features.
OpenType specification