Add text_style + styled_text crates (CSS-like resolution + document blocks)

[waywardmonkeys]

• Add text_style: a no_std + alloc style vocabulary for text (inline + paragraph declarations with Specified semantics).
• Add text_style_resolve: engine layer for specified→computed resolution, including OpenType settings parsing and structured errors.
• Add styled_text: span application and a lightweight block/document model built on attributed_text + text_style, yielding resolved run iterators.
• Add styled_text_parley: Parley backend that lowers resolved runs into parley::StyleProperty calls to build parley::Layout.

[waywardmonkeys]

There's at least one big problem with this ... text-style is already a taken name, so text_style can't be the name we use.

This is a great bike shedding opportunity for people (the name).

[waywardmonkeys]

This also doesn't yet lower to Parley and have an example ... coming soon. Other things too.

[waywardmonkeys]

I will also peel off the attributed_text change to a separate PR and land it separately ...

[dfrg]

I'm still reading through this but my general feeling is that we'll want a simpler vocabulary crate that only provides the fundamental resolved property types. Things like Tag, FontWeight, Language*, FontVariation, FontFeature, GenericFamily, WordBreak, etc. And maybe some parsing for these. I'm thinking of the color crate as an example.

* A zero alloc language type the only captures language, script and region subtags would be nice. We don't really care about the rest.

[nicoburns]

I'm still reading through this but my general feeling is that we'll want a simpler vocabulary crate that only provides the fundamental resolved property types. Things like Tag, FontWeight, Language*, FontVariation, FontFeature, GenericFamily, WordBreak, etc. And maybe some parsing for these. I'm thinking of the color crate as an example.

• A zero alloc language type the only captures language, script and region subtags would be nice. We don't really care about the rest.

I agree with this. And would say that I think it would be useful to have the "computed" styles (and likely a few other complementary low-level types like Tag) in a low-level type-only vocabulary crate that can be shared by everything which consumes parley (and parley/fontique themselves). Whereas I would expect the "specified" styles to be coupled with the "style systems" (of whatever variety) that sit on top.

[waywardmonkeys]

I'll be pushing a proposal to address some of this shortly... and then I'll be passing out. :)

[waywardmonkeys]

@dfrg I think the last set of changes adding text_primitives (yay for more bike shedding opportunities!) may help ...

If so, I could separate that out from this PR and submit a new PR that contains just that and the changes to have Parley / Fontique use it. (After I sleep...)

[waywardmonkeys]

(It would still need some of the code that we have for some of these types in the existing stuff ... like parse functions, display impls, and bytemuck stuff. But that's easy to bring over.)

[dfrg]

If so, I could separate that out from this PR

Yes, this looks much better to me and I think it makes sense to split it out into a separate PR so we can bikeshed a bit on name and get it merged.

Thanks!

[waywardmonkeys]

Splitting a very small font_stack from parley would be useful to me as well.

[dfrg]

Splitting a very small font_stack from parley would be useful to me as well.

Adding this to text_primitives (with the name FontFamily to match CSS) makes sense to me. We just need to figure out how to handle names in a way that makes allocation optional.

[nicoburns]

Splitting a very small font_stack from parley would be useful to me as well.

+1 for this. I think basically everything that's a computed style in Parley makes sense here (I'm assuming that where this is headed is that Parley will end up with less style resolution than it currently has (basically only things that can't be computed ahead of time becuase they depend on the font metrics or font fallback).

Adding this to text_primitives (with the name FontFamily to match CSS) makes sense to me. We just need to figure out how to handle names in a way that makes allocation optional.

Some kind Arc-based solution might also make sense. I think a lot of consumers will be converting into this type from some other similar type, and being able to cache that conversion would make a lot of sense. Especially because even without a single layout having a lot of spans with identical font-family specification is a common case.

In my case my source will be https://docs.rs/stylo/latest/style/values/computed/font/struct.FontFamilyList.html which is itself an Arc so I could probably have an Arc-> Arc lookup which I'd imagine would be quite cheap. Blitz currently is allocating a new Vec of Strings every time a font-family style is specified which isn't ideal. I haven't benchmarked how much of an impact that has.

[waywardmonkeys]

Another part of this has been pulled out and turned into #501.

[waywardmonkeys]

And the extraction of FontFamily (with improvements to parsing along the same lines as #501) is now in #502.