Add NSExpression operator for rich text (format expressions)

[1ec5]

The iOS and macOS map SDKs’ NSExpression implementation will automatically support the format expression support being added in #12624, via the MGL_FUNCTION expression operator. However, this operator is only a last-ditch fallback; for something as amenable to runtime styling as formatted text fields, we would want to provide a more ergonomic representation when working with NSExpression.

During early design discussions for the formatted string feature, I had proposed possibly piggybacking on NSAttributedString as a familiar platform-specific representation for the style specification’s Formatted type. NSAttributedString was attractive because of its numerous methods for applying and inspecting attributes. It seemed natural that a rich text object would be represented by the platform’s standard rich text class.

Unfortunately, NSAttributedString didn’t turn out to be a good fit for the format expression for a couple reasons:

• We expect that Formatted objects would tend to contain non-constant string expressions. NSAttributedString assumes each set of attributes is applied to a run of text represented by a character sequence, not an expression of variable length. A Formatted object containing a non-constant string expression would have to be represented by an NSAttributedString containing an NSTextAttachment, with the attribute name as NSData – not a particularly convenient representation.
• The format operator’s annotation objects currently support font-scale and text-font properties that bear no relation to NSAttributedStringKey. It would be no problem to define ad-hoc attribute keys like MGLFontScaleAttributeName that are set to NSExpressions, but the lack of support for NSFontAttributeName could be surprising to developers.

The obvious alternative to NSAttributedString would be a more literal translation of the JSON, an aftermarket expression operator like mgl_attributed({…}). (The term “format” should be avoided for its similarity to -[NSString stringWithFormat:], and “annotation” could be confused with MGLAnnotation.) The main problem with the literal approach is that NSExpression’s format string syntax lacks dictionary literals, so the annotation objects would have to be represented by %@ placeholders in most cases.

Perhaps it would be too ambitious to come up with an ergonomic, one-to-one representation of all Formatted obects in NSExpression. Maybe it would be OK to convert format JSON expressions to MGL_FUNCTION NSExpressions.

If so, I’d recommend implementing very basic NSAttributedString support only as a convenience when going from NSExpression to JSON. Besides supporting MGLFontScaleAttributeName and MGLFontNamesAttributeName attributes, we could helpfully convert any NSFontAttributeName to the appropriate font-scale and text-font annotation arguments. (font-scale might be difficult because the overall expression doesn’t contain the base font size.) We could also extend NSTextAttachment to make it easier to put an expression inside an NSAttributedString.

/cc @fabian-guerra @ChrisLoer

[1ec5]

It would be no problem to define ad-hoc attribute keys like MGLFontScaleAttributeName that are set to NSExpressions, but the lack of support for NSFontAttributeName could be surprising to developers.

As a counterpoint, the CarPlay framework uses attributed strings to allow images to be embedded as text attachments in instruction text, but “other text attributes including text size and fonts will be ignored”.

/ref mapbox/mapbox-navigation-ios#1665

[stale]

This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.

[fabian-guerra]

Although #14094 creates the bindings for the format expression, it does not addresses the intent of using the foundation framework rich text capabilities. Will keep open this until further discussion.