There are several problems, first off:
1. I'm not entirely sure what I'm supposed to be changing on the text field when someone writes `html`.
2. We're using the XML parser for HTML (both `htmlText` and SWF tag parsing) which causes problems. Notably, `<br>` issues an AVM1 error (!!!) because the XML parser doesn't like unclosed tags.
3. Reading `htmlText` should not return the same HTML tree (at least, not until we implement stylesheets). It should instead regenerate an HTML tree from text spans.
This test is currently inaccurate by up to 5 pixels, this is due to some behavior with really, really wide tabstops and word breaks that I don't entirely get yet.
This was verified by visual comparison with Flash Player; lines of text appear to be shifted by half-pixels, while the script output is always still rounded down.
This is an approximate text with a 1-pixel tolerance because our height is currently off by one and I cannot explain why. Previous attempts to fix the bug have resulted in cascading errors that resulted in off-by-one errors in the opposite direction. This is still better than nothing and I need to check other tests in.
Flash has a weird bug where it will NOT trim trailing spaces off of the metrics reported to users if the text is left-aligned. We replicate this here so that tests pass.
The `Default` bounds are NOT safe to union against if they were uninitialized. Doing so will force any resulting layout box to enclose `(0,0)`, which can throw off certain layout calculations. Instead, we use `None` to signal an uninitialized box.
`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).
I don't know why, but this is necessary for the "NEW STUFF" box on homestarrunner.com's toons menu to position correctly. SOMEWHERE, we are performing some kind of operation that adjusts one of the two, but not the other, and I can't find out what.
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.
David Wendt