Bullets are implemented by rendering U+2022 as if it were normal text, but always placed 18px from the left of the line. This appears to be sort of what Flash does.
This also replaces the `edittext_html_defaults` test with a more robust test that checks the default format and global format of SWF-based, text, and HTML test vectors.
It *does*, however, respect `<sbr>` (which does the exact same thing), as well as `\n` (which makes absolutely no sense in HTML, normally that would get stripped out).
This implementation has a few bugs which appear to have something to do with alignment. It's not only justify, but justify is the only test that's flagged as failing.
If you look at the margins test, you'll see what I mean: right-aligned and justified text doesn't quite make it to the right edge of the box even though it should. I'm not sure why.
This also restricts text rounding further: `measure` now only rounds when wrapping text, since Flash Player appears to account for fractional pixels in all other cases.
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 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.
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.
Right margins: Simple enough, we just need to subtract the right margin from the bounds when we calculate our alignment adjustment.
Trailing spaces: This is very tricky as we effectively have to remeasure the last box in the line when fixing it up. This also means LayoutContext has to hold the text itself so we can remeasure again...
Lines wider than bounds: If word wrap is disabled it is possible for a line to exceed the bounds of the box. In this case it will be left-aligned. Effectively, the align adjustment is clamped to positive values and we do that here too.
This doesn't work right yet because the resulting width doesn't apply correctly to the field. This is because `EditText`'s `_width` and `_height` change it's intrinsic bounds rather than it's X and Y scale (like it would with a button or a movie clip).
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 prevents a bounds-check panic when we inevitably try to slice an array like `[300..2]` or something like that.
We also skip rendering the space that we're turning into a newline to avoid it popping up on the next line by accident.
`max_length` isn't a geometrical width, despite the fact that the type system didn't prevent me from making erroneous conversions. It's actually just a text length limit, which we won't be dealing with for some time.
When first instantiated, we use the static bounds; however, further relayouts grab `local_bounds` and calculate a width from that. `EditText` works almost identically to any other display object, with the exception that device fonts do not render if the transform is not an axis-aligned bounding box (and it doesn't respect scale). We don't have to worry about that for now.
This is surprisingly difficult because of how Flash handles these properties: they are cached at the start of a new line (explicit or flown) and then used for all spans that intersect with that line. Ergo, `LayoutContext` needs to keep track of all the boxes we generate within the line and the span that ultimately is going to provide margins for it.
And yet, at the same time, we also have to precalculate the effects of these margins when flowing text so that we know how much space we have to play with. This needs to be calculated the same at the start of the line as it is at the end. This is why `LayoutContext` is a separate type: it handles all the state tracking and crap that has to be done when splitting text into spans, paragraphs, and lines all at the same time.
Fortunately, this design will make it easier to implement other features like text alignment where we couldn't even begin to calculate everything in one pass.
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.
"Mixing" is defined as `Option.or`ing all the properties in the new text format with the old one. Not specifying a text format in the new default will result in the field retaining it's old properties.
This yields nodes as `Step`s. This allows keeping track of the structure of the tree as you walk through descendents, as each element will be yielded twice: both as a `Step::In` *and* as a `Step::Out`. Non-element nodes will be yielded once as a `Step::Around`.
I'm adding `walk` iteration specifically to avoid having to write certain methods recursively. Existing recursive callers of `children` should probably be updated to `walk` the tree and maintain a separate `Vec` stack.
This also necessitated the addition of code to:
* Ensure span breaks exist at both sides of the text boundary, without creating degenerate (length-0) spans
* Consolidate spans with matching text formats
* Shorten or lengthen the total list of text spans to match the backing string
* Ensure at least one text span exists at all times
This still has some minor to-dos: for example, it relies on the default `TextSpan` formatting, which probably should be replaced with actually accepting or storing a default format to be used when constructing new text spans.
Despite having HTML and CSS rendering capabilities, the Flash text field actually does not use HTML as it's internal representation. Instead, the text-span format implied by `getTextFormat` and `setTextFormat` is used to drive layout. You can see this by watching what happens to `htmlText`, *especially* when you add and remove stylesheets.
The `LayoutBox` machinery will be adapted to consume text spans in a future commit. This would make the entire rendering pipeline: HTML/CSS -> Text Spans -> Layout Boxes -> Render commands.
This makes the implementation of rectangle union (`Add`/`AddAssign`) far easier as we just compute the min and max of the offset and extent coordinates. It also makes the conversion into and from `swf::Rectangle` easier as it's now effectively a generic version of that datatype.
On the other hand, `width`, `height`, and `size` now have to be calculated, and require `T` to be self-`Sub`. I'm not sure if this is that much of a problem or not.
David Wendt