From 8c125d28fd9aa2e1b7de5bfe9d4f0abfd37ddae8 Mon Sep 17 00:00:00 2001 From: Bruce Mitchener Date: Fri, 9 Feb 2024 16:43:12 +0700 Subject: [PATCH] Fix typos. --- doc/pathseg.md | 2 +- doc/roadmap_2023.md | 4 ++-- examples/scenes/src/lib.rs | 2 +- examples/with_bevy/src/main.rs | 2 +- src/scene.rs | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/doc/pathseg.md b/doc/pathseg.md index fefde03d..4d4e2545 100644 --- a/doc/pathseg.md +++ b/doc/pathseg.md @@ -42,7 +42,7 @@ In the previous encoding, every path segment was encoded independently; the segm This encoding fixes that. Bit 2 of the tag byte indicates whether the segment is the last one in the subpath. If it is set, then the size encompasses all the points in the segment. If not, then it is short one, which leaves the offset for the next segment pointing at the last point in this one. -There is a relatively straightforward state maching to convert the usual moveto/lineto representation to this one. In short, the point for the moveto is encoded, a moveto or closepath sets the end bit for the previously encoded segment (if any), and the end bit is also set for the last segment in the path. Certain cases, such as a lone moveto, must be avoided. +There is a relatively straightforward state machine to convert the usual moveto/lineto representation to this one. In short, the point for the moveto is encoded, a moveto or closepath sets the end bit for the previously encoded segment (if any), and the end bit is also set for the last segment in the path. Certain cases, such as a lone moveto, must be avoided. ### Bit magic diff --git a/doc/roadmap_2023.md b/doc/roadmap_2023.md index 64cc7210..07a47f4f 100644 --- a/doc/roadmap_2023.md +++ b/doc/roadmap_2023.md @@ -20,7 +20,7 @@ This roadmap is in roughly chronological in order of when we expect to complete In addition, there are a few optional aspects to the roadmap, which will be implemented if there is demand from users or motivation from contributors: -* Native renderering back-ends, to reduce the overhead of WebGPU, especially runtime shader compilation. +* Native rendering back-ends, to reduce the overhead of WebGPU, especially runtime shader compilation. * A solution to conflation artifacts, to improve rendering quality for some classes of vector art. * Subpixel RGB rendering, to improve rendering quality on low-dpi LCD screens. * High Dynamic Range (HDR) rendering, to exploit capabilities of new displays. @@ -111,7 +111,7 @@ Taking that idea to the next step, we can make the scene encoding format part of Another potential reason to make the encoding part of the interface is so assets can be stored in encoded form, saving the cost of re-encoding. Our vector path encoding is *good,* as it's been carefully designed to minimize both the cost of generating it CPU-side, and consuming it GPU-side. One data point to support that is that our encoding of the 14MB paris-30k SVG file (as included in [Forma]) is about 12MB. And that's with 32 bit coordinates. For pre-encoded assets (or other special cases like font glyphs), it makes sense to use 16 bit coordinates instead, for about a 2x additional saving. -Thus, making the encoding part of the public, documented interface could open up some interesting possibilites. Obviously it's also too early to freeze the format, as we'll want to continue to iterate it to make it more efficient and add more capabilities, but likely a "semi-stable" approach, perhaps versioned stable releases, could work well. +Thus, making the encoding part of the public, documented interface could open up some interesting possibilities. Obviously it's also too early to freeze the format, as we'll want to continue to iterate it to make it more efficient and add more capabilities, but likely a "semi-stable" approach, perhaps versioned stable releases, could work well. With [vello#239] we already expose a good chunk of the encoding, and encourage people to experiment with that as we decide what to stabilize and how. diff --git a/examples/scenes/src/lib.rs b/examples/scenes/src/lib.rs index cb27171c..52691081 100644 --- a/examples/scenes/src/lib.rs +++ b/examples/scenes/src/lib.rs @@ -69,7 +69,7 @@ pub struct Arguments { #[arg(help_heading = "Render Parameters")] #[arg(long, global(false), value_parser = parse_color)] /// The base color applied as the blend background to the rasterizer. - /// Format is CSS style hexidecimal (#RGB, #RGBA, #RRGGBB, #RRGGBBAA) or + /// Format is CSS style hexadecimal (#RGB, #RGBA, #RRGGBB, #RRGGBBAA) or /// an SVG color name such as "aliceblue" pub base_color: Option, #[clap(subcommand)] diff --git a/examples/with_bevy/src/main.rs b/examples/with_bevy/src/main.rs index 04234cea..00004c59 100644 --- a/examples/with_bevy/src/main.rs +++ b/examples/with_bevy/src/main.rs @@ -107,7 +107,7 @@ struct MainPassCube; pub struct VelloTarget(Handle); #[derive(Component)] -// In the future, this will probably connect to the bevy heirarchy with an Affine component +// In the future, this will probably connect to the bevy hierarchy with an Affine component pub struct VelloFragment(SceneFragment); #[derive(Component)] diff --git a/src/scene.rs b/src/scene.rs index 86ebe975..5f45772c 100644 --- a/src/scene.rs +++ b/src/scene.rs @@ -88,7 +88,7 @@ impl<'a> SceneBuilder<'a> { Self { scene } } - /// Pushes a new layer bound by the specifed shape and composed with + /// Pushes a new layer bound by the specified shape and composed with /// previous layers using the specified blend mode. pub fn push_layer( &mut self,