`EditText` supports two different forms of leading:
1. Font-provided leading, specified relative to the EM square and scaled with font size
2. User-specificed leading, specified in pixels
Notably, the former appears to apply to the first line in the text and pushes it down. This showed up in the `edittext_font_size` test, and according to that test result the leading is rounded *up* to the nearest pixel, plus one.
That last bit seems possibly wrong and is subject to further change, but it matches the tests at multiple scales.
Certain text routines calculate text on the pixel grid, despite the fact that Flash ordinarily works in twips. There is probably a reason for this - my guess is to keep text wrapping stable across multiple pixel densities (e.g. low-res screens plus high-res print).
This fixes spaces at the start of text spans not being rendered, but also breaks center-align.
I also broke the font tests, so I had to rewrite them, which makes me question their value.
These tests depend on the particulars of our default device font, Noto Sans. If this test proves to be fragile we may need to create a testing font with a locked width and kerning table...
This involves a new struct called a `FontDescriptor` which is generated whenever a font is registered and used to index the font in the library. When a font is requested, it goes through the descriptor system to get found.
Embed an SWF version of Noto Sans (core/assets/*) into the player.
The player will load this font and use it to render device text.
This is a quicky implementation to get dynamic device text
rendering.
David Wendt