Re-added original alt text

src/ch04-01-what-is-ownership.md

@@ -265,7 +265,6 @@ the memory that holds the contents of the string, a length, and a capacity.
 This group of data is stored on the stack. On the right is the memory on the
 heap that holds the contents.
 
-<!-- <img alt="String in memory" src="img/trpl04-01.svg" class="center" style="width: 50%;" /> -->
 {{#include img/trpl04-01.svg}}
 
 <span class="caption">Figure 4-1: Representation in memory of a `String`
@@ -282,7 +281,6 @@ pointer, the length, and the capacity that are on the stack. We do not copy the
 data on the heap that the pointer refers to. In other words, the data
 representation in memory looks like Figure 4-2.
 
-<!-- <img alt="s1 and s2 pointing to the same value" src="img/trpl04-02.svg" class="center" style="width: 50%;" /> -->
 {{#include img/trpl04-02.svg}}
 
 <span class="caption">Figure 4-2: Representation in memory of the variable `s2`
@@ -293,7 +291,6 @@ look like if Rust instead copied the heap data as well. If Rust did this, the
 operation `s2 = s1` could be very expensive in terms of runtime performance if
 the data on the heap were large.
 
-<!-- <img alt="s1 and s2 to two places" src="img/trpl04-03.svg" class="center" style="width: 50%;" /> -->
 {{#include img/trpl04-03.svg}}
 
 <span class="caption">Figure 4-3: Another possibility for what `s2 = s1` might
@@ -330,7 +327,6 @@ because Rust also invalidates the first variable, instead of calling it a
 shallow copy, it’s known as a *move*. In this example, we would say that
 `s1` was *moved* into `s2`. So what actually happens is shown in Figure 4-4.
 
-<!-- <img alt="s1 moved to s2" src="img/trpl04-04.svg" class="center" style="width: 50%;" /> -->
 {{#include img/trpl04-04.svg}}
 
 <span class="caption">Figure 4-4: Representation in memory after `s1` has been

src/ch04-02-references-and-borrowing.md

@@ -25,7 +25,6 @@ function return value is gone. Second, note that we pass `&s1` into
 `String`. These ampersands represent *references*, and they allow you to refer
 to some value without taking ownership of it. Figure 4-5 depicts this concept.
 
-<!-- <img alt="&amp;String s pointing at String s1" src="img/trpl04-05.svg" class="center" /> -->
 {{#include img/trpl04-05.svg}}
 
 <span class="caption">Figure 4-5: A diagram of `&String s` pointing at `String

src/ch04-03-slices.md

@@ -123,7 +123,6 @@ byte at index 6 of `s` with a length value of 5.
 
 Figure 4-6 shows this in a diagram.
 
-<!-- <img alt="world containing a pointer to the byte at index 6 of String s and a length 5" src="img/trpl04-06.svg" class="center" style="width: 50%;" /> -->
 {{#include img/trpl04-06.svg}}
 
 <span class="caption">Figure 4-6: String slice referring to part of a

src/ch15-01-box.md

@@ -178,7 +178,6 @@ type needs, the compiler looks at the variants, starting with the `Cons`
 variant. The `Cons` variant holds a value of type `i32` and a value of type
 `List`, and this process continues infinitely, as shown in Figure 15-1.
 
-<!-- <img alt="An infinite Cons list" src="img/trpl15-01.svg" class="center" style="width: 50%;" /> -->
 {{#include img/trpl15-01.svg}}
 
 <span class="caption">Figure 15-1: An infinite `List` consisting of infinite
@@ -233,7 +232,6 @@ broken the infinite, recursive chain, so the compiler can figure out the size
 it needs to store a `List` value. Figure 15-2 shows what the `Cons` variant
 looks like now.
 
-<!-- <img alt="A finite Cons list" src="img/trpl15-02.svg" class="center" /> -->
 {{#include img/trpl15-02.svg}}
 
 <span class="caption">Figure 15-2: A `List` that is not infinitely sized

src/ch15-04-rc.md

@@ -35,7 +35,6 @@ Let’s return to our cons list example in Listing 15-5. Recall that we defined
 it using `Box<T>`. This time, we’ll create two lists that both share ownership
 of a third list. Conceptually, this looks similar to Figure 15-3:
 
-<!-- <img alt="Two lists that share ownership of a third list" src="img/trpl15-03.svg" class="center" /> -->
 {{#include img/trpl15-03.svg}}
 
 <span class="caption">Figure 15-3: Two lists, `b` and `c`, sharing ownership of

src/ch15-06-reference-cycles.md

@@ -75,7 +75,6 @@ well. This instance’s memory can’t be dropped either, because the other
 remain uncollected forever. To visualize this reference cycle, we’ve created a
 diagram in Figure 15-4.
 
-<!-- <img alt="Reference cycle of lists" src="img/trpl15-04.svg" class="center" /> -->
 {{#include img/trpl15-04.svg}}
 
 <span class="caption">Figure 15-4: A reference cycle of lists `a` and `b`