Support locale and font validation for Android

[sffc]

There are at least four questions that would be useful to have a library solution to solve for the Android ecosystem:

1. Does this device support Unicode for Myanmar script? What about Zawgyi?
2. In case of devices with both Unicode and Zawgyi support, are we running in a Zawgyi locale or a Unicode locale?
3. Should the UI language be in Burmese or English?
4. Is the locale's country an alias for Myanmar?

@mihnita says that any implementation of these features would need to be Android-specific and would probably not work outside of an Android environment. Therefore, this could be implemented by a sub-library within Myanmar Tools, distributed under its own artefact ID.

Ideas for APIs that such a library could provide:

public enum BurmeseFontEncoding {
  UNICODE,
  ZAWGYI
};

/**
 * Returns the default font encoding used to render Burmese text on this device.
 */
public BurmeseFontEncoding getDefaultBurmeseFontEncoding() {}

/**
 * Returns an ordered list of fonts available on the system that have Burmese-range
 * code points, in the order of priority.
 */
public List<Font> getAvailableBurmeseFonts() {}

The implementation of this library would need to be based on heuristics from the Android ecosystem.

[alp]

@sffc what would be a result of getDefaultBurmeseFontEncoding() call for a system which doesn't have Burmese fonts installed? Also, I'd like to clarify intended use case for getAvailableBurmeseFonts(). Will it be used to populate fallback fonts in an app?

[sffc]

@sffc what would be a result of getDefaultBurmeseFontEncoding() call for a system which doesn't have Burmese fonts installed?

Good question. What do you think good behavior would be? I could see arguments for either returning UNICODE or for returning a new enum value like NOT_AVAILABLE.

Also, I'd like to clarify intended use case for getAvailableBurmeseFonts(). Will it be used to populate fallback fonts in an app?

I was thinking it would be used to return which system fonts are available for an app to use. I am not an expert on how font fallback works in Android, though. @mihnita should have more information on this.

[alp]

Good question. What do you think good behavior would be? I could see arguments for either returning UNICODE or for returning a new enum value like NOT_AVAILABLE.

Agree, there are arguments for both. I have a slight preference to own dedicated NOT_AVAILABLE or UNKNOWN value. Mainly because it can enable developers to trigger any additional logic to handle these cases, or communicate it more explicitly to a user.

[mihnita]

I am wondering if we want to keep the "font" in the API names. It only makes them look verbose.

APIs that I can think of:

• Tell me if this system supports Burmese, all 4 combinations (no support / Unicode only / Zawgyi only / Unicode + Zawgyi)
• What kind of Zawgyi support there is ("legacy Zawgyi" (OEM hacks, pre Q) or "Google endorsed Zawgyi" (>= Q))
• List of Burmese Zawgyi fonts (?) (the class is Typeface, not Font)
• List of Burmese Unicode fonts (?) (the class is Typeface, not Font)
• List of Burmese locales, and "kind". Maybe unified with the first API? (if the system supports Burmese)
• APIs to detect the encoding of a string, and to convert between Zawgyi and Unicode (both way)

Might be really nice to have some "magic incantation" that on can call at application startup and would make it work without major changes. And / or APIs that do the conversion "on the fly" when set / get text in widgets.

[alp]

Also we learned recently about a hybrid font ZawDecode (http://aungthurhahein.github.io/ZawDecode/), which is based on Unicode standard, but can render Zawgyi too (85% accuracy is claimed). With a proposed classification, I think it's acceptable to treat it as a Unicode one.