features are not functions (wording for appl'n implementation)

Many feature descriptions use wording in the Application implementation portion as though a feature table were a function. E.g.,

the application passes this value to the feature table and gets back the GIDs

This might have made sense if some standard library API were being referred to, but that's not the case.
Feature and lookup tables are data, not functions.
(This was pointed out by Simon Cozens in discussion for #557.)

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 4da11419-0864-96ff-7f67-296680843fc1
Version Independent ID: 1d46dac1-d559-ce3e-2f6f-f47cf8cd9e0f
Content: Registered features, a-e - Typography
Content Source: typographydocs/opentype/spec/features_ae.md
Product: typography
GitHub Login: @PeterCon
Microsoft Alias: PeterCon

I've tried drafting changes for feature descriptions in features_uz:
'unic':

Application interface: For GIDs found in the 'unic' coverage table, the application passes GIDs to the 'unic' table, and gets back new GIDsFor glyph IDs in the subtable coverage of an associated lookup table, the application retrieves a substitute glyph ID from the subtable.

'valt':

Application interface: For GIDs found in the 'valt' coverage table, the application passes the GIDs to the table and gets back positional adjustments (YPlacement)For glyph IDs in the subtable coverage of an associated lookup table, the application retrieves positioning adjustment values from the subtable.

'vatu':

Application interface: For substitutions defined in the 'vatu' table, the application passes the sequence of GIDs to the table, and gets back the GID for the vattu variant ligatureFor glyph IDs in the subtable coverage of an associated lookup table, the application tests for a matching sequence, and retrieves a subtitute glyph ID from the subtable.

'vchw':

Application interface: For glyph IDs in the subtable coverage of an associated lookup table, the application tests for a matching glyph sequence, and retrieves positioning adjustment values from the subtable.

'vert':

Application interface: For GIDs found in the 'vert' coverage table, the application passes GIDs to the lookup tables associated with the feature, then gets back new GIDs.For glyph IDs in the subtable coverage of an associated lookup table, the application retrieves a substitute glyph ID from the subtable.

'vhal':

Application interface: For GIDs found in the 'vhal' coverage table, the application passes the GIDs to the table and gets back positional adjustments (XPlacement, XAdvance, YPlacement and YAdvance)For glyph IDs in the subtable coverage of an associated lookup table, the application retrieves positioning adjustment values from the subtable.

'vjmo':

Application interface: For substitutions defined in the 'vjmo' table, the application passes the sequence of GIDs to the feature, and gets back the GID for the vowel jamo formFor glyph IDs in the subtable coverage of an associated lookup table, the application tests for a matching sequence and retrieves a substitute glyph ID from the subtable.

'vkna':

Application interface: For GIDs found in the 'vkna' coverage table, the application passes GIDs to the feature, and gets back new GIDsFor glyph IDs in the subtable coverage of an associated lookup table, the application tests for a matching sequence and retrieves a substitute glyph ID from the subtable.

'vkrn':

Application interface: The application passes a sequence of GIDs to the 'vkrn' table, and gets back adjusted positions (XPlacement, XAdvance, YPlacement and YAdvance) for those GIDs. When using the type 2 lookup on a run of glyphs, it’s critical to remember to not consume the last glyph, but to keep it available as the first glyph in a subsequent run (this is a departure from normal lookup behavior).For glyph IDs in the subtable coverage of an associated lookup table, the application tests for a matching glyph sequence, and retrieves positioning adjustment values from the subtable.

'vpal':

Application interface: For GIDs found in the 'vpal' coverage table, the application passes the GIDs to the table and gets back positional adjustments (XPlacement, XAdvance, YPlacement and YAdvance)For glyph IDs in the subtable coverage of an associated lookup table, the application retrieves positioning adjustment values from the subtable.

'vrt2':

Application interface: For GIDs found in the 'vrt2' coverage table, the application passes GIDs to the feature, and gets back new GIDsFor glyph IDs in the subtable coverage of an associated lookup table, the application tests for a matching sequence and retrieves a substitute glyph ID from the subtable.

'vrtr':

Application interface: For GIDs found in the 'vrtr' coverage table, the application passes GIDs to the lookup tables associated with the feature, then gets back new GIDsFor glyph IDs in the subtable coverage of an associated lookup table, the application tests for a matching sequence and retrieves a substitute glyph ID from the subtable.

'zero':

Application interface: For GIDs in the 'zero' coverage table, the application passes a GID to the 'zero' table and gets back a new GIDFor glyph IDs in the subtable coverage of an associated lookup table, the application tests for a matching sequence and retrieves a substitute glyph ID from the subtable.

Now for a comment on the above drafts: The revisions are restating what had been there but in ways that are more coherent given what Feature and Lookup tables actually are.
But I don't find having these "application interface" descriptions satisfying or really useful: they basically repeat what is covered in the OTL Common Formats / GSUB / GPOS chapters, just being more specific in each case in describing the particular GPOS or GSUB lookup processing.
If that's all that these "application interface" descriptions are, then it might be better simply to delete them entirely.
Are there any other kinds of information that might need to be called out for any feature as application interface details?

My inclination would be to have general processing guidance for GSUB and GPOS outside of the individual feature descriptions, but retain the application interface section (but maybe under another name?) in the feature descriptions to accommodate special processing guidance when needed. So this section would either say 'Refer to general feature processing...' or would say 'In addition to general feature processing, this feature also requires...'.
[One of the things we've talked about making standard info in the feature descriptions is recommended default state—on and cannot be turned off, on and can be turned off, or off and can be turned on—: this is a kind of application-feature interface, but would benefit from a new field in each feature description. Is this something that could be in scope for the current work? I took a run at the values in the State column of the tables in this document.]

I since found cases in which the AI field wasn't just repeating generic GPOS/GSUB info. So, agree that that should stay, but the rest could go; and I don't see a need even to repeat for each feature, "See..."
Wrt "default state", see also #290. I'm not keen on doing a major restructuring of all entries in the feature registry for a dot-dot version. But for now I think your 1/0, 0/1, 1/1 details could be captured in the current UI Suggestion field. You could open a separate issue for that, and I could try to do that in 184. If you could provide the 1/0 etc details in a spreadsheet or CSV file that would help.

Still in process on this. Here's a draft change to go into the Feature tags page:

The feature descriptions provided include details regarding lookup types that can be used to implement each feature. Some feature descriptions may include feature-specific details regarding how text-layout software is expected to interact with the feature. General details on processing of lookup tables is provided in the 'GPOS', 'GSUB' and OpenType Layout Common Table Formats chapters. Lookup information is provided for reference purposes onlyInformation on lookups and lookup types is provided only as recommendations or suggestions; the set of lookups used to implement a feature willmay vary across platforms, applications, fonts, and font developers.

Considering this wording for the application interface for discretionary features:

Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria..

Here's a second draft of revision to feature desciptions in features_uz:
unic:

Application interface: For GIDs found in the 'unic' coverage table, the application passes GIDs to the 'unic' table, and gets back new GIDs.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.

valt:

Application interface: For GIDs found in the 'valt' coverage table, the application passes the GIDs to the table and gets back positional adjustments (YPlacement).Should be applied to runs of characters for applicable scripts in vertical text layout.

vatu:

Application interface: For substitutions defined in the 'vatu' table, the application passes the sequence of GIDs to the table, and gets back the GID for the vattu variant ligature.In recommended usage, this feature triggers substitutions required for correct layout of certain scripts. It should be applied in the appropriate contexts, as determined by script-specific processing.
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.

vchw:
(This is part of a new feature description.)

Application interface: Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.

vert:

Application interface: For GIDs found in the 'vert' coverage table, the application passes GIDs to the lookup tables associated with the feature, then gets back new GIDs.Should be applied to runs of characters for applicable scripts in vertical text layout.

vhal:

Application interface: For GIDs found in the 'vhal' coverage table, the application passes the GIDs to the table and gets back positional adjustments (XPlacement, XAdvance, YPlacement and YAdvance).Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.

vjmo:

Application interface: For substitutions defined in the 'vjmo' table, the application passes the sequence of GIDs to the feature, and gets back the GID for the vowel jamo form.In recommended usage, this feature triggers substitutions required for correct layout of certain scripts. It should be applied in the appropriate contexts, as determined by script-specific processing.
UI suggestion: This feature should be on by default.Control of the feature should not generally be exposed to the user.

vkna:

Application interface: For GIDs found in the 'vkna' coverage table, the application passes GIDs to the feature, and gets back new GIDs.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.

vkrn:

Application interface: The application passes a sequence of GIDs to the 'vkrn' table, and gets back adjusted positions (XPlacement, XAdvance, YPlacement and YAdvance) for those GIDs. When using the type 2 lookup on a run of glyphs, it’s critical to remember to not consume the last glyph, but to keep it available as the first glyph in a subsequent run (this is a departure from normal lookup behavior).Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.

vpal:

Application interface: For GIDs found in the 'vpal' coverage table, the application passes the GIDs to the table and gets back positional adjustments (XPlacement, XAdvance, YPlacement and YAdvance).Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.

vrt2:
(Choose this AI description based on the existing UI recommendation, quoted here.)

Application interface: For GIDs found in the 'vrt2' coverage table, the application passes GIDs to the feature, and gets back new GIDs.Discretionary feature: can be applied to glyph runs in vertical text layout based on document markup, user control or other application criteria.
UI suggestion: This feature should be active by default when vertical writing mode is on, although the user must be able to override it.

vrtr:
(Other details in this feature description aren't entirely clear to me, so this is a best attempt based on what I understand.)

Application interface: For GIDs found in the 'vrtr' coverage table, the application passes GIDs to the lookup tables associated with the feature, then gets back new GIDs.Should be applied to applicable characters in vertical text layout.

zero:

Application interface: For GIDs in the 'zero' coverage table, the application passes a GID to the 'zero' table and gets back a new GID.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.

In the old form, the “application interface” had information on whether the feature was a GSUB feature (“ the application passes the sequence of GIDs to the table, and gets back the GID” or such) or a GPOS feature (“ the application passes the GIDs to the table and gets back positional adjustments” or such). The new form omits that information. Is that intentional? I know there’s some disagreement on whether features should be segregated into GSUB and GPOS features, or whether every feature should be usable in either table.

Since that is typically included in the "recommended implementation" sections, I didn't think it needed to be repeated here. But in cases of non-discretionary features that are specifically intended for GSUB or for GPOS, it might still useful to include. I'll revisit 'unic' – 'zero' with that in mind.

How does this seem (two representative examples)?
unic:

Application interface: For GIDs found in the 'unic' coverage table, the application passes GIDs to the 'unic' table, and gets back new GIDs.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. When used, 'GSUB' processing is required.

valt:

Application interface: For GIDs found in the 'valt' coverage table, the application passes the GIDs to the table and gets back positional adjustments (YPlacement).Should be applied to runs of characters for applicable scripts in vertical text layout. When used, 'GPOS' processing is required.

And one more representative sample:
vatu:

Application interface: For substitutions defined in the 'vatu' table, the application passes the sequence of GIDs to the table, and gets back the GID for the vattu variant ligature.In recommended usage, this feature triggers substitutions required for correct layout of certain scripts. It should be applied in the appropriate contexts, as determined by script-specific processing.  When used, 'GSUB' processing is required; not used for 'GPOS' processing.

A “recommended implementation” means nothing specification-wise – anybody is free to choose an implementation that’s not recommended.
The proposed wording for unic leaves it open what happens when the feature is used in the GPOS table, and the wording for valt is silent on use in the GSUB table.
I’d expect a specification to be clear about that – either there needs to be a clear statement that any feature can be used in either table, or each feature needs to be described as a GSUB feature or a GPOS feature, and there needs to be a clear statement that features found in the wrong table will be ignored.

Well, you're describing what might be ideal. I think it will take long discussion to get broad consensus either than all features can be used in either table or to nail down for every feature in which tables it may be used. That's outside the scope of a 1.8.4 update.
In the meantime, I've attempted to reflect what was already being stated in a more useful way. I don't see how what I've proposed is substantively different from what was there, but if there's strong objection to it then I won't add the "GSUB processing required" etc. bits.
Please provide feedback for what you think would be reasonable and feasible for a 1.8.4 update.

I’d expect a specification to be clear about that – either there needs to be a clear statement that any feature can be used in either table, or each feature needs to be described as a GSUB feature or a GPOS feature, and there needs to be a clear statement that features found in the wrong table will be ignored.

For a lot of features, either GSUB or GPOS implementation is going to be the obvious, rational way to implement them. I mean, I can easily conceive of a way to implement aspects of typically GSUB features using GPOS, but it introduces multiple difficulties that are avoided in simpler GSUB implementations. However, I would much rather leave that to the font maker to decide, and think that the spec should explicitly permit any feature to use GSUB, GPOS, or a combination of both.
[There are only couple of existing features that are specifically GSUB and GPOS ways to implement the same kind of textual functionality: mset and mark, respectively, and the former is explicitly a backwards compatibility implementation. Font makers will need to know how and when to use such features, but that shouldn't affect the general approach of allowing features to have associated lookups of any GSUB or GPOS type.]
I agree with Peter that this is something that needs broad consensus—hopefully soon—, but my inclination for now is not to include statements of table implementation in the feature descriptions. I'd rather not encourage restricted implementations while we're considering removing such restrictions.

@tiroj What do you think of the draft in my longer comment from a couple of hours ago, which doesn't mention GSUB or GPOS in the AI sections?
(Norbert had mentioned that the existing descriptions, in repeating GSUB/GPOS details, were giving an indication that GSUB or GPOS processing was expected.)

The draft approach is, I think, a good interim step, while we decide how table implementation should be spec'd.

It's a recommendation for font makers, such that if, for example, they implement TRK langsys substitutions for smallcaps, they should also remember to do this for petite caps.

But the description for 'smcp' puts details in the Application interface section.

Application interface: For GIDs found in the 'smcp' coverage table, the application passes GIDs to the 'smcp' table, and gets back new GIDs. Note that applications should treat ß (U+00DF) as a pair of s characters, and that the Turkish dotless i maps to the normal small cap I.

That makes it sound like the application is supposed to handle special casing (in some way?).
I guess it's a separate issue that I'll side-step.

Based on the discussion in #610 so far, it seems we have to assume for now that there are separate sets of GSUB features and GPOS features.
I’d simply use the terms “GSUB feature” or “GPOS feature” somewhere in the “application interface” section, e.g., “Discretionary GSUB feature” or “This GPOS feature...”, without discussing processing. Then add a section to the “Feature tags” page:

Features are described as either a “GSUB feature” or a “GPOS feature”. Implementations must process GSUB features as described if they’re used in the GSUB table, and GPOS features as described if they’re used in the GPOS table. Whether GSUB features used in the GPOS table, and GPOS features used in the GSUB table, are applied is currently implementation dependent.

Those comments about ß and Turkish dotless i should be removed from the smcp feature. Not only are they in the wrong part of the description, they're hopelessly limited in scope. At the time the feature was first registered, these were about the limit of understanding of Latin-script font makers, including Adobe, of what might be needed in terms of supporting language specific behaviour. Things are better now and, ironically, those two examples are typically driven by mechanisms outside the smcp lookups.

If features are going to be categorised as GSUB or GPOS, then I would like to see that become a standard data field in each feature description, rather than putting it in the Application Interface section. This categorisation isn't particular to application interface.
In general, when we have a data point that needs to be specified for each feature, i.e. also for default state, this should be a separate data field in the description and of a standard format, such that it could be easily parsed.

Those comments about ß and Turkish dotless i should be removed from the smcp feature.

Can you open a separate issue for that? (I don't want to change that as part of changes for this issue.)

I suggested mention of "GSUB" or "GPOS" in the application interface fields, but got feedback against that. And, as noted, when there's implicit mention of those tables in current text there is also explicit mention in the recommended implementation fields. So, I'm not adding this into the AI fields at this time.

Draft revisions for features 'palt' to 'twid' (features_pt):
palt:

Application interface: For GIDs found in the 'palt' coverage table, the application passes the GIDs to the table and gets back positional adjustments (XPlacement, XAdvance, YPlacement and YAdvance).Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.

pcap:

Application interface: For GIDs found in the 'pcap' coverage table, the application passes GIDs to the 'pcap' table, and gets back new GIDs.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. Petite cap substitutions should follow language rules for smallcap ('smcp') substitutions.

pkna:

Application interface: For GIDs found in the 'pkna' coverage table, the application passes the GIDs to the table and gets back new GIDs.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.

pnum:

Application interface: For GIDs found in the 'pnum' coverage table, the application passes GIDs to the 'pnum' table and gets back new GIDs.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.

pref:

Application interface: For substitutions defined in the 'pref' table, the application passes the sequence of GIDs to the table, and gets back the GID for the pre base form of the consonant. When shaping scripts of south India, the application may examine the results of processing this feature to determine if the conjoining consonant form needs to be re-ordered.In recommended usage, this feature triggers substitutions required for correct layout of certain scripts. It should be applied in the appropriate contexts, as determined by script-specific processing requirements. The effect of lookups associated with this feature may be used by the application to control subsequent reordering of conjoined consonant glyphs, as determined by script-specific processing requirements.
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.

pres:

Application interface: For substitutions defined in the 'pres' table, the application passes the sequence of GIDs to the feature, and gets back the GID for the ligature (or matra as the case may be).In recommended usage, this feature triggers substitutions required for correct display of certain scripts. It should be applied in the appropriate contexts, as determined by script-specific processing requirements.
UI suggestion: This feature should be on by default.Control of the feature should not generally be exposed to the user.

pstf:

Application interface: For substitutions defined in the 'pstf' table, the application passes the sequence of GIDs to the feature, and gets back the GID for the post base form of the consonant.In recommended usage, this feature triggers substitutions required for correct display of certain scripts. It should be applied in the appropriate contexts, as determined by script-specific processing requirements.
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.

psts:

Application interface: For substitutions defined in the 'psts' table, the application passes the sequence of GIDs to the feature, and gets back the GID for the ligature.In recommended usage, this feature triggers substitutions required for correct display of certain scripts. It should be applied in the appropriate contexts, as determined by script-specific processing requirements.
UI suggestion: This feature should be on by default.Control of the feature should not generally be exposed to the user.

pwid:

Application interface: For GIDs found in the 'pwid' coverage table, the application passes the GIDs to the table and gets back new GIDs.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.

qwid:

Application interface: For GIDs found in the 'qwid' coverage table, the application passes the GIDs to the table and gets back either new GIDs or positional adjustments (XPlacement and XAdvance).Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.

rand:

Application interface: For GIDs found in the rand coverage table, the application passes a GID to the rand table and gets back one or more new GIDs.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. The feature is designed to be used with an alternate substitution lookup that provides a selection of alternate glyphs for a given character. The application selects one of these either by a pseudo-random algorithm, or by noting the sequence of IDs returned, storing that sequence, and stepping through that set as the corresponding character code is invoked.

rclt:

Application interface: The application passes sequences of GIDs to the feature table, and gets back new GIDs. Note that full sequences must be passed.In recommended usage, this feature triggers substitutions required for correct display of certain scripts. It should be applied in the appropriate contexts, as determined by script-specific processing requirements. When processing lookups, context before or after the glyph sequence to which the feature is applied must be considered.
UI suggestion: This feature should be active by default. It is recommended that this feature not be turned off, to avoid breaking obligatory shaping.Control of this feature should not generally be exposed to the user.

rkrf:

Application interface: For substitution sequences defined in the 'rkrf' table, the application passes the sequence of GIDs to the table, and gets back the GID for the half form.In recommended usage, this feature triggers substitutions required for correct display of certain scripts. It should be applied in the appropriate contexts, as determined by script-specific processing requirements.
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.

rlig:

Application interface: The 'rlig' table maps sequences of glyphs to corresponding ligatures (GSUB lookup type 4). Ligatures with more components must be stored ahead of those with fewer components in order to be found. The set of standard ligatures will normally remain constant by script.In recommended usage, this feature triggers substitutions required for correct display of certain scripts. It should be applied in the appropriate contexts, as determined by script-specific processing requirements.
UI suggestion: This feature should be active by default. It is recommended that this feature not be turned off to avoid breaking obligatory script shaping.Control of this feature should not generally be exposed to the user.

rphf:

Application interface: The application passes the GIDs for Ra and virama to the table and gets back the GID for the reph mark. The application may examine the results of processing other features to determine where in the sequence the reph mark should be re-ordered to.In recommended usage, this feature triggers substitutions required for correct display of certain scripts. It should be applied in the appropriate contexts, as determined by script-specific processing requirements.
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.

rtbd:

Application interface: For GIDs found in the 'rtbd' coverage table, the application passes a GID to the table and gets back a new XPlacement and XAdvance value.In recommended usage, the application applies this feature to characters at the right end of a horizontal line when the 'opbd' has been applied to those characters.
UI suggestion: This feature is called by an application when the user invokes the 'opbd' feature.In recommended usage, this is applied to sequences automatically by applications when the 'opbd' feature is used, and direct user control is not required.

rtla:

UI suggestion: None.Control of this feature should not generally be exposed to the user.

rtlm:

UI suggestion: None.Control of this feature should not generally be exposed to the user.

ruby:

Application interface: For GIDs found in the 'ruby' coverage table, the application passes the GIDs for default forms to the table and gets back new GIDs for ruby forms. The application then scales and positions these forms according to its defaults, which may take user parameters.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. After associated lookups are applied, applications may re-size or scale glyphs or perform other positioning or layout adjustments based on other parameters.

salt:

Application interface: For GIDs found in the 'salt' coverage table, the application passes the GIDs to the 'salt' 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.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. If implemented in a font using an alternate substitution lookup, the application selects one of the alternative glyphs based on user choice or other criteria.

sinf:

Application interface: For GIDs found in the 'sinf' coverage table, the application passes a GID to the feature and gets back a new GID.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.

smcp:
(Doesn't incorporate change for #616.)

Application interface: For GIDs found in the 'smcp' coverage table, the application passes GIDs to the 'smcp' table, and gets back new GIDs.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. Note that applications should treat ß (U+00DF) as a pair of s characters, and that the Turkish dotless i maps to the normal small cap I.

smpl:

Application interface: For GIDs found in the 'smpl' coverage table, the application passes the GIDs to the table and gets back one new GID for each.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. Note: This is a change of character code. Besides the original character code, the application should store the code for the new character.

ssXX:

Application interface: Note that the application is responsible for counting and enumerating the number of features in the font with tag names of the format 'ss01' to 'ss20', and for presenting the user with an appropriate selection mechanism. For GIDs found in the 'ssXX' coverage table, the application passes the GIDs to the 'ssXX' table and gets back one or more new GIDs.Discretionary features: can be applied to glyph runs based on document markup, user control or other application criteria.
UI suggestion: This feature should be off by default. Note that the application is responsible for counting and enumerating the number of features in the font with tag names of the format 'ss01' to 'ss20', and for presenting the user with an appropriate selection mechanism.

ssty:

Application interface: Feature is invoked automatically by math layout handler depending on nesting level inside the math formula.In recommended usage, this feature is used to trigger substitutions that are required for correct display of math formula. It should be applied in aapropriate contexts under the control of a math layout handler. If implemented in a font using an alternate substitution lookup, the first or second alternate glyph should be selected depending on the nesting level within the math formula.
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.

stch:

Application interface: For GIDs found in the 'stch' coverage table, the application passes the sequence of GIDs to the table, and gets back the GIDs for the multiple substitution.For characters that require stretching, such as Syriac abbreviation mark (U+070F), the 'stch' feature is applied. If the default glyph for the character is in the coverage of an associated lookup subtable, the mapped glyph sequence is retrieved. The last glyph of the substitute sequence is reordered to the end of the sequence of glyphs to be enclosed or encompassed. The remaining glyphs from the substitution sequence are inserted before the sequence of glyphs to be enclosed. Odd-numbered glyphs in the substitution sequence are positioned so as to be distributed evenly over the width of text being enclosed. Even-numbered glyphs are repeated so that the spaces between the odd-numbered glyphs is filled.
UI suggestion: This feature should be on by default.Control of this feature should not generally be exposed to the user.

subs:

Application interface: For GIDs found in the 'subs' coverage table, the application passes a GID to the feature and gets back a new GID.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. Note: This is a change of semantic value. Besides the original character codes, the application should store the code for the new character.

sups:

Application interface: For GIDs found in the 'sups' coverage table, the application passes a GID to the feature and gets back a new GID.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. Note: This can include a change of semantic value. Besides the original character codes, the application should store the code for the new character.

swsh:

Application interface: For GIDs found in the 'swsh' coverage table, the application passes the GIDs to the 'swsh' 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.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. If implemented in a font using an alternate substitution lookup, the application selects one of the alternative glyphs based on user choice or other criteria.

titl:

Application interface: For GIDs found in the 'titl' coverage table, the application passes the GIDs to the 'titl' table and gets back new GIDs.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.

tjmo:

Application interface: For substitutions defined in the 'tjmo' table, the application passes the sequence of GIDs to the feature, and gets back the GID for the trailing jamo form.In recommended usage, this feature triggers substitutions required for correct layout of certain scripts. It should be applied in the appropriate contexts, as determined by script-specific processing.
UI suggestion: This feature should be on by default.Control of this feature should not generally be exposed to the user.

tnam:

Application interface: For GIDs found in the 'tnam' coverage table, the application passes the GIDs to the table and gets back new GIDs.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. Note: This is a change of character code. Besides the original character code, the application should store the code for the new character.

tnum:

Application interface: For GIDs found in the 'tnum' coverage table, the application passes GIDs to the 'tnum' table and gets back new GIDs.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.

trad:

Application interface: For GIDs found in the 'trad' 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.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. If implemented in a font using an alternate substitution lookup, the application selects one of the alternative glyphs based on user choice or other criteria. The application stores a record of any simplified forms which resulted from substitutions (the 'smpl' feature); for such forms, applying the 'trad' feature undoes the previous substitution. Note: This is a change of character code. Besides the original character code, the application should store the code for the new character.

twid:

Application interface: For GIDs found in the 'twid' coverage table, the application passes the GIDs to the table and gets back either new GIDs or positional adjustments (XPlacement and XAdvance).Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.

Draft revisions for features 'kern' to 'ornm' (features_ko).
While working on these, some small updates were made to revisions shown earlier for consistency between related features (e.g., 'opbd'/'lfbd'/'rtbd') or greater consistency in wording for features with similarities. (I haven't revised the comments above to reflect these updates; it will be easier to review when drafts for the complete pages can be made available.)
kern:

Recommended implementation: The font stores a set of adjustments for pairs of glyphs (GPOS lookup type 2 or 8, XPlacement, XAdvance, YPlacement and YAdvance). These may be stored as one or more tables matching left and right classes, &/or as individual pairs. Additional adjustments may be provided for larger sets of glyphs (e.g. triplets, quadruplets, etc.) to overwrite the results of pair kerns in particular combinations.

Note: When using a GPOS type 2 lookup for this feature, it is recommended that no positioning adjustment be applied to the second glyph in a pair. (That is, that valueFormat2 be set to 0.) As a result, the next glyph pair to be processed after the lookup has been applied to this pair will start at the second glyph. In this way, every glyph in a sequence can undergo positioning adjustment as the first glyph in a pair. Otherwise, if positioning of the second glyph is adjusted, then the next glyph pair to be processed will begin with the glyph following the second glyph. That will result in kerning adjustment happening only for every other pair of glyphs.

Application interface: The application passes a sequence of GIDs to the 'kern' table, and gets back adjusted positions (XPlacement, XAdvance, YPlacement and YAdvance) for those GIDs. When using the type 2 lookup on a run of glyphs, it’s critical to remember to not consume the last glyph, but to keep it available as the first glyph in a subsequent run (this is a departure from normal lookup behavior).Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.

lfbd:

Application interface: For GIDs found in the 'lfbd' coverage table, the application passes a GID to the table and gets back a new XPlacement and XAdvance value.In recommended usage, the application applies this feature automatically to characters at the right end of a horizontal line when the 'opbd' feature has been applied to those characters. See the the 'opbd' feature for additional information.
UI suggestion: This feature is called by an application when the user invokes the 'opbd' feature.In recommended usage, this is applied to sequences automatically by applications when the 'opbd' feature is used, and direct user control is not required.

liga:

Application interface: For sets of GIDs found in the 'liga' coverage table, the application passes the sequence of GIDs to the table and gets back a single new GID. Note that full sequences must be passed.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.

ljmo:

Application interface: For substitutions defined in the 'ljmo' table, the application passes the sequence of GIDs to the feature, and gets back the GID for the leading jamo form.In recommended usage, this feature triggers substitutions required for correct layout of certain scripts. It should be applied in the appropriate contexts, as determined by script-specific processing requirements.
UI suggestion: This feature should be on by default.Control of the feature should not generally be exposed to the user.

lnum:

Application interface: For GIDs found in the 'lnum' coverage table, the application passes a GID to the 'lnum' table and gets back a new GID.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. Even if the current figures resulted from an earlier substitution, it may not be correct to simply revert to the original GIDs, because of interaction with the figure width features, so it’s best to use this table.

locl:

Application interface: Localized forms are associated with specific languages and are activated by language tags. Which glyph is used as the localized form should be determined by the language the user has specified. The user can switch localized forms by selecting a new language, or may enable default forms by switching off the 'locl' feature.In recommended usage, this feature triggers substitutions or positioning adjustments to provide the most appropriate typography for the language of content. This feature should always be applied. Language tagging or similar metadata indicating the language of the text should be used to select the most appropriate language system table within the font’s GPOS or GSUB table.
UI suggestion: This feature should be active by default.Control of the feature should not generally be exposed to the user directly. Control over language-specific typography should be provided by language settings or by providing the user ability to choose between the alternative language systems supported in the font’s GPOS or GSUB tables.

ltra:

UI suggestion: NoneControl of this feature should not generally be exposed to the user.

ltrm:
UI suggestion: NoneControl of this feature should not generally be exposed to the user.
mark:

Application interface: For GIDs found in the 'mark' coverage table, the application gets back the positioning or position adjustment values for the mark glyph. Script/language sensitivity: None.In recommended usage, this feature triggers positioning of mark glyphs required for correct layout. It should always be applied.
UI suggestion: Control of this feature should not generally be exposed to the user.
Script/language sensitivity: None.

med2:

Application interface: The application is responsible for noting word boundaries. For GIDs in the middle of words and found in the 'med2' coverage table, the application passes a GID to the feature and gets back a new GID.In recommended usage, this feature triggers substitutions required for correct layout of Syriac text. The application should always apply the feature to the Alaph glyph when the preceding base character is a joining character.
UI suggestion: This feature should be on by default.Control of the feature should not generall be exposed to the user.

medi:

Application interface: In recommended usage, this feature triggers substitutions that are required for correct display of cursively-connecting scripts. It should be applied in the appropriate contexts, as determined by script-specific processing requirements. 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 GIDsglyphs, 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.

mgrk:

Application interface: For GIDs found in the 'mgrk' coverage table, the application passes a GID to the feature table and gets back a new GID.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. Note: This is a change of semantic value. Besides the original character codes, the application should store the code for the new character.

mkmk:

Application interface: The application gets back positioning values or positional adjustments for marks.In recommended usage, this feature triggers positioning of mark glyphs required for correct layout. It should always be applied.
UI suggestion: This feature should be active by default.Control of this feature should not generally be exposed to the user.

mset:

Note: This feature is not recommended for use in new fonts.

nalt:

Application interface: For GIDs found in the 'nalt' coverage table, the application passes a GID and gets back a set of new GIDs, then stores the one selected by the user.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. If implemented in a font using an alternate substitution lookup, the application selects one of the alternative glyphs based on user choice or other criteria.
UI suggestion: This feature should be inactive by default. TheWhen implemented in the font using an alternate substitution lookup, the application must provide a means for the user to select the desired form from the set returned by the tablealternative glyphs mapped in the lookup. It can note the position of the selected form in a set of alternates, and offer the glyph at that position as the default selection the next time this feature is invoked. In the absence of such prior information, the application may assume that the first glyph in a set is the preferred form, so the font developer should order them accordingly.

nlck:

Application interface: Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.

nukt:

Application interface: The application passes the sequence of GIDs (consonant and nukta), to the table, and gets back the GID for the nukta form.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 requirements.
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.

numr:

Application interface: For GIDs found in the 'numr' coverage table, the application passes a GID to the table and gets back a new GID.In recommended usage, this feature is applied automatically as part of the application’s implementation for the 'frac' feature. See the 'frac' for details.
UI suggestion: This feature should normally be called by an application when the user applies the 'frac' feature.In recommended usage, this feature is applied to sequences automatically by applications when the 'frac' feature is used, and direct user control is not required.

onum:

Application interface: For GIDs found in the 'onum' coverage table, the application passes a GID to the 'onum' table and gets back a new GID.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.

opbd:

Application interface: For GIDs found in the 'opbd' coverage table, the application calls one of two related tables, depending on the position of the glyph. For glyphs at the left end of a horizontal line, it calls the 'lfbd' table, for glyphs at the right end of a horizontal line, it calls the 'rtbd' table.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. The application implementation for this feature should make use of the 'lfbd' and 'rtbd' features: the 'lfbd' feature should be applied automatically to glyphs at the left end of a horizontal line; the 'rtbd' feature should be applied automatically to glyphs at the right end of a horizontal line. It affects the line length, which should be taken into consideration by line-breaking and justification algorithms.
UI suggestion: This feature should be active by default. It effectively changes the line length, so justification algorithms should account for this adjustment.

ordn:

Application interface: For sets of GIDs found in the 'ordn' coverage table, the application passes the sequence of GIDs to the table and gets back new GIDs. Note that full sequences must be passed.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.  When processing lookups, context before or after the glyph sequence to which the feature is applied must be considered. Note: This may be a change of semantic value. Besides the original character codes, the application should store the code for the new character.

ornm:

Application interface: Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. When this feature is invoked, the application must note whether the selected text is the bullet character (U+2022) or alphanumeric characters. In the first case, it passes the GID for bullet to the 'ornm' table and gets back a set of GIDsretrieves the glyphs mapped from the bullet glyph, and gives the user a means to select from among them. In the second case, for GIDs found in the 'ornm' coverage table, it passes GIDs to the 'ornm' table and gets back new GIDsa substitution is applied directly.
UI suggestion: This feature should be inactive by default. When more than one GID is returnedWhen implemented in the font using an alternate substitution looup (the bullet case), an application could display the forms sequentially in context, or present a palette showing all the forms at once, or give the user a choice between these approaches. Once the user has selected a specific ornament, that one should be the default selection the next time the bullet is typed. In the absence of such prior information, the application may assume that the first ornament in a set is the preferred form, so the font developer should order them accordingly.

Cf. #622

Draft revisions for features 'aalt' to 'expt':
aalt:

Application interface: Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. The application determines the GIDglyph ID for the default form of a given character (Unicode valuedefault glyph from the 'cmap' table with no features applied). It then checks to see whether the GIDglyph ID is found in the 'aalt' coverage table. If so, the application passes this value to the feature table and gets back the GIDs in the associated groupretrieves the alternate glyphs mapped in the alternate substitution lookup.
UI suggestion: While most one-from-many substitution features can be applied globally with reasonable results, 'aalt' is not designed to support this use. The application should indicate to the user which glyphs in the user’s document have alternative forms (i.e which are in the coverage table for 'aalt'), and provide some means for the user to select an alternate glyph. When the user selects one of those glyphs and applies the 'aalt' feature, anAn application could display the forms sequentially in context, or present a palette showing all the forms at once, or give the user a choice between these approaches. The application may assume that the first glyph in a set is the preferred form, so the font developer should order them accordingly. When only one alternate exists, this feature could toggle directly between the alternate and default forms.

abvf:

Function: Substitutes the above-base form of a vowel. In particular, this feature is used for certain “split” vowels in Khmer or other Brahmi-derived scripts if the character has separate components that appear before and above a consonant, but the Unicode character for the vowel does not have a decomposition into separate characters for the two components.
Example: In complex scripts like Khmer, the vowel OEKhmer script, U+17BE KHMER VOWEL SIGN OE must be split into a pre-base form and an above-base form. The above-base form of OE would be substituted to form the correct piece of the lettervowel that is displayed above the base consonant.
Recommended implementation: This feature substitutes the GID for OE with the above part of the glyphis used to map the default glyph for OE to a glyph for the above-base component (GSUB lookup type 1).
Application interface: In recommended usage, this feature triggers substitutions required for correct display of Khmer script. It should be applied in the appropriate contexts, as determined by script-specific processing requirements. In particular, in a cluster in which the applicable split vowelIn a sequence where a split vowel with an above form is used, the application must insert the pre-base glyph into the correct location and then apply the above-base form feature to the split vowel. The application gets back the GID for the correct form for the piece that is placed above the base glyph. The application may also choose to position this glyph if required, after this feature is called.
UI suggestion: This feature should be on by default.Control of the feature should not generally be exposed to the user.

abvm:

Application interface: The application must define the GIDs of the base glyphs above which marks need to be positioned, and the marks themselves. If these are located in the coverage table, the application passes the sequence to the 'abvm' table and gets the positioning values (x,y) or positioning adjustments for the mark in return.In recommended usage, this feature triggers positioning of mark glyphs required for correct display of certain scripts. It should be applied in the appropriate contexts, as determined by script-specific processing requirements.
UI suggestion: This feature should be on by default.Control of the feature should not generall be exposed to the user.

abvs:

Recommended implementation: Lookups for this feature map each sequence of consonant and vowel sign to the corresponding ligature in the fontThe 'abvs' feature is used to map consonant vowel sequences to corresponding ligature glyphs (GSUB lookup type 4).
Application interface: The application must define the GIDs of the base glyphs and the mark that combines with it to form a ligature. The application passes the sequence to the 'abvs' table. If these are located in the coverage table, it gets the GID for the ligature in return.In recommended usage, this feature triggers substitutions required for correct display of certain scripts. It should be applied in the appropriate contexts, as determined by script-specific processing requirements.
UI suggestion: This feature should be on by default.Control of the feature should not generally be exposed to the user.

afrc:

Application interface: The application must define the full sequence of GIDs to be replaced. When the full sequence is found in the 'afrc' coverage table, the application passes the sequence to the 'afrc' table and gets a new GID in return.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. The application applies the feature to a complete sequence of figures separated by slash (U+002F) or fraction slash (U+2044).

akhn:

Recommended implementation: This feature maps the sequences for generating Akhands defined in the given script, to the ligature they formis used to map sequences that form Akhands to the corresponding ligature glyph (GSUB lookup type 4).
Application interface: The application passes the full sequence of GIDs. If these are located in the coverage table of the Akhand table, the application gets the GID for the akhand ligature in return.In recommended usage, this feature triggers substitutions required for correct display of certain scripts. It should be applied in the appropriate contexts, as determined by script-specific processing requirements.
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.

blwf:

Recommended implementation: This feature substitutes the GID sequence of virama (halant) followed by a consonant; by the GID ofis used to map a virama (halant) plus consonant sequence to the glyph for the below base form of the consonant (GSUB lookup type 4).
Application interface: In a conjunct formation sequence, if a consonant is identified as having a below base form, the application gets back the GID for this. The application may also choose to position this glyph if required, after this feature is called.In recommended usage, this feature triggers substitutions required for correct display of certain scripts. It should be applied in the appropriate contexts, as determined by script-specific processing requirements.
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.

blwm:

Application interface: The application must define the GIDs of the base glyphs below which marks need to be positioned, and the marks themselves. If these are located in the coverage table, the application passes the sequence to the 'blwm' table and gets the positioning values (x,y) or positioning adjustments for the mark in return.In recommended usage, this feature triggers positioning of mark glyphs required for correct display of certain scripts. It should be applied in the appropriate contexts, as determined by script-specific processing requirements.
UI suggestion: This feature should be on by default.Control of the feature should not generall be exposed to the user.

blws:

Recommended implementation: The 'blws' table maps the identified conjunct forming sequences; or consonant vowel sign sequences; to their ligaturesThe 'blws' feature is used to map consonant conjunct sequences or consonant vowel sequences to corresponding ligature glyphs (GSUB lookup type 4).
Application interface: For GIDs found in the 'blws' coverage table, the application passes the sequence of GIDs to the table, and gets back the GID for the ligature.In recommended usage, this feature triggers substitutions required for correct display of certain scripts. It should be applied in the appropriate contexts, as determined by script-specific processing requirements.
UI suggestion: This feature should be on by default.Control of the feature should not generally be exposed to the user.

calt:

Application interface: The application passes sequences of GIDs to the feature table, and gets back new GIDs. Note that full sequences must be passed.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.

case:

Recommended implementation: The font may implement this change by substituting different glyphs (GSUB lookup type 1) or by repositioning the original glyphs (GPOS lookup type 1, XPlacement and YPlacement).
Application interface: The application queries whether specific GIDs are found in the coverage table for the 'case' feature. If so, it passes these IDs to the table and gets back either new GIDs or positional adjustments (XPlacement and YPlacement).Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.
UI suggestion: It would be good to apply this feature (or turn it off) by defaultautomatically when the user changes case on a sequence of more than one character. Applications could also detect words consisting only of capitals, and apply this feature based on user preference settings.

ccmp:

Recommended implementation: The 'ccmp' table maps the character sequence to its corresponding ligature (GSUB lookup type 4) or string of glyphs (GSUB lookup type 2). When using GSUB lookup type 4, sequences that are made up of larger number of glyphs must be placed before those that require fewer glyphs.Glyphs for multiple characters are mapped to a single glyph (GSUB lookup type 4), or the glyph for a character is mapped to a sequence of glyphs (GSUB lookup type 2).
Application interface: For GIDs found in the 'ccmp' coverage table, the application passes the sequence of GIDs to the table, and gets back the GID for the ligature, or GIDs for the multiple substitution.This feature should always be applied.
UI suggestion: This feature should be on by default.Control of the feature should not generally be exposed to the user.

cfar:

Application interface: For substitutions defined in the 'cfar' table, the application passes the GID to the table and gets back the GID for an alternate form. TheIn recommended usage, this feature triggers substitutions that are required for correct display of Khmer script. It should be applied in the appropriate contexts, as determined by script-specific processing requirements. In particular, the application is expected to apply this feature if a syllable contains a Coeng Ra followed by other conjoining consonants or vowels.
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.

cjct:

Recommended implementation: The 'cjct' table maps the sequence of a consonant (the nominal form) followed by a virama (halant) followed by a second consonant (the nominal form or a half form) to the corresponding conjunct form (GSUB lookup type 4).A glyph for a consonant conjunct form is mapped from a sequence of two or more glyphs for consonants separated by virama (halant) (e.g., C H C, or C H C H C, etc.); or from sequences of glyphs involving simpler consonant conjuncts or conjoining consonant forms resulting from earlier substitutions from default consonant + virama + consonant (+ etc.) sequences (GSUB lookup type 4).
Application interface: For substitution sequences defined in the 'cjct' table, the application passes the sequence of GIDs to the table, and gets back the GID for the conjunct form.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 requirements.
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.

clig:

Application interface: For sets of GIDs found in the 'clig' coverage table, the application passes the sequence of GIDs to the table and gets back a single new GID. Note that full sequences must be passed.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. When processing lookups, context before or after the glyph sequence to which the feature is applied must be considered. Note: This may include a change of character code. Besides the original character code, the application should store the code for the new character.

cpct:

Recommended implementation: The font specifies X- and Y-axis adjustments for a small number of full-width glyphs (GPOS lookup type 1, XPlacement, XAdvance, YPlacement and YAdvance).
Application interface: For GIDs found in the 'cpct' coverage table, the application passes the GIDs to the table and gets back positional adjustments (XPlacement, XAdvance, YPlacement and YAdvance).Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.

cpsp:

Application interface: For GIDs found in the 'cpsp' coverage table, the application passes a sequence of GIDs to the 'cpsp' table and gets back a set of XPlacement and XAdvance adjustments.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. The application may rely on the user to apply this feature (e.g., by selecting text for a change to all-caps) or apply its own heuristics for recognizing words consisting of capitals.

cswh:

Application interface: For GIDs found in the 'cswh' coverage table, the application passes the GIDs to the 'cswh' table and gets back one or more new GIDs. If more than one GID is returnedDiscretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. If the font is implemented using an alternate substitution lookup, the application must provide a means for the user to select the one desired.
UI suggestion: This feature should be inactive by default. When more than one GID is returnedimplemented in the font using an alternate substitution lookup, an application could display the forms sequentially in context, or present a palette showing all the forms at once, or give the user a choice between these approaches. The application may assume that the first glyph in a set is the preferred form, so the font developer should order them accordingly.

curs:

Recommended implementation: TheLookup tables for the 'curs' table providesfeature provide entry and exit points (x,y) for glyphs to be cursively positioned (GPOS lookup type 3).
Application interface: For GIDs located in the coverage table, the application gets back positioning point locations for the preceding and following glyphs.In recommended usage, this feature triggers positioning adjustments that are required for correct display of fonts that implement cursive joining behavior. It should always be applied.
UI suggestion: This feature could be made active or inactive by default, at the user’s preference.Control of this feature should not normally be exposed to the user.
Script/language sensitivity: Can be used in any cursive script.Used primarily for Arabic and other cursively-connecting scripts, and also any other scripts for which cursive styles can optionally be used.

cvXX:
After the table giving the structure for the feature parameters table:

If a font supports two or more character variant features, use of Feature Parameters tables should be consistent across all of these features.

Later:

Application interface: Discretionary features: can be applied to glyph runs based on document markup, user control or other application criteria. The application is responsible for counting and enumerating the number of features in the font with tag names of the format 'cv01' to 'cv99', and for presenting the user with an appropriate selection mechanism. The application is also responsible for interpreting any feature parameter tables (if the application developer wishes to use that data) and presenting referenced strings in user interface. For GIDs found in the 'cvXX' coverage table, the application passes the GIDs to the 'cvXX' table and gets back one or more new GIDs; the application selects one of the returned GIDs for display. TheIf the font is implemented using an alternate substitution lookup, the application may use an index parameter as an index into the array of returned GIDsmapped glyph IDs.
UI suggestion: This feature should be off by default. An application can display glyph variants for a given character as a glyph palette in the user interface. If a Feature Parameters table is provided, the feature UI label or the feature andnamed parameter UI labels (if provided) can be presented in the application user interface; or the sample-text string (if provided) can be presented in the application user interface.
Script/language sensitivity: None. For each respective[/distinct] 'cvXX' feature, the FeatureParams in the FeatureList must point to the same set of values.

c2pc:

Application interface: For GIDs found in the 'c2pc' coverage table, the application passes GIDs to the 'c2pc' table, and gets back new GIDs.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. Note that applications may use this feature in an implementation to support petite-cap formatting applied to text with language-specific case-mapping logic. See 'pcap' and 'smcp' for additional information.

c2sc:

Application interface: For GIDs found in the 'c2sc' coverage table, the application passes GIDs to the 'c2sc' table, and gets back new GIDs.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. Note that applications may use this feature in an implementation to support small-cap formatting applied to text with language-specific case-mapping logic. See 'smcp' for additional information.

dist:

Function: Provides a means to control distance between glyphs.

Note: This feature should only be used for required positioning adjustments, not as an alternate kerning feature. For spacing adjustments that can be controlled by the user, the 'kern' feature should be used.

Example: In the Devanagari (Indic) script, the distance between the vowel sign U and a consonant can be adjusted using this.In Telugu script, adjust the placement of subjoined consonant forms to avoid collision with other glyphs.
Recommended implementation: The 'dist' tableThe font provides distances by which a glyph needs to move towards or away from another glyph (GPOS lookup type 2type 1, type 2, or contextual lookups that reference type 1 or type 2 lookups).
Application interface: For GIDs found in the 'dist' coverage table, the application passes their GID to the table and gets back the distance that needs to be maintained between them.In recommended usage, this feature triggers positioning adjustments that are required for correct display of the given script. It should be applied in the appropriate contexts, as determined by script-specific processing requirements.
UI suggestion: This feature could be made active or inactive by default, at the user’s preference.Control of the feature should not generall be exposed to the user.
Script/language sensitivity: Required in Indic scripts.
Feature interaction: None.This and other certain other features, such as 'kern', are typically implemented using single or pair adjustment positioning lookups. Note that, if multiple lookups are applied to a glyph, the positioning adjustments will be additive. The glyphs affected by the 'dist' and 'kern' features should be distinct unless it is intended that their effects can be combined.

dlig:

Application interface: For sets of GIDs found in the 'dlig' coverage table, the application passes the sequence of GIDs to the table and gets back a single new GID. Note that full sequences must be passed. This may include a change of character code.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. When processing lookups, context before or after the glyph sequence to which the feature is applied must be considered. Besides the original character code, the application should store the code for the new character.

dnom:

Application interface: For GIDs found in the 'dnom' coverage table, the application passes a GID to the table and gets back a new GID.In recommended usage, this feature is applied automatically as part of the application’s implementation for the 'frac' feature. See the 'frac' for details.
UI suggestion: This feature should normally be called by an application when the user applies the 'frac' feature.In recommended usage, this feature is applied to sequences automatically by applications when the 'frac' feature is used, and direct user control is not required.

dtls:

Application interface: Feature is invoked automatically by math layout handler depending on height of the base formula box.In recommended usage, this feature is used to trigger substitutions that are required for correct display of math formula. It should be applied in appropriate contexts under the control of a math layout handler. See the 'math' table chapter for additional information.
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.

expt:

Application interface: For GIDs found in the 'expt' coverage table, the application passes the GIDs to the table and gets back one new GID for each.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. Note: This is a change of character code. Besides the original character code, the application should store the code for the new character.

Draft revisions for features 'falt' to
falt:

Application interface: For GIDs found in the 'falt' coverage table, the application passes a GID to the table and gets back a new GID.In recommended usage, this feature is applied automatically to final glyphs of lines when text is justified. The feature may affect the length of lines, which should be taken into consideration by line-breaking and justification algorithms.

fin2:

Recommended implementation: TheA 'fin2' lookup table maps default alphabetic forms to corresponding final forms (GSUB lookup type 5type 1).
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.In recommended usage, this feature triggers substitutions required for correct layout of Syriac text. The application should always apply the feature to the Alaph glyph when the preceding base character is non-joining and is a character other than Dalath, Rish, or dotless Dalath-Rish.
UI suggestion: This feature should be on by default.Control of the feature should not generall be exposed to the user.

fin3:

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.In recommended usage, this feature triggers substitutions required for correct layout of Syriac text. The application should always apply the feature to the Alaph glyph when at the end of Syriac words if the preceding base character is Dalath, Rish, or dotless Dalath-Rish.
UI suggestion: This feature should be on by default.Control of the feature should not generall be exposed to the user.

fina:

Application interface: In recommended usage, this feature triggers substitutions that are required for correct display of cursively-connecting scripts. It should be applied in the appropriate contexts, as determined by script-specific processing requirements. 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.

flac:

Application interface: Feature is invoked automatically by math layout handler depending on height of the base formula box.In recommended usage, this feature is used to trigger substitutions that are required for correct display of math formula. It should be applied in the appropriate contexts, as determined by math layout handler. See the 'math' table chapter for additional information.
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.

frac:

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).Glyphs for figures (digits) separated by a slash (U+002F) are mapped to variant forms (GSUB lookup type 1, or contextual substitutions that reference type 1 lookups), or sequences of such glyphs are mapped to ligature fraction glyphs (GSUB lookup type 4).
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 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 to replace all remaining figures (as listed in the 'dnom' coverage table) with denominators.The application evaluates the sequence of glyphs for the span of characters over which this feature has been applied by the user. If an associated lookup subtable matches the entire glyph sequence, the substitutions described in that lookup are applied to the glyph sequence directly. If no lookup subtable is found that matches the entire sequence, then the application does the following:

Apply the 'numr' feature to the figures within the span that precede the slash and also to the slash, and process associated lookups.
Apply the 'dnom' feature to the figures within the span that follow the slash and process associated lookups.

fwid:

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, XPlacement and XAdvance).
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).Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.

half:

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.In recommended usage, this feature triggers substitutions required for correct display of certain scripts. It should be applied in the appropriate contexts, as determined by script-specific processing requirements.
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.

haln:

Function: Produces the halant forms of consonants in Indic scripts (that is, precomposed glyphs for consonant with the halant).
Example: In Sanskrit (Devanagari script), syllable final consonants are frequently required in their halant form.
Recommended implementation: TheA 'haln' lookup 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 'haln' 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.In recommended usage, this feature triggers substitutions required for correct display of certain scripts. It should be applied in the appropriate contexts, as determined by script-specific processing requirements.
UI suggestion: This feature should be on by default.Control of the feature should not generally be exposed to the user.

halt:
(These revisions include changes for consistency with the newly-added 'chws' feature.)

Function: RespacesRe-spaces glyphs designed to be set on full-em widths, fitting them onto half-em widths., to approximate more sophisticated text layout, such as what is described in [Requirements for Japanese Text Layout (JLREQ)][1] or similar CJKV text-layout specifications that expect half-width forms of characters whose default glyphs are full-width.* This feature differs from 'hwid' in that it does notis not used to substitute new glyphs.
* In JLREQ, see, in particular, [3.1.4 Positioning of Consecutive Opening Brackets, Closing Brackets, Commas, Full Stops and Middle Dots][2] and [B. Spacing between Characters][3]. See also [Requirements for Chinese Text Layout (CLREQ)][4], [Requirements for Hangul Text Layout (KLREQ)][5].
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, XPlacement, XAdvance, YPlacement and YAdvance).
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).If a layout engine supports advanced layout for CJKV text as described in [CLREQ][4], [JLREQ][1] or [KLREQ][5], this feature should not be used. Otherwise, this feature should be enabled in horizontal layout to all CJKV text or selectively to particular characters that require special treatment in CJKV text layout, such as brackets, punctuation, and quotation marks.
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)][1] 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.This feature should not be used in combination with a layout engine that independently provides advanced layout as described in [CLREQ][4], [JLREQ][1] or [KLREQ][5]. For applications that provide such advanced layout, it may appropriate not to expose control of this feature to users. In applications that do not support such advanced layout, this feature should be enabled by default for horizontal layout of CJK text.

hist:

Application interface: For GIDs found in the 'hist' coverage table, the application passes the GIDs to the 'hist' table and gets back new GIDs.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.

hkna:

Application interface: For GIDs found in the 'hkna' coverage table, the application passes GIDs to the feature, and gets back new GIDs.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.

hlig:

Recommended implementation: The 'hlig' table maps default ligatures and character combinations to corresponding historical ligatures (GSUB lookup type 1).Sequences of glyphs for certain character combinations are mapped to corresponding historical ligature glyphs.
Application interface: For GIDs found in the 'hlig' coverage table, the application passes the GIDs to the 'hlig' table and gets back new GIDs.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.

hngl:

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.Glyphs for hanja characters are mapped to corresponding glyphs for Hangul syllables (GSUB lookup type 1); or default glyphs for hanja characters are mapped to two or more corresponding alternate glyphs for Hangul syllables (GSUB lookup type 3). 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 returnedDiscretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. If the font is implemented using an alternate substitution lookup, 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.

hojo:

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.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.

hwid:

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).Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.

init:

Application interface: In recommended usage, this feature triggers substitutions that are required for correct display of cursively-connecting scripts. It should be applied in the appropriate contexts, as determined by script-specific processing requirements. 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.

isol:

Application interface: In recommended usage, this feature triggers substitutions that are required for correct display of cursively-connecting scripts. It should be applied in the appropriate contexts, as determined by script-specific processing requirements. 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.

ital:

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.This feature is applied automatically by the application based on italic formatting indicated in document markup, user control or other means.

jalt:

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.In recommended usage, this feature is applied automatically to glyphs in justified text, as determined by a justication algorithm or direct user control. The feature may affect the length of lines, which should be taken into consideration by line-breaking and justification algorithms.

jp78:

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 returnedDiscretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. If the font is implemented using an alternate substitution lookup, 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.

jp83:

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 returnedDiscretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. If the font is implemented using an alternate substitution lookup, the application must provide a means for the user to select the one desired.

jp90:

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.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. Note: This is a change of character code. Besides the original character code, the application should store the code for the new character.

jp04:

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.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria.

All features have been reviewed in relation to this issue and revisions drafted as applicable.
If there is feedback on any feature description not related to the core issue here (don't describe features as though they're functions), please open a separate issue.


Master patient list

See all patients

Filter the patients

View one patient

I really hate to ask this, but do you think you could squash these commits down?


Update comment for one-time payment

This comments refers to a subcollection on subscription doc, but I think it should ref to the customer doc.
We aren't writing to subscription, but to customer.
This came up because I'm not using subscriptions but do want to use this to sync payments on one-time purchases (via checkout_session and/or manual invoices)
Overall, it seems like this extension assumes invoice == subscription. Which is fine. I'll just handle certain webhook events outside of this extension. But this is an area where it seems like we can decouple things nicely (FWIW)

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Just Get the Chat Part

Hello, I just discovered your package, installed it and found that it works very well. But I need your opinion to make an edit. I am making a new application, the general parts of the application are ready, I just want to use your package for the messaging part. I have my own membership system and database. How can I remove the login and registration section in your package and integrate my own member list? Which are the fields where I can change UserId and other parts?

Hello, thanks! So you will have two backends:

nodejs_websocket_backend (WebSocket backend from this project)
Your existing backend

Host nodejs_websocket_backend separated from your existing backend project.
Follow all the instructions on Getting started section on GitHub, and customize nodejs_websocket_backend/environment/db.ts to use your existing db (don’t use production db for now ⚠).
You may also want to customize the entities the way your db is designed on nodejs_websocket_backend/src/domain/entity.
So the Flutter App will no longer generate the token interacting with nodejs_websocket_backend, but interacting with your existing backend instead:
Go to flutter_app/lib/features/login_and_registration/data/data_sources/auth_remote_ds.dart and change the code from  getAccessTokenWithEmailAndPassword and also useRefreshTokenToGetNewAccessToken functions to call your existing API, so the code AsklessClient.instance…(something) will no longer exist inside these 2 functions.
On nodejs_websocket_backend/src/index.ts change the code from the authenticate(...) function and replace it with your custom token validation logic.


Impersonation behaviour when protected domains/users list is empty

If in the default Anti-Phishing policy you configure the "Action > Domain impersonation" and set it to Quarantine the message, bu t leave the list under "Protect specific domains, include custom domains" empty, what is the expected behaviour? I would expect nothing, but have some hints that if the list is empty all non-owned domains are effected, resulting in all email send on behalf of... (for example via mailchimp, surveymonkey or any other mass mailing systems) directly to quarantine.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: f0b8f651-9d8e-a34b-8dde-2b6a9448f875
Version Independent ID: 20e96426-627d-9973-8303-a43a114c7b61
Content: Set up Office 365 ATP anti-phishing policies - Office 365
Content Source: microsoft-365/security/office-365-security/set-up-anti-phishing-policies.md
Service: o365-seccomp
GitHub Login: @MSFTTracyP
Microsoft Alias: tracyp

@kennethvs, if Include custom domains is On, yet the list of domains is empty, I, too, would expect nothing to happen. Do you have evidence to the contrary?

@kennethvs - Thank you for submitting feedback.
From our understanding, the issue you raised has been answered by chrisda so we will close this issue.
Thank you for your contribution to make the docs better! Much appreciated!

Hi All,
Sorry for not answering... we raised a MS Support ticket for this behavior (Case #:19498641) - it seems that the Domain Impersonation filtering was not working as we expected. Let's say for example that you have a domain called survey.nl and receive email from surveymonkey.com - that email is then considered domain impersonation causing it to end up in Quarantine. You should then mark surveymonkey.com as a trusted domain within the same policy.
Regards,
Kenneth