To provide a more detail beyond what Simon said (a bit technical, but useful to understand):
Digital text has an encoded form, which almost ubiquitously is Unicode. This assigns a numeric encoding for every character of every writing system, and that is how characters are stored in a computer or transmitted between computers. For example, the numeric value 65 (in Unicode hex notation, U+0041) is used as the encoded representation for Latin capital letter "A"; the value 3,627 (U+0E2B) is used to represent Thai letter ha "ห", etc.
Everything that happens when entering, processing, or displaying text is done in terms of the encoded representation inside the computer. When you press a key on a keyboard and see something display on the screen, there is not a direct connection from keyboard to font. Rather there are two sequential interactions: the keypress results in generating the encoded representation stored in the computer, then a separate process takes that encoded representation and displays it on the screen using a font.
The important point here is that there is no direct connection between a shift key or any other key and a font. The effect of pressing keys is to generate Unicode encoded sequences stored in the computer, and what the effect is of any key depends entirely on the programming of a keyboard input method. In principle, a keyboard input method can be created to allow two shift keys to behave differently in terms of the encoded sequences that get generated, but that is not common. On the other hand, it is not uncommon for the right Alt key on a PC to have different effects than the left Alt key.
When creating a font, you generally should not be thinking about keying sequences that produce different visual results. Rather, you should think in terms of Unicode character sequences, and creating a font that will produce a display of text that reflects the Unicode-defined semantics of the encoded characters. Then, if you need a particular keying experience, there would be an independent exercise of creating an input method that produces a Unicode character sequence from the desired keypress sequences.
If you create a font that produces some custom association between keystrokes and display, then most likely what you will have done is to create a font that assigns glyphs to Unicode encoding in a misaligned way, so that the font does not match the underlying Unicode semantics of the data. That will make the font and the data produce unusable by anyone except if displayed by that font.
Back in 2001, I wrote a chapter in a book explaining these concepts; it's available online here:
Dave's links to the font-resource and fonts-in-xml pages mention use of a font within the app package. That's been supported in Windows app packages since Windows 8. The main difference is that Android allows you to designate font files as a distinct "font" resource type, whereas in Windows they are just binary file assets. (They can be embedded into the package resource index (.pri) file rather than loose.)
Downloadable font support is new in the latest Android release. We had support for downloading fonts from a Windows library in the first Windows 10 release, and added support for downloading fonts from any cloud font service in the Windows 10 Creators Update (spring 2017).
The interesting things that Android has done are (i) to be able to incorporate a downloadable font in an app by making a declaration in the app manifest, and (ii) explicit handling of certs.
I noticed the discrepancy while preparing the draft text for OT 1.8 and followed up with Apple. They did update the description for the dataOffset field in the data map record, that the offsets are from the start of the 'meta' table, and that makes clear where the data corresponding to a given record is located. It also makes clear that the dataOffset field in the header isn't required. Their spec also indicates that the data map records follow the header.
They probably should update the header description in their spec.
As confirmation of what I'm saying, here's an excerpt from discussion I had with John Jenkins -- this is John writing:
"Yes, the offsets are really from the start of
the 'meta' table and not the start of the data. (We recently updated our spec
to reflect this.) I think the best thing to do—since there are already
implementations out there—is to change the 'offsetToData' field in
the header to 'unused; set to 0'..."
And later in the discussion,
"I think it would still be a good idea to have
zeroing it out be the norm."
Wrt "supported", that is still ambiguous, but let me make some observations:
First, "supported" is the less interesting of the two concepts. It's mainly useful for font fallback or font binding scenarios as a heuristic to decide, "Is it worth even trying to display this string using this font?" Ultimately, the question of whether a font can display a string is determined from the 'cmap', and data such as the "supported" field or OS/2 fields is just a first-level heuristic for this.
Secondly, the OS/2 Unicode range fields were initially based on Unicode blocks, and blocks don't really correspond to anything that has practical use. For example, consider the currency symbols block: there aren't very many usage scenarios that involve all or even a large number of those characters at once. Nobody writes messages in currency symbols, for instance. Or, consider Romanian or Turkish text, say: there are multiple Unicode blocks you would need to check to determine if a font can display it. But a font certainly doesn't need to have complete coverage of all those blocks to support Romanian or Turkish. Should a font designed to support Romanian and Turkish but not, say, Lithuanian set Unicode range bits for those blocks? If it does, that may result in misleading an app used for Lithuanian.
"Supports" allows one to be specific, if desired; e.g., to say that the font can support Romanian and Turkish, but not list Lithuanian. For widely-used scripts like Latin, though, I wouldn't want to be the font developer struggling over what languages to specifically mention and how to verify that. (Btw, see the thread on testing for language coverage.)
It's much easier to simply make a declaration about a script: "This font supports Latin script". Of course, particularly for Latin and Cyrillic, or even Arabic, there are so many characters used for certain languages but not others, this can be very ambiguous. My guidance would be to declare support for the script if there are any major languages that could be displayed using the font. Keeping in mind that this is no more than a heuristic for font fallback, I think that's good enough.
I'm not sure that this moves discussion of UI for variable fonts forward that much. It's fairly obvious to make the connection between an N-dimensional variable font with numeric inputs and a collection of up-to-N controls each of which can set up-to-N numeric values. I don't find discussion of multi-variant data visualization all that helpful because visualization of the N dimensions isn't a goal: seeing text formatted using the selected font instance is the only necessary and best visualization of the selected settings; and a radar chart that shows the settings on N axes for "Display Narrow" doesn't actually tell me as a user anything I need to know.
What might move the discussion forward more would be (i) critical analysis of different kinds of controls in terms of what font-selection scenarios they would or wouldn't be useful for, or (ii) what scenarios might require what manipulation of what kinds of font variables.
For instance, the discussion of pads points out the obvious, that two variables can be controlled at once. It assumes that for fonts with two or more axes a pad will be beneficial because it "avoid[s] an overload of UI elements and give[s] a designer better visibility." But this overlooks a question of whether or not it makes sense to manipulate the pair of axes together. For example, when would it be useful to manipulate, say, x-height and serifness at the same time, or contrast and optical size? Or would it ever be useful? If you think about cases of successful pad-like or 2D controls, you discover that they are successful because they combine variables that make sense to manipulate together.
Probably the most widely-used and successful 2D controls are colour pickers that manipulate luminance and saturation at the same time, or hue and saturation. Usually the 2D control is combined with a slider for the 3rd dimension: hence luminance-saturation + hue, or hue-saturation + luminance, or hue-luminance + saturation. They are successful because the dimensions they manipulate are so closely related and pertain to a single concept in the user's mind: colour.
Another 2D control that is fairly common is the level-curves control used in image editing apps. The concepts involved are more abstract, and therefore the level-curves actually have a fairly significant learning curve (pun intended). To the extent these controls are successful, it is because the problem to solve can only be controlled in two dimensions: the need is to set level adjustments for pixels of various luminance levels, spanning the complete range of possible luminance levels -- so a continuous range of input luminance levels needs to be associated with an adjustment value for each.
The simpler counterpart to the level-curves control are the levels controls, comprised of a histogram visualization with level-adjustment sliders for brights, darks and midtones. The problem is simplified to three inputs and simpler controls -- three sliders -- are used. This is similar to audio equalizers, in which the continuous audio-frequency range is divided into (say) five sub-ranges, and a level-adjustment slider is provided for each range.
With those comparisons in mind, rather than creating a 2D pad that can manipulate any arbitrary combination of two axes, as in TypeShift, I think it would be much more helpful to explore whether there are any combinations of possible font axes that would make sense to manipulate together because users intuitively think of them as being closely related, as in the case of colour pickers. Or whether there are situations in which it will make sense for a user to set font values in relationship to some continuous range of inputs values, as in the case of level-curves controls; or a simpler version of that with the input values grouped into a small number of ranges, as with levels and equalizer controls?
Note with regard to the latter that optical size is like this: text size is a continuous ranges of inputs, and the designer chooses adjustment levels to contrast, x-height, etc. corresponding to each input. But this is being selected at design time, so that at usage time the selection can generally be automated and doesn't require any UI. This brings two questions to mind:
- What font variables can be automated, based on what inputs and in what scenarios?
Multiple axes present a risk of exposing the user to choice overload. How can we limit the choices we present to the things most valuable for the user to control. What are the opportunities to provide better typography automatically, without requiring users to understand more concepts and make more choices?
And, going in the opposite direction from simplicity...
- Are there any scenarios in which a levels or level-curves kind of UI would be useful?
E.g., one could imagine a font that doesn't have an optical size axis, but does have contrast, x-height, etc. axes, and a UI is provided with a set of level-curves controls that allows the user to determine what contrast, etc. setting gets used at each text size -- i.e., designing their own customized optical-size meta-axis using primitive axes in the font?
Summarizing, if we want to move discussion of UI for variable fonts forward, I think we need to move beyond simple surveys of control types and dive into the deeper waters of how typography works, and how good typographic results can best be achieved by a combination of users interacting with typographic options and software making good choices on their behalf.