Fix embedded_graphics code + typo in chapter 3

Compiles now

blog/content/edition-3/posts/03-screen-output/index.md

@@ -312,7 +312,7 @@ Fortunately, there is the nice `no_std`-compatible [`embedded-graphics`] crate,
 
 ```rust ,hl_lines=3
 // in kernel/src/framebuffer.rs
-use embedded_graphics::pixelcolor::Rgb888;
+use embedded_graphics::pixelcolor::{Rgb888, RgbColor};
 
 pub struct Display {
     framebuffer: FrameBuffer,
@@ -330,7 +330,12 @@ impl Display {
             (info.width, info.height)
         }
 
-        if let Ok((x @ 0..width, y @ 0..height)) = coordinates.try_into() {
+        let (x, y) = {
+            let c: (i32, i32) = coordinates.into();
+            (c.0 as usize, c.1 as usize)
+        };
+
+        if (0..width).contains(&x) && (0..height).contains(&y) {
             let color = Color { red: color.r(), green: color.g(), blue: color.b()};
             set_pixel_in(&mut self.framebuffer, Position { x, y }, color);
         }
@@ -363,7 +368,7 @@ impl embedded_graphics::draw_target::DrawTarget for Display {
 
 
 
-  draw shapes and pixels directly onto the framebuffer. That's fine and all, but how is one able to go from that to displaying text on the screen? Understanding this requires taking a deep dive into how characters are rendered behind the scenes.
+So far, we have drawn shapes and pixels directly onto the framebuffer. That's fine and all, but how is one able to go from that to displaying text on the screen? Understanding this requires taking a deep dive into how characters are rendered behind the scenes.
 
 When a key is pressed on the keyboard, it sends a character code to the CPU. It's the CPU's job at that point to then interpret the character code and match it with an image to draw on the screen. The image is then sent to either the GPU or the framebuffer (the latter in our case) to be drawn on the screen, and the user sees that image as a letter, number, CJK character, emoji, or whatever else he or she wanted to have displayed by pressing that key.