[ios, macos] Adds support for specifying an ideographic font family name

[akitchen]

Adding a MGLIdeographicFontFamilyName to the containing app's Info.plist
will result in CJK glyphs being rasterized on demand (#10522)

I'm not really sure how we want to thread this info in, so this is partly a request for comment on the approach. Ultimately it may make sense to have this info live on the style somehow but obviously that would entail much broader scope. This may meet our needs for the time being.

cc/ @ChrisLoer @1ec5 @boundsj

[1ec5]

This is a pretty elegant solution to the issue raised in #10522 (comment). Medium-term, I think it would be preferable to allow developers to specify different font families for different map views, just as they can with GL JS. (And longer term, different font families for each layer, as described in #10522 (comment).) But this should meet the most pressing need for the time being.

Since this PR introduces a new Info.plist key, would you mind documenting it in the “Info.plist Keys” document (iOS, macOS), which is included in the jazzy docset?

[ChrisLoer]

Awesome, thanks @akitchen !

[akitchen]

Thanks for the feedback. This was meant to make this feature easy to use as it currently stands; longer-term I think we have room for improvement (specifying font into per-layer, per-style, changing at runtime, etc.). My concern with this implementation choice is that we'd be introducing a new Info.plist key only to replace it down the road with more code infrastructure and breaking API changes. I think more conversation might be needed as to short term vs. long term goals here.

[akitchen]

@pveugen and I were chatting about this this morning and he shares my concern re: introducing a new Info.plist key only to deprecate it soon thereafter. Also, Info.plist values are effectively global constants, and we ultimately want this to be more dynamic and customizable. So I'm going to continue to iterate on this a little bit.

For now a more forward-compatible strategy that minimizes entropy for apps integrating the SDK might be to hardcode the font family name in a way which an app developer can override if desired (probably Arial Unicode MS due to its very high glyph count) and then incrementally introduce more configurability in subsequent releases.

We should be aiming to enable the basic use case as early as possible, enhancing the developer experience in subsequent releases as we learn more about what our users need to do.

/cc @1ec5 @ChrisLoer

[ChrisLoer]

For now a more forward-compatible strategy that minimizes entropy for apps integrating the SDK might be to hardcode the font family name in a way which an app developer can override if desired (probably Arial Unicode MS due to its very high glyph count) and then incrementally introduce more configurability in subsequent releases.

Do you mean make them build their own version of the SDK if they want to change it?

As in GL JS, I think it makes sense for the default setting to be no local glyph generation at all -- because that's the setting that's most correct/loyal-to-the-style-spec.

[akitchen]

Do you mean make them build their own version of the SDK if they want to change it?

No, it shouldn't be necessary.

It might feel a little dirty, but under the current factoring a developer could inject a value by overriding that method with an implementation in a class category (or subclass, I guess). This would allow us to be consistent with gl-js here (if that is indeed a goal) while avoiding introducing soon-to-be-deprecated Info.plist keys.

If the base implementation of -[MGLMapView ideographicFontFamilyName] simply returned nil, then the containing app would include something like the following:

#import <Mapbox/Mapbox.h>

@implementation MGLMapView (RendererConfiguration)

- (NSString *)ideographicFontFamilyName {
    return @"Arial Unicode MS";
}

@end

Long term I wouldn't want this to be the solution, but it's an option until we have a better abstraction in place. At the moment we don't have any mechanism (that I'm aware of) for users to provide configuration values to the renderer or map view at initialization time.

/cc @1ec5 @ChrisLoer

[1ec5]

Would -ideographicFontFamilyName be publicly documented? I think an Info.plist entry would be easier to deprecate than a formal API. Let’s suppose a subsequent release offers the ability to specify an entire font descriptor rather than just a family name: then -ideographicFontFamilyName would hang around as part of the public API, whereas we could just remove any mention of the Info.plist key, even if we continue to provide a compatibility shim. (It would be pretty straightforward to implement such a shim, in any case.)