refactor: add default_font, change font api

[nuzzles]

Added

• There is now a default_font feature that uses the same FiraMono-subset.ttf font used in the bevy/default_font feature.

Changed

• The font API has changed significantly. Please visit examples/text for further usage. This is to prepare for additional text features such as linebreak behavior, bounded text, and text justification.
  • VelloText has been renamed to VelloTextSection.
  • VelloText.content has been renamed to VelloText.value.
  • There is now a VelloTextStyle struct and it is a required field of VelloText.
  • VelloFont has been removed from VelloTextBundle and moved into VelloTextStyle.

[DJMcNab]

We need to make sure we're handling the licensing properly.

Can we ask the Bevy project to make a crate containing just the font file, so that the usages can be properly shared?

[DJMcNab]

What's the license for this file?

[nuzzles]

OFL 1.1

[DJMcNab]

If you are using both this crate with default_font and bevy/default_font, does your binary include both?

I do see that the file is relatively small, so it's probably fine.

[nuzzles]

We aren't currently using bevy/default_font, not until bevyengine/bevy#14406 is merged at least.

[nuzzles]

We're good - see

bevyengine/bevy#14406

We recently submitted a PR to expose the font data under current licensing. Which is approved, waiting merge.

So we will switch to that as soon as we can.

[DJMcNab]

I don't agree with @alice-i-cecile's reading of the OFL in bevyengine/bevy#8445. According to their FAQ:

The only situation in which an OFL font can be distributed without the text of the OFL (either in a separate file or in font metadata), is when a font is embedded in a document or bundled within a program. In the case of metadata included within a font, it is legally sufficient to include only a link to the text of the OFL on https://openfontlicense.org/, but we strongly recommend against this. Most modern font formats include metadata fields that will accept the full OFL text, and full inclusion increases the likelihood that users will understand and properly apply the license.

I can't find the license text within the font file (at least using fc-query), and this use case (hosted on GitHub) is not "bundled within a program" (even though it will be once the program is built).
Even if Bevy has decided it's OK for them, if we're distributing this file, I strongly want us to make it clear that it's under the OFL.

So we should either just remove this file and only use the capability from that PR, or add the OFL.

[nuzzles]

I don't agree with @alice-i-cecile's reading of the OFL in bevyengine/bevy#8445. According to their FAQ:

The only situation in which an OFL font can be distributed without the text of the OFL (either in a separate file or in font metadata), is when a font is embedded in a document or bundled within a program. In the case of metadata included within a font, it is legally sufficient to include only a link to the text of the OFL on https://openfontlicense.org/, but we strongly recommend against this. Most modern font formats include metadata fields that will accept the full OFL text, and full inclusion increases the likelihood that users will understand and properly apply the license.

I can't find the license text within the font file (at least using fc-query), and this use case (hosted on GitHub) is not "bundled within a program" (even though it will be once the program is built). Even if Bevy has decided it's OK for them, if we're distributing this file, I strongly want us to make it clear that it's under the OFL.

So we should either just remove this file and only use the capability from that PR, or add the OFL.

I always planned on switching with the data from the PR, however I am not opposed to adding the OFL sooner until we can do that. I'd gladly accept a PR to add the OFL.