John Hudson wrote: > It might be a good idea if someone explained to us font designers > exactly what is required of us. Some mirrored forms such as the > parentheses, are being handled in character processing, not glyph > processing, and I have yet to see any set of requirements (e.g. in > Microsoft's Arabic or Hebrew OpenType font specs) for font layout > features to address any additional mirror glyph behavior.
I am actually working on such a layout feature for OpenType (see at the end of this message for a complete description). I believe that the current mirrored and mirrored glyph properties are useful only when no help can be obtained from the font; otherwise, the resolved directionality should be provided to the font, which should then select the appropriate shape for each and every character, regardless of the mirrored and mirrored glyph properties. Mirrored glyph encourages application developers to insert a step in the rendering process, at the character level, to replace occurrences of U+0028 in rtl contexts by U+0029 (and similarly for the others). The first problem is that the font is not given any clue that this happened; in other words, the font designer does not have the opportunity to treat U+0028 in a rtl context and U+0029 in a ltr context differently; in some designs that have non symmetric shapes, this could be nice. Second, this machinery fails entirely for characters that do not have a mirrored glyph (such as square root). Mirrored glyph is fundamentally something that belongs to the font, not to the character. Mirrored is also problematic. It's only use is to trigger the selection of an alternate glyph, so it is really speaking about glyphs. We admit that the selection of a small cap or uncase or petite cap or regular or swash form is not part of the character stream; what makes the selection of a shape appropriate for rtl or ltr context any different? in particular, why should we rule out the use of an alternate shape for A based on the directionality? One possible objection to my assertions is that the font could trigger the shape changes based on the script/language of the text, and therefore not need the directionality. However, that amounts to saying that we do not need directionality overrides, so it cannot be right. Comments welcome, Eric. Tag: 'rtla' Friendly name: Right-to-left alternates Function: A number of Unicode characters are rendered by different shapes depending on the directional context in which they appear. For example, the character U+0028 LEFT PARENTHESIS is interpreted by the Unicode standard as an opening parenthesis and it appears as “(” in left-to-right contexts, and as “)” in right-to-left contexts (this is described on page 66 of the Unicode Standard, version 3.0). The 'rtla' feature is used access the shape appropriate for a right-to-left context. Example: The 'rtla' feature replaces the glyph “(” by the glyph “)”. Recommended implementation: substitution feature. Since this feature is a glyph selection feature, it should probably be performed early in the shaping process. At least all the glyphs mapped from characters with the mirrored property should have a replacement. Application interface: the layout application applies the Unicode bidi algorithm to the character string to display, and maps the resulting character string to glyphs via the cmap. It activates the 'rtla' feature on glyphs that correspond to characters with an odd resolved level. It is important to note that all such glyphs should have the 'rtla' feature, not just those that correspond to characters with mirrored property. The motivation is that the font designer may want additional characters to assume different shapes (e.g. U+201C LEFT DOUBLE QUOTATION MARK). UI suggestion: none. Script/language sensitivity: none. Feature interaction: This feature may be used in combination with other features.
