As Adobe registered this feature, they should provide clarification.

These three features are some of the unimplemented featured and should be deprecated (they are unimplementable as they go against how OpenType shaping is done in virtually all implementations). I have only ever seen one font that has opbd feature (and the values were just garbage) and no implementation that supports them.

These are part of a speculative model of OTL implementation that Adobe envisaged in the early days of OpenType, in which some features referenced other features. It was based on a misunderstanding of the relationship of OTL feature tags to software UI, so the opbd feature would provide the UI for the lower level lfbd and rfbd features. Not sure what the folks at Adobe were smoking at the time.

I agree with Khaled that these features as specified are unimplemented and probably unimplementable in the common OTL implementation model (so like the daffy size feature). opbd should be deprecated. The lfbd and rfbd should either be deprecated or rewritten in a way that makes them implementable.

I asked Adobe, who registered these features, to investigate this issue.

In the meantime, I've revised the opbd/lfbd/rtbd feature descriptions as part of work for #347 and #601. I'll repeat here the current drafts for these features (including unchanged portions that are relevant for this issue)—note that the revisions address only #347/#601 and do not attempt to address the issue reported here.

opbd:

Function: Aligns glyphs by their apparent left or right extents in horizontal setting, or apparent top or bottom extents in vertical setting, replacing the default behavior of aligning glyphs by their origins. Another name for this behavior would be visual justification. The optical edge of a given glyph is only indirectly related to its advance width or bounding box; this feature provides a means for getting true visual alignment.

Example: Succeeding lines beginning with T, D and W would shift to the left by varying amounts when the text is left-justified and this feature is applied. Succeeding lines ending with r, h and y would likewise shift to the right by differing degrees when the text is right-justified and this feature is applied.

Recommended implementation: Values for affected glyphs are defined with a separate record for left, right, top, and bottom. Each record describes the amount by which the placement and advance width should be altered (GPOS lookup type 1).Positioning adjustments (GPOS lookup type 1) are implemented in separate lookups associated with features for left, right, top and bottom line positions.

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.

lfbd:

Function: Aligns glyphs by their apparent left extents at the left ends of horizontal lines of text, replacing the default behavior of aligning glyphs by their origins. This feature is called by the Optical Bounds ('opbd') feature.

Example: Succeeding lines beginning with T, D and W would shift to the left by varying amounts when the text is left-justified and this feature is applied.

Recommended implementation: Values for affected glyphs describe the amount by which the placement and advance width should be altered (GPOS lookup type 1).

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.

rtbd:

Function: Aligns glyphs by their apparent right extents at the right ends of horizontal lines of text, replacing the default behavior of aligning glyphs by their origins. This feature is called by the Optical Bounds ('opbd') feature.

Example: Succeeding lines ending with r, h and y would shift to the right by differing degrees when the text is right-justified and this feature is applied.

Recommended implementation: Values for affected glyphs describe the amount by which the placement and advance width should be altered (GPOS lookup type 1).

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 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 feature is applied to sequences automatically by applications when the 'opbd' feature is used, and direct user control is not required.

We are investigating.

Adobe would like ‘opbd’ and its minions ‘lfbd’ & ‘rtbd’ to be marked as deprecated in the features registry.

I am 100% okay with opbd being deprecated.

The individual lfbd and rtbd features are, however, potentially useful without opbd if rewritten and, indeed, could constitute part of a model that might also involve tpbd (top) and (btbd) bottom optical bounds features for vertical text. The error of the original feature registration was the idea that a single feature was needed to be able to apply the others, as a kind of gateway between application function and the individual features and their lookups. The idea of using GPOS to define margin alignment isn't a terrible one in itself, especially for some scripts and styles that are not well served by algorithmic margin alignment such as currently available in InDesign.

That said, implementation of GPOS optical margin alignment, in both fonts and applications, requires some significant work, which I'm not holding my breath awaiting. I would rather, however, consider these features potential or pending, rather than deprecated. It would be silly to formally deprecate them and then decide down the road that we'd actually like to use them.

As part of a separate issue that required touching the “Application interface” fields, I’ve drafted a revision for ‘lfbd’ and ‘rtbd’ to say the following:

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.

To allow for usage of ‘lfbd’ or ‘rtbd’ independent of ‘opbd’, I’ve have to revise that, but that would be doable.

Note that an actual implementation would throw up a number of interesting practical issues. The lfbd and rtbd features should be applied, respectively, when text is left-aligned or right-aligned. That would imply not only margin alignment, but also column alignment, and even tab alignment. While margin and column widths may reasonably be assumed to be wide enough to merit text boundary alignment, tab distances may be close, and it may be necessary for software to use some kind of tolerance when determining whether to apply a boundary alignment feature.

If text is justified (i.e. both left and right boundaries are aligned to margin, column edges, etc..) the output of the lfbd and rtbd features needs to be taken into account for linebreaking and other justification functions such as wordspacing tolerances or kashida insertion.

Because of the amount of work involved in defining lfbd and rtbd GPOS lookups (and the current lack of any very convenient visual editing tool), I don't imagine it being something a lot of font makers would do for a lot of fonts (although that may be different if automated (paging Mr Cozens)). I can imagine it being most desirable in some display fonts with unusual glyph shapes, extending left and right swashes intended for line initial and final use, and similar things that don't submit well to algorithmic text boundary alignment.

The individual lfbd and rtbd features are, however, potentially useful without opbd if rewritten and, indeed, could constitute part of a model that might also involve tpbd (top) and (btbd) bottom optical bounds features for vertical text.

I still GPOS is a bad place for this information. GPOS arranges lookups in scripts and languages which makes sense while doing basic shaping, but by the time optical alignment is done (after line breaking and after/during justification), the script and language itemization of the text is probably gone, or makes no sense to be respected, but implementations need to still deal with all the complexity or do special casing (e.g. only check for DFLT lookups). Moreover, parts of the text layout stack needing this information are not usually OpenType shapers but higher level code, so they are forced to re-implement substantial parts of GPOS table or convince OpenType engines to give them the data.

Since these features are not used and have been used in the past 20 years, they should be deprecated for good and alternative explored based on the needs of implementations, may be a dedicated table like Apple’s opbd table would be a better and more implementable way, may be something entirely different.

Features like opbd or size give a feeling that people tried to shoehorn anything vaguely related to glyph positioning into GPOS, even if the model of operation is completely different.

Good points, Khaled. As a counterpoint, one could say that optical bounds adjustments are just kerning to the space outside the text. :)

I've heard input here and also in other contexts (mpeg-otspec list, offline discussion with Apple, MS.) Based on the combined input, I think there's general consensus to let 'opbd' be deprecated, but not to deprecate 'lfbd' and 'rtbd': there's still thinking that they are potentially useful and indication that they are, in fact, supported in some apps.

Proposed revisions for next version:

opbd:

Tag: 'opbd' (DEPRECATED)

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.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. In recommended usage, the application applies this feature to characters at the left end of a horizontal line when paragraphs are left or left and right justified.

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.Discretionary feature: can be applied to glyph runs based on document markup, user control or other application criteria. In recommended usage, the application applies this feature to characters at the right end of a horizontal line when paragraphs are right or left and right justified.