Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Experiment: styled_text crate #209

Draft
wants to merge 16 commits into
base: main
Choose a base branch
from
Draft

Experiment: styled_text crate #209

wants to merge 16 commits into from

Conversation

waywardmonkeys
Copy link
Contributor

This is an experimental PR that moves some stuff from fontique and parley into a new styled_text crate.

This crate would get a rich text / attributed text or that could go in another crate.

Both fontique and parley depend on this new crate, but it only depends on core_math and is fully no_std compatible.

Nearly all of this should be so general that it could be used by other text systems as well.

@waywardmonkeys waywardmonkeys requested a review from dfrg December 7, 2024 18:27
@waywardmonkeys
Copy link
Contributor Author

I see that the font config code in fontique does something that will need adjustment ... and there's plenty of stuff that would need to be cleaned up with imports and such ...

@waywardmonkeys
Tidy up GenericFamily a bit.
79ab65f 
Rename the file in `styled_text` so it matches what it contains.

Just re-export from fontique's root via styled_text rather than
via fontique::generic.
@waywardmonkeys
Impl bytemuck for GenericFamily.
7807707 
We then use that to get the max value for the GenericFamilyMap
in fontique.
@waywardmonkeys
Add README.md content and LICENSE-*
667561e
@waywardmonkeys
Copy link
Contributor Author

waywardmonkeys commented Dec 8, 2024 •
edited
Loading

Some things to resolve:

  • Should WhiteSpaceCollapse move into styled_text?
  • Should TextStyle move into styled_text?
  • Should StyleSet move into styled_text?
  • Fontique refers to Stretch, Style, and Weight, but Parley uses FontStretch, FontStyle, and FontWeight. We should choose one naming scheme and export it that way from styled_text and just use that.
  • It would be nice to have a better way to distinguish between styled_text::FontFeature and parley::style::FontFeature (the latter is based on swash for internal usage within parley).
  • Vendor the parse list code / API for FontFeature and FontVariation into styled_text and then use that from within Parley.
  • This doesn't yet handle inline boxes, although that'll be more at the RichText / RichTextBuilder level once that arrives.
  • There are still imports to clean up and harmonize.

@waywardmonkeys waywardmonkeys mentioned this pull request Dec 8, 2024
Merged
@waywardmonkeys
Move FontConfig conversion to styled_text
48294c6 
This also adds additional cases for the stretch conversion and
a note in the doc comments about where these values have come from.
@waywardmonkeys
Copy link
Contributor Author

I tink there's some interesting directions for this in the future as well.

Like FontSize should be an enum, not an f32 (at this level) so that ti can handle the various things that CSS Fonts 4 does.

This also could grow some easier ways to configure the various OpenType features rather than requiring knowing the details of what the tags are. (This too can be inspired by CSS Fonts 4.)

It could be pretty exciting, but we need to make the first steps ...

@nicoburns
Copy link
Contributor

This looks interesting, but I think we ought to do a more conservative Parley 0.3 release before we land this.

@waywardmonkeys
Copy link
Contributor Author

I think that right now, I've avoided any breaking changes in the API ... but I definitely plan to have some, like dealing with Weight vs FontWeight and friends. But those are easy... If there is agreement, this could easily land this week.

@waywardmonkeys
Copy link
Contributor Author

But I might also submit some of the breaking changes separately from this and then rebase this on top of them...

@nicoburns
Copy link
Contributor

I think that right now, I've avoided any breaking changes in the API ... but I definitely plan to have some, like dealing with Weight vs FontWeight and friends. But those are easy... If there is agreement, this could easily land this week.

I'm less concerned about breaking changes and more concerned about whether this crate structure makes sense. I think we ought to give ourselves more time to iterate and settle on a design rather than trying to immediately rush it into a release along with other changes that have been stewing for some time.

@waywardmonkeys waywardmonkeys mentioned this pull request Dec 9, 2024
Merged
waywardmonkeys added a commit to waywardmonkeys/parley that referenced this pull request Dec 9, 2024
@waywardmonkeys
Impl bytemuck traits for GenericFamily
79b3a70 
This can be used in the future as part of FFI work, but for now,
the `Contiguous` trait is used to provide a `MAX_VALUE` used by
`GenericFamilyMap`.

This is a backport of part of linebender#209 where the separation between
`GenericFamily` and `GenericFamilyMap` has grown to span crates.

The testing here borrows from (copies) what is done for similar
testing of `bytemuck` traits in the `color` crate.
waywardmonkeys added a commit to waywardmonkeys/parley that referenced this pull request Dec 9, 2024
@waywardmonkeys
Impl bytemuck traits for GenericFamily
9fa9bb1 
This can be used in the future as part of FFI work, but for now,
the `Contiguous` trait is used to provide a `MAX_VALUE` used by
`GenericFamilyMap`.

This is a backport of part of linebender#209 where the separation between
`GenericFamily` and `GenericFamilyMap` has grown to span crates.

The testing here borrows from (copies) what is done for similar
testing of `bytemuck` traits in the `color` crate.

These crates already depend on `bytemuck`, so this isn't a new
dependency. A decision is made here though to not use the `derive`
feature as when we move this type to a vocabulary crate, we will
want to avoid the `derive` feature there to avoid a dependency
on proc macros.
waywardmonkeys added a commit to waywardmonkeys/parley that referenced this pull request Dec 9, 2024
@waywardmonkeys
Impl bytemuck traits for GenericFamily
713ab68 
This can be used in the future as part of FFI work, but for now,
the `Contiguous` trait is used to provide a `MAX_VALUE` used by
`GenericFamilyMap`.

This is a backport of part of linebender#209 where the separation between
`GenericFamily` and `GenericFamilyMap` has grown to span crates.

The testing here borrows from (copies) what is done for similar
testing of `bytemuck` traits in the `color` crate.

These crates already depend on `bytemuck`, so this isn't a new
dependency. A decision is made here though to not use the `derive`
feature as when we move this type to a vocabulary crate, we will
want to avoid the `derive` feature there to avoid a dependency
on proc macros.
@waywardmonkeys waywardmonkeys mentioned this pull request Dec 9, 2024
Merged
waywardmonkeys added a commit to waywardmonkeys/parley that referenced this pull request Dec 9, 2024
@waywardmonkeys
fontique: Move creation of attributes from fontconfig
2a1bb86 
This exposes `from_fontconfig` functions on `FontStretch`, `FontStyle`,
and `FontWeight` rather than only defining them locally within the
fontconfig code.

This is in preparation for a change similar to linebender#209 where these types
and others get pulled into a shared vocabulary crate and this sort
of constructor helper would be useful to others.
@waywardmonkeys waywardmonkeys mentioned this pull request Dec 9, 2024
Merged
waywardmonkeys added a commit to waywardmonkeys/parley that referenced this pull request Dec 9, 2024
@waywardmonkeys
Impl bytemuck traits for GenericFamily
53ceac3 
This can be used in the future as part of FFI work, but for now,
the `Contiguous` trait is used to provide a `MAX_VALUE` used by
`GenericFamilyMap`.

This is a backport of part of linebender#209 where the separation between
`GenericFamily` and `GenericFamilyMap` has grown to span crates.

The testing here borrows from (copies) what is done for similar
testing of `bytemuck` traits in the `color` crate.

These crates already depend on `bytemuck`, so this isn't a new
dependency. A decision is made here though to not use the `derive`
feature as when we move this type to a vocabulary crate, we will
want to avoid the `derive` feature there to avoid a dependency
on proc macros.
waywardmonkeys added a commit to waywardmonkeys/parley that referenced this pull request Dec 9, 2024
@waywardmonkeys
Impl bytemuck traits for GenericFamily
d9dbfc5 
This can be used in the future as part of FFI work, but for now,
the `Contiguous` trait is used to provide a `MAX_VALUE` used by
`GenericFamilyMap`.

This is a backport of part of linebender#209 where the separation between
`GenericFamily` and `GenericFamilyMap` has grown to span crates.

The testing here borrows from (copies) what is done for similar
testing of `bytemuck` traits in the `color` crate.

These crates already depend on `bytemuck`, so this isn't a new
dependency. A decision is made here though to not use the `derive`
feature as when we move this type to a vocabulary crate, we will
want to avoid the `derive` feature there to avoid a dependency
on proc macros.
github-merge-queue bot pushed a commit that referenced this pull request Dec 9, 2024
@waywardmonkeys
Impl bytemuck traits for GenericFamily (#213)
1d9d344 
This can be used in the future as part of FFI work, but for now, the
`Contiguous` trait is used to provide a `MAX_VALUE` used by
`GenericFamilyMap`.

This is a backport of part of #209 where the separation between
`GenericFamily` and `GenericFamilyMap` has grown to span crates.

The testing here borrows from (copies) what is done for similar testing
of `bytemuck` traits in the `color` crate.

These crates already depend on `bytemuck`, so this isn't a new
dependency. A decision is made here though to not use the `derive`
feature as when we move this type to a vocabulary crate, we will want to
avoid the `derive` feature there to avoid a dependency on proc macros.
github-merge-queue bot pushed a commit that referenced this pull request Dec 9, 2024
@waywardmonkeys @DJMcNab
fontique: Move creation of attributes from fontconfig (#212)
0e851bb 
This exposes `from_fontconfig` functions on `FontStretch`, `FontStyle`,
and `FontWeight` rather than only defining them locally within the
fontconfig code.

This is in preparation for a change similar to #209 where these types
and others get pulled into a shared vocabulary crate and this sort of
constructor helper would be useful to others.

---------

Co-authored-by: Daniel McNab <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@dfrg dfrg Awaiting requested review from dfrg

At least 1 approving review is required to merge this pull request.

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@waywardmonkeys @nicoburns