Normal quotes

67-05.md

@@ -4,11 +4,11 @@
 
 #### Implementation Notes {#Heading9}
 
-Finally, a few notes on Listing 67.1. First, you’ll notice that although
+Finally, a few notes on Listing 67.1. First, you'll notice that although
 we clip all polygons to the view frustum in worldspace, we nonetheless
 later clamp them to valid screen coordinates before adding them to the
 edge list. This catches any cases where arithmetic imprecision results
-in clipped polygon vertices that are a bit outside the frustum. I’ve
+in clipped polygon vertices that are a bit outside the frustum. I've
 only found such imprecision to be significant at very small z distances,
 so clamping would probably be unnecessary if there were a near clip
 plane, and might not even be needed in Listing 67.1, because of the
@@ -20,7 +20,7 @@ percent of the time leads to sporadic and hard-to-debug errors.
 There is no separate routine to clear the background in Listing 67.1.
 Instead, a special background surface at an effectively infinite
 distance is added, so whenever no polygons are active the background
-color is drawn. If desired, it’s a simple matter to flag the background
+color is drawn. If desired, it's a simple matter to flag the background
 surface and draw the background specially. For example, the background
 could be drawn as a starfield or a cloudy sky.
 
@@ -31,7 +31,7 @@ for the latter case: Storage for the maximum number of vertices per
 polygon must be allocated in the polygon structures. In a fully polished
 implementation, vertices would be linked together or pointed to, and
 would be dynamically allocated from a vertex pool, so each polygon
-wouldn’t have to contain enough space for the maximum possible number of
+wouldn't have to contain enough space for the maximum possible number of
 vertices.
 
 Each surface has a field named **state**, which is incremented when a
@@ -44,9 +44,9 @@ coordinates from floating point to fixed point. Due to this conversion,
 it is possible, although rare, for a polygon that is viewed nearly
 edge-on to have a trailing edge that occurs slightly *before* the
 corresponding leading edge, and the span-generation code will behave
-badly if it tries to emit a span for a surface that hasn’t yet started.
+badly if it tries to emit a span for a surface that hasn't yet started.
 It would help performance if this sort of fix-up could be eliminated by
-careful arithmetic, but I haven’t yet found a way to do so for
+careful arithmetic, but I haven't yet found a way to do so for
 1/z-sorted spans.
 
 Lastly, as discussed in Chapter 66, Listing 67.1 uses the gradients for