Lots of prose fixes

Change-Id: Ie1b4b17fa6c28d15b92dc620c11dcf89d7933501
No-Try: true
Docs-Preview: https://skia.org/?cl=415901
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/415901
Reviewed-by: Mouad Debbar <mdebbar@google.com>
Reviewed-by: Yegor Jbanov <yjbanov@google.com>

site/docs/dev/design/text_c2d.md

@@ -1,7 +1,7 @@
 Canvas2D extensions for Shaped Text
 =============
 [Shaped Text](text_shaper.md) is a proposal for exposing the Browser's text shaping engine. It takes in
-a block of (annoated) text, and returns the low-level information need to correctly measure, hit-test,
+a block of (annoated) text, and returns the low-level information needed to correctly measure, hit-test,
 and draw the text as positioned glyphs. This processing step is needed whenever text is measured or
 drawn in the browser, and this processing can be complex and time consuming. The output of this processing
 is, however, simple and can be rendered quite efficiently. It is runs (tied to a specific Typeface and size)

site/docs/dev/design/text_overview.md

@@ -11,7 +11,7 @@ Native (desktop, mobile) frameworks combine these primitives with common renderi
 - colors, gradients, patterns
 - blending and colorspaces
 
-One primitive in particular stands out: **Text**. It can be drawn with the same common constructs as rects and paths, but it has another component unrelated to actual drawing, a 'processing' step that is surprisingly complex and expensive: **Shaping**. The native frameworks recognized this, and offer a separate set APIs just around this:
+One primitive in particular stands out: **Text**. It can be drawn with the same common constructs as rects and paths, but it has another component unrelated to actual drawing, a 'processing' step that is surprisingly complex and expensive: **Shaping**. The native frameworks recognized this, and offer a separate set of APIs just around this:
 - CoreGraphics --> CoreText
 - Direct2D/X --> DirectWrite
 - Skia --> SkShaper
@@ -30,7 +30,7 @@ Part of this complexity lies in language and alphabets themselves, and part is d
 This simple sentence is illustrative of some of the richness (i.e. complexity) of displaying text. Some examples
 - The 'ffi" in office (or possibly just the "fi") **could** be drawn with a specialized form called a [ligature](https://en.wikipedia.org/wiki/Ligature_(writing)).
 - The "ü" could have been drawn as a single shape, or it could have been drawn by separately drawing "u" followed by drawing the umlaut (¨) on top.
-- The third word may not be reprsentable in the same font as the other words, so a different font may have been need.
+- The third word may not be reprsentable in the same font as the other words, so a different font may have been needed.
 
 This example in no way attempts to be complete or exhaustive, but it suggests the processing needed to go from just the 'letters' in a sentence, to the actual 'shapes' that must be found or composed from various fonts to finally be able to draw it.
 
@@ -50,7 +50,7 @@ All of these attributes (and more) go into the browser's search for the best mat
 
 We define a Typeface to be a coherent collection of shapes in a given typograph style (including any variation settings). Typically a typeface is stored in a single file or blob (e.g. an OpenType file).
 
-Along with a single Typeface we define the individual *shapes* or images in the typeface as **Glyphs**. Glyphs represent the smallest independent drawing element within a typeface. By convention, glyphs are identify by an *index*, ranging from 0 to however many are in a particular typeface.
+Along with a single Typeface we define the individual *shapes* or images in the typeface as **Glyphs**. Glyphs represent the smallest independent drawing element within a typeface. By convention, glyphs are identified by an *index*, ranging from 0 to however many are in a particular typeface.
 
 Determining what glyphs, in what order and positions, are needed to represent a set of letters, is the heart of **Shaping**, and it is this process, and resulting typefaces + positioned glyphs, that we propose exposing to Web Apps.
 
@@ -62,7 +62,10 @@ The core [Shaping APIs](text_shaper.md) are detailed here.
 
 Assocated [Canvas2D extensions](text_c2d.md) are detailed here.
 
-Note: it is an explicit goal to **not** tie Shaping or its results to Canvas2D. We envision multiple scenarios where a framework or app will want to shape text, but not need a Canvas2D context (e.g. it may draw using WebGL or WebGPU, or with a bespoke renderer).
+Note: it is an explicit goal to **not** tie Shaping or its results to Canvas2D. We envision multiple scenarios where a framework or app will want to shape text, but not need a Canvas2D context .
+- drawn using WebGL or WebGPU
+- drawn using DOM (but utilizing line-breaking and metrics results)
+- drawn using a bespoke (i.e. wasm) renderer
 
 We are also proposing a lower level interface, one that just addresses exposing [unicode properties](uni_characterize.md).
 

site/docs/dev/design/text_shaper.md

@@ -8,10 +8,10 @@ A related explainer focuses on suggested [extensions to canvas2d](text_c2d.md) t
 
 ## Target audience
 
-We want to target web apps that have already chosen to rendering their content either in canvas2d,
+We want to target web apps that have already chosen to render their content either in canvas2d,
 or webgl, or in some other fashion, but still want access to the powerful international text shaping
 and layout services inherent in the browser. In the case of canvas2d, which already has some facilities
-for text, we want to address the missing services and low-level results needed for creating interative
+for text, we want to address the missing services and low-level results needed for creating interactive
 text editing or high-perferformance rendering and animations.
 
 Rather than 'extend' the existing canvas2d fillText() method, we propose an explicit 2-step model:
@@ -22,7 +22,7 @@ JavaScript frameworks are another target audience. This proposal is heavily infl
 APIs on native platforms (desktop and mobile) and seeks to deliver similar control and performance.
 Thus it may be quite natural that sophiticated frameworks build upon these interfaces, providing more
 'friendly', constrained versions of the features. This is expected, since multiple 'high level' models
-for text are valid, each with its own opinions and tradeoffs. The goal of this API is to be expose the
+for text are valid, each with its own opinions and tradeoffs. The goal of this API is to expose the
 core services and results, and leave the opinionated layers to the JavaScript community.
 
 ### Principles