[mpeg-OTspec] RE: DAM2 comments

[Ken Lunde]

Peter,

Thank you. As the person who submitted the previous text, I agree that yours is better.

Note that the 'halt' feature description will need the same change to its "UI suggestion" field.

Best...

-- Ken

> On Sep 3, 2016, at 7:04 PM, Peter Constable petercon at microsoft.com [mpeg-OTspec] <mpeg-OTspec-noreply at yahoogroups.com> wrote:
> 
> 
> Addendum: I hadn’t noticed that there were changes to the UI suggestion field of the ‘vhal’ feature description. The text proposed in the DAM2 ballot doc has a long, run-on sentence. I suggest it be revised as follows:
> 
>  
> 
> 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 [21]) 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.
> 
>  
> 
>  
> 
> Peter
> 
>  
> 
> From: Peter Constable 
> Sent: Saturday, September 3, 2016 5:13 PM
> To: Peter Constable <petercon at microsoft.com>; mpeg-OTspec at yahoogroups.com
> Subject: RE: DAM2 comments
> 
>  
> 
> Wow! Some mail server along the way (I’m guessing Yahoo!) badly munged the formatting in the HTML mail I sent.
> 
>  
> 
> From: mpeg-OTspec at yahoogroups.com[mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of Peter Constable petercon at microsoft.com [mpeg-OTspec]
> Sent: Saturday, September 3, 2016 5:06 PM
> To: mpeg-OTspec at yahoogroups.com
> Subject: [mpeg-OTspec] DAM2 comments
> 
>   
> 
> I’m reviewing the DAM2 ballot document, and note the following substantive (major editorial or technical) issues:
> 
> 1) The ‘fina’ feature description:
> 
> First, I find the value in the Function field to be very difficult to comprehend:
> 
> “Function: Unicode joining-script shaping [20] for single-joining final (‘R Right_Joining’ in right-to-left scripts; ‘L Left_Joining’ in left-to-right scripts) or dual-joining characters in final situation.”
> 
> Even for someone well-versed in Unicode, this is difficult to read, and it doesn’t actually state what the feature is supposed to do.
> 
> Secondly, there is a technical flaw in referring to “right-to-left scripts” and “left-to-right” scripts: nowhere will you find script property values for directionality. This is a little trickier to resolve: I think what is really intended here is one of the following (in the case of Right_Joining), thought it’s not clear which, or if it’s intentionally ambiguous:
> 
> “Right_Joining, if the characters have strong right-to-left Bidi_Class property value.”
> 
> Or,
> 
> “Right_Joining, if the resolved bidi level of the characters is odd.
> 
> I’ll leave that as an open issue for now.
> 
> Thirdly, the application interface field has a value that begins,
> 
>             “The application is responsible for parsing character strings and identifying which orthographic shaping form feature to apply…”
> 
> While I don’t have any objection to the goal of categorizing features, “orthographic shaping form feature” sounds like a technical term yet it is nowhere defined. Rather than get into whether to introduce feature meta-properties at this time, I think the field content can be reworded to get at the same point without any terminological issue.
> 
> Fourth, the Script/language sensitivity field has this:
> 
> “Can be used in any script with joining properties specified in the Unicode standard for joining-script shaping [20].”
> 
> The problem with that is that every Unicode character has a Joining_Type property. The scripts of interest are those with characters that are right-, left- or dual-joining; this can also be characterized as scripts for which Joining_Type properties are givenexplicitly in ArabicShaping.txt.
> 
> Between the above and other editorial issues, I would revise the feature description to the following (the external, normative reference to UCD will need to be revised for OFF):
> 
> 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 theUnicode Character Database (UCD). Specifically, Joining_Type property values are documented in the UCD file, ArabicShapint.txt, the current version of which is available athttp://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 associate 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'.
>  
> 
> 2) ‘init’ feature description
> 
> Similar comments to the above. I’d revise as follows:
> 
>  
> 
> 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 theUnicode Character Database (UCD). Specifically, Joining_Type property values are documented in the UCD file, ArabicShapint.txt, the current version of which is available athttp://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, iniital 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 associate with the feature and gets back a new GID. 
> UI suggestion: This feature should be active by default. 
> 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'.
>  
> 
> 3) ‘isol’ feature description
> 
> Similar comments to the above. I’d revise as follows:
> 
>  
> 
> 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 theUnicode Character Database (UCD). Specifically, Joining_Type property values are documented in the UCD file, ArabicShaping.txt, the current version of which is available athttp://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 'init' 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 'fina' 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'.
>  
> 
> 4) ‘medi’ feature description
> 
> Similar comments to the above. I’d revise as follows:
> 
>  
> 
> Tag: 'medi'
> Note: This feature description was significantly revised in 2016.
> Friendly name: Medial Forms
> Registered by: Microsoft/Adobe
> Function: Replaces glyphs for characters that have applicable joining properties with an alternate form when occurring in a medial context. This applies to characters that have the Unicode Joining_Type property value 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 'medi' feature to the letter ARABIC LETTER QAF (U+0642 “ق”) when it follows a left-joining character and precedes a right-joining character, thereby replacing the default “ق” glyph with its dual-joining, medial 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 'medi' feature is applied and that are found in the 'medi' 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 'isol'.
>  
> 
>  
> 
>  
> 
> I’ve reviewed other portions of DAM2 other than changes to the ‘SVG’ table (which I’m leaving to Sairus and my co-workers Rick Manning and Miles Cohen to review), and I have no further comments at this time.
> 
>  
> 
> Peter
> 
> 
> 
>