Corrected minor typos

Author: Ian Thomas

02-introduction.rst

@@ -219,7 +219,7 @@ Buffers
 +++++++
 
 The next question is thus where do those vertices comes from ? The idea of
-modern GL is that vertices are stored on the GPU and needs to be uploaded to
+modern GL is that vertices are stored on the GPU and need to be uploaded to
 the GPU before rendering. The way to do that is to build buffers onto the CPU
 and to send these buffers onto the GPU. If your data does not change, no need
 to upload them again. That is the big difference with the previous fixed

03-quickstart.rst

@@ -17,7 +17,7 @@ Preliminaries
 -------------------------------------------------------------------------------
 
 The main difficulty for newcomers in programming modern OpenGL is that it
-requires to underdtand a lot of different concepts at once and then, to perform
+requires to understand a lot of different concepts at once and then, to perform
 a lot of operations before rendering anything on screen. This complexity
 implies that there are many places where your code can be wrong, both at the
 conceptual and code level. To illustrate this difficulty, we'll program our
@@ -395,7 +395,7 @@ We now need to bind the buffer to the program, that is, for each attribute
 present in the vertex shader program, we need to tell OpenGL where to find the
 corresponding data (i.e. GPU buffer) and this requires some computations. More
 precisely, we need to tell the GPU how to read the buffer in order to bind each
-value to the relevant attribute. To do this, GPU needs to kow what is the
+value to the relevant attribute. To do this, GPU needs to know what is the
 stride between 2 consecutive element and what is the offset to read one
 attribute:
 
@@ -531,7 +531,7 @@ Varying color
    A colored quad using a per-vertex color.
 
 Until now, we have been using a constant color for the four vertices of our
-quad and the result is (unsuprinsingly) a boring uniform red or blue quad. We
+quad and the result is (unsurprisingly) a boring uniform red or blue quad. We
 can make a bit more interesting though by assigning different colors for each
 vertex and see how OpenGL will interpolate colors. Our new vertex shader would
 need to be rewritten as:
@@ -722,8 +722,8 @@ program.
 Uniform color                                                                  
 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
-Adding a `uniform` specified color like is only a matter of modifying the
-fragment shader as in the previous section an directly assigning the color to
+Adding a `uniform` specified color is only a matter of modifying the
+fragment shader as in the previous section and directly assigning the color to
 the quad program (see `<code/chapter-03/glumpy-quad-uniform-color.py>`_):
 
 .. code:: python
@@ -735,8 +735,8 @@ the quad program (see `<code/chapter-03/glumpy-quad-uniform-color.py>`_):
 Varying color                                                                  
 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
-Adding a per-vertex color like is also and only a matter of modifying the
-fragment shader as in the previous section an directly assigning the color to
+Adding a per-vertex color is also only a matter of modifying the
+fragment shader as in the previous section and directly assigning the color to
 the quad program (see `<code/chapter-03/glumpy-quad-varying-color.py>`_):
 
 .. code:: python
@@ -849,7 +849,7 @@ angle theta around the origin (0,0) for a point (x,y):
        float y2 = sin(theta)*x + cos(theta)*y;
 
 
-Solution: `<code/chapter-03/quad-rotate.py>`_
+Solution: `<code/chapter-03/quad-rotation.py>`_
 
 
 .. _GLUT:   http://freeglut.sourceforge.net 		

04-maths.rst

@@ -10,7 +10,7 @@ Basic Mathematics
 
 
 There is no way around mathematics. If you want to understand computer
-geometry, you need to masterize a few mathematical concepts. But not that many
+geometry, you need to master a few mathematical concepts. But not that many
 actually. I won't introduce everything since there is already a lot of
 tutorials online explaining the core concepts of `linear algrebra
 <http://math.hws.edu/graphicsbook/c3/s5.html>`_, `Euclidean geometry
@@ -92,7 +92,7 @@ through points to be projected). For these two projections, results are similar
 but different. In the first case, distances have been exactly conserved while
 in the second case, the distance between projected points has increased, but
 projected points are still equidistant. The third projection is where
-homogenous coordinates make sense. For this (abritraty) projection, we decided
+homogenous coordinates make sense. For this (arbitrary) projection, we decided
 that the further the point is from the origin, and the further away from the
 origin its projection will be. To do that, we measure the distance of the point
 to the origin and we add this distance to its `w` value before projecting it
@@ -110,7 +110,7 @@ P(-0.5), P(0.0), P(+0.5), P(+1.0)]`, we have have `║P(-1.0)-P(-0.5)]║ >
    actual representation: a + bi⃗ + cj⃗ + dk⃗, where a, b, c, and d are real
    numbers, and i⃗, j⃗, k⃗ are the fundamental quaternion units.
 
-Back to our regular 3D-Euclidean space, the principle remains the same and we have the following relationgship between Cartesian and homogeneous coordinates:
+Back to our regular 3D-Euclidean space, the principle remains the same and we have the following relationship between Cartesian and homogeneous coordinates:
 
 .. code::
    :class: math
@@ -122,7 +122,7 @@ Back to our regular 3D-Euclidean space, the principle remains the same and we ha
    Cartesian     Homogeneous
    
 
-If you didn't understood everything, you can stick to the description provided
+If you didn't understand everything, you can stick to the description provided
 by Sam Hocevar:
 
 * If w = 1, then the vector (x,y,z,1) is a position in space
@@ -144,7 +144,7 @@ Transformations
    (bottom). Remember that last transformation is on the left.
 
 
-We'll use now homogeneous coordinates and express all our transformations using
+We'll now use homogeneous coordinates and express all our transformations using
 only 4×4 matrices. This will allow us to chain several transformations by
 multiplying transformation matrices. However, before diving into the actual
 definition of these matrices, we need to decide if we consider a four

05-cube.rst

@@ -32,10 +32,10 @@ explicitly OpenGL how to draw 6 faces with them:
 
 These vertice describe a cube centered on (0,0,0) that goes from (-1,-1,-1) to
 (+1,+1,+1). Unfortunately, we cannot use `gl.GL_TRIANGLE_STRIP` as we did for
-the quad. If your remember how this rendering primitive considers vertices as a
+the quad. If you remember how this rendering primitive considers vertices as a
 succession of triangles, you should also realize there is no way to organize
-our vertices into a triangle strip that wpuld describe our cube. This means we
-have to tell OpenGL explicitely what are our triangles, i.e. we need to
+our vertices into a triangle strip that would describe our cube. This means we
+have to tell OpenGL explicitly what are our triangles, i.e. we need to
 describe triangles in terms of vertex indices (relatively to the `V` array we
 just defined):
 
@@ -108,7 +108,7 @@ from the `glumpy.glm` module (that also defines ortho, frustum and perspective
 matrices as well as rotation, translation and scaling operations). This default
 perspective matrix is located at the origin and look in the negative z
 direction with the up direction pointing toward the positive y-axis. If we
-leave our cube at the origin, the camera would be inside the cube and we woudl
+leave our cube at the origin, the camera would be inside the cube and we would
 not see much. So let first create a view matrix that is a translation along the
 z-axis:
 

16-glsl-reference.rst

@@ -171,7 +171,7 @@ functionality are intrinsically declared with the following types:
 
 :proto:`gl_PointSize`
 
-   The variable gl_PointSize` is intended for a vertex shader to write the size
+   The variable `gl_PointSize` is intended for a vertex shader to write the size
    of the point to be rasterized. It is measured in pixels.