Fix clippy::doc_lazy_continuation lints (#866)

Also, fixed a typo in the same text.

crates/usvg/src/text/mod.rs

@@ -196,9 +196,10 @@ impl std::fmt::Debug for FontResolver<'_> {
 }
 
 /// Convert a text into its paths. This is done in two steps:
-/// 1. We convert the text into glyphs and position them according to the rules specified in the
-/// SVG specifiation. While doing so, we also calculate the text bbox (which is not based on the
-/// outlines of a glyph, but instead the glyph metrics as well as decoration spans).
+/// 1. We convert the text into glyphs and position them according to the rules specified
+///    in the SVG specification. While doing so, we also calculate the text bbox (which
+///    is not based on the outlines of a glyph, but instead the glyph metrics as well
+///    as decoration spans).
 /// 2. We convert all of the positioned glyphs into outlines.
 pub(crate) fn convert(
     text: &mut Text,

crates/usvg/src/tree/text.rs

@@ -626,14 +626,14 @@ impl Text {
     /// This process is in general lossless and should lead to correct output, with
     /// two notable exceptions:
     /// 1. For glyphs based on the `SVG` table, only glyphs that are pure SVG 1.1/2.0
-    /// are supported. Glyphs that make use of features in the OpenType specification
-    /// that are not part of the original SVG specification are not supported.
+    ///    are supported. Glyphs that make use of features in the OpenType specification
+    ///    that are not part of the original SVG specification are not supported.
     /// 2. For glyphs based on the `COLR` table, there are a certain number of features
-    /// that are not (correctly) supported, such as conical
-    /// gradients, certain gradient transforms and some blend modes. But this shouldn't
-    /// cause any issues in 95% of the cases, as most of those are edge cases.
-    /// If the two above are not acceptable, then you will need to implement your own
-    /// glyph rendering logic based on the layouted glyphs (see the `layouted` method).
+    ///    that are not (correctly) supported, such as conical
+    ///    gradients, certain gradient transforms and some blend modes. But this shouldn't
+    ///    cause any issues in 95% of the cases, as most of those are edge cases.
+    ///    If the two above are not acceptable, then you will need to implement your own
+    ///    glyph rendering logic based on the layouted glyphs (see the `layouted` method).
     pub fn flattened(&self) -> &Group {
         &self.flattened
     }