Merge branch 'doc' into 0.9.1

doc/pages.doxy

@@ -9,16 +9,16 @@
 	 
 	This library works perfectly with OpenGL but it also ensures interoperability with other third party libraries and SDK. It is a good candidate for software rendering (Raytracing / Rasterisation), image processing, physic simulations and any context that requires a simple and convenient mathematics library.
 	
-	\note The Doxygen-generated documentation will often state that a type or function
-	is defined in a namespace that is a child of the \link glm glm \endlink namespace.
-	Please ignore this; you can access all publicly available types as direct children
-	of the glm namespace.
-	
 	GLM is written as a platform independent library with no dependence and officially supports the following compilers:
 	1. GCC 3.4 and higher
 	2. LLVM 2.3 through GCC 4.2 front-end and higher
 	3. Visual Studio 2005 and higher
 
+	\note The Doxygen-generated documentation will often state that a type or function
+	is defined in a namespace that is a child of the \link glm glm \endlink namespace.
+	Please ignore this; All publicly available types and functions can be accessed as a direct children
+	of the glm namespace.
+	 
 	The source code is licenced under the <a href="http://www.opensource.org/licenses/mit-license.php">MIT licence</a>.
 	 
 	Thanks for contributing to the project by <a href="https://sourceforge.net/apps/trac/ogl-math/newticket">submitting tickets for bug reports and feature requests</a>. 
@@ -67,7 +67,7 @@ int foo()
 	
 	The \ref core "GLM" represents only what GLSL's core provides in terms of types and functions
 	(to the best of GLM's ability to replicate them). All that is needed to use the core
-	is to <tt>#include <glm/glm.hpp></tt>.
+	is to include <tt><glm/glm.hpp></tt>.
 	
 	\ref gtc "GTC extensions" are functions and types that add onto the core.
 	These are considered reasonably stable, with their APIs not changing much between
@@ -79,7 +79,7 @@ int foo()
 	is why they are marked "experimental". Like GTC extensions, each experimental extension is included
 	with a separate header file.
 	
-	All the extensions can be included at once by default with <tt>#include <glm/ext.hpp></tt> 
+	All the extensions can be included at once by default by including <tt><glm/ext.hpp></tt> 
 	but this is not recommanded as it will reduce compilation speed for many unused features.
 	
 	All of GLM is defined as direct children of the glm namespace, including extensions. 
@@ -255,8 +255,8 @@ void foo()
 	
 	GLM's functions are defined in headers, so they are defined with C++'s "inline" delcaration. 
 	This does not require the compiler to inline them, however. 
-	If you want to force the compiler to inline the function, using whatever capabilities that the compiler provides to do so, 
-	you can define GLM_FORCE_INLINE before any inclusion of <glm/glm.hpp>.
+	To force the compiler to inline the function, using whatever capabilities that the compiler provides to do so, 
+	GLM_FORCE_INLINE can be defined before any inclusion of <glm/glm.hpp>.
 
 	\code
 #define GLM_FORCE_INLINE 
@@ -281,7 +281,7 @@ void foo()
 
 	\section advanced_compatibility Compatibility
 	Compilers have some language extensions that GLM will automatically take advantage of them when they are enabled. 
-	The #define GLM_FORCE_CXX98 can switch off these extensions, forcing GLM to operate on pure C++98.
+	GLM_FORCE_CXX98 can switch off these extensions, forcing GLM to operate on pure C++98.
 
 	\code
 #define GLM_FORCE_CXX98 
@@ -394,9 +394,10 @@ void foo()
 	
 	\section faq7 Should I use 'using namespace glm;'?
 	
-	This is unwise. There is every chance that are that if 'using namespace glm;' is called, name collisions will happen. GLSL names for functions are fairly generic, so it is entirely likely that there is another function called, for example, \link glm::sqrt sqrt \endlink.
+	This is unwise. Chances are that if 'using namespace glm;' is called, name collisions will happen. 
+	GLSL names for functions are fairly generic, so it is entirely likely that there is another function called, for example, \link glm::sqrt sqrt \endlink.
 	
-	If you need frequent use of particular types, you can bring them into the global
+	For frequent use of particular types, they can be brough into the global
 	namespace with a 'using' declaration like this:
 	
 	/code
@@ -409,9 +410,11 @@ void foo()
 	
 	GLM is mainly designed to be convenient; that's why it is written against GLSL specification.
 	
-	The <a href="http://en.wikipedia.org/wiki/Pareto_principle">80-20</a> rule suggests that 80% of a program's performance comes from 20% of its code. Therefore, one must first identify which 20% of the code is impacting the performance.
+	The <a href="http://en.wikipedia.org/wiki/Pareto_principle">80-20 rule</a> suggests that 80% of a program's performance comes from 20% of its code. 
+	Therefore, one should first identify which 20% of the code is impacting the performance.
 	
-	In general, if one identifies certain math code to be a performance bottleneck, the only way to solve this is to write specialized code for those particular math needs. So no canned library solution would be suitable.
+	In general, if one identifies certain math code to be a performance bottleneck, the only way to solve this is to write specialized code for those particular math needs. 
+	So no canned library solution would be suitable.
 	
 	That being said, GLM can provides some descent performances alternatives based on approximations or SIMD instructions.
 **/
@@ -614,12 +617,15 @@ glm::vec3 lighting(
 	GLM HEAD snapshot:
 		http://ogl-math.git.sourceforge.net/git/gitweb.cgi?p=ogl-math/ogl-math;a=snapshot;h=HEAD;sf=tgz
 	 
-	GLM Trac, for bug report and feature request:
+	GLM bug tracker:
 		https://sourceforge.net/apps/trac/ogl-math
 	 
 	GLM website:
 		http://glm.g-truc.net
 	 
+	GLM OpenGL SDK page:
+		http://www.opengl.org/sdk/libs/GLM/
+
 	G-Truc Creation page:
 		http://www.g-truc.net/project-0016.html