Fix .md file formatting

doc/BranchingAndRolling.md

@@ -11,14 +11,17 @@ branch to correspond to a branched release of Chrome.
 Chromium's dependency on third-party projects is tracked in [the Chromium
 repository's src/DEPS file]
 (http://src.chromium.org/viewvc/chrome/trunk/src/DEPS). To update the ANGLE
-dependency: * Find the line in this file that defines "src/third\_party/angle"
-for deps (**not** deps\_os) * Change the [git SHA-1 revision number]
+dependency:
+ * Find the line in this file that defines "src/third\_party/angle"
+for deps (**not** deps\_os)
+ * Change the [git SHA-1 revision number]
 (http://git-scm.com/book/ch6-1.html) to be that of the commit on which Chromium
-should depend. Please use the full SHA-1, not a shortened version. * You can
+should depend. Please use the full SHA-1, not a shortened version.
+ * You can
 find the SHA-1 for a particular commit with `git log` on the appropriate branch
 of the repository, or via [the public repository viewer]
-(https://chromium.googlesource.com/angle/angle). * If using the public
-repository viewer, you will need to select the branch whose log you wish to view
+(https://chromium.googlesource.com/angle/angle).
+ * If using the public repository viewer, you will need to select the branch whose log you wish to view
 from the list on the left-hand side, and then click on the "tree" link at the
 top of the resulting page. Alternatively, you can navigate to
 `https://chromium.googlesource.com/angle/angle/+/<branch name>/` -- including
@@ -33,18 +36,18 @@ created to correspond to the Chrome release version, so that Chrome may
 incorporate only these changes, and not everything that has been committed since
 the version on which Chrome depended at branch time. **Please note: Only ANGLE
 admins can create a new branch.** To create a branch of ANGLE for a branched
-Chrome release: * Determine what the ANGLE dependency is for the Chrome release
-by checking the DEPS file for that branch. * Check out this commit as a new
-branch in your local repository. * e.g., for [the Chrome 34 release at
-chrome/branches/1847]
+Chrome release:
+ * Determine what the ANGLE dependency is for the Chrome release
+by checking the DEPS file for that branch.
+ * Check out this commit as a new branch in your local repository.
+   * e.g., for [the Chrome 34 release at chrome/branches/1847]
 (http://src.chromium.org/viewvc/chrome/branches/1847/src/DEPS), the ANGLE
 version is 4df02c1ed5e97dd54576b06964b1da67ea30238e. To check this commit out
-locally and create a new branch named 'mybranch' from this commit, use: `git
-checkout -b mybranch 4df02c1ed5e97dd54576b06964b1da67ea30238e
-` * To create this new branch in the public repository, you'll need to push the
+locally and create a new branch named 'mybranch' from this commit, use: ```git
+checkout -b mybranch 4df02c1ed5e97dd54576b06964b1da67ea30238e```
+ * To create this new branch in the public repository, you'll need to push the
 branch to the special Gerrit reference location, 'refs/heads/<branch name>'. You
-must be an ANGLE administrator to be able to push this new branch. * e.g., to
-use your local 'mybranch' to create a branch in the public repository called
-'chrome\_m34', use: `git push origin mybranch:refs/heads/chrome_m34
-` * The naming convention that ANGLE uses for its release-dedicated branches is
-'chrome\_m##'.
+must be an ANGLE administrator to be able to push this new branch.
+   * e.g., to use your local 'mybranch' to create a branch in the public repository called
+'chrome\_m34', use: ```git push origin mybranch:refs/heads/chrome_m34```
+   * The naming convention that ANGLE uses for its release-dedicated branches is 'chrome\_m##'.

doc/CodingStandard.md

@@ -60,25 +60,31 @@ Items marked {DEV} indicate a deviation from the Google guidelines. Items marked
 #### Variable Names
 
 Use the following guidelines, they do deviate somewhat from the Google
-guidelines. * class and type names: start with capital letter and use CamelCase.
+guidelines. 
+* class and type names: start with capital letter and use CamelCase.
 * {DEV} class member variables: use an **`m`** prefix instead of trailing
-underscore and use CamelCase. * global variables (if they must be used): use a
-**`g_`** prefix. * {DEV} variable names: start with lower case and use CamelCase
-(chosen for consitency) * {DEV} function names: Member functions start with
-lower case and use CamelCase. Non-member functions start with capital letter and
-use CamelCase (chosen for consistency) * Constants: start with a **`k`** and use
-CamelCase * namespaces: use all lower case * Enumerator Names - follow constants
-* macros: all uppercase with underscores * exceptions to naming: use common
-sense!
+underscore and use CamelCase.
+* global variables (if they must be used): use a **`g_`** prefix.
+* {DEV} variable names: start with lower case and use CamelCase (chosen for consistency)
+* {DEV} function names: Member functions start with lower case and use CamelCase. Non-member functions start with capital letter and
+use CamelCase (chosen for consistency)
+* Constants: start with a **`k`** and use CamelCase
+* namespaces: use all lower case
+* Enumerator Names - follow constants
+* macros: all uppercase with underscores
+* exceptions to naming: use common sense!
 
 ### [Comments](http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Comments)
 
 *   {DO} read and follow Google's recommendations.
-*   Each file **must** start with the following boilerplate notice: `// //
-    Copyright (c) 2002-2011 The ANGLE Project Authors. All rights reserved. //
-    Use of this source code is governed by a BSD-style license that can be //
-    found in the LICENSE file. //
-    `
+*   Each file **must** start with the following boilerplate notice:
+```
+//
+//  Copyright (c) 2002-2011 The ANGLE Project Authors. All rights reserved.
+//  Use of this source code is governed by a BSD-style license that can be
+//  found in the LICENSE file.
+//
+```
 
 ### [Formatting](http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Formatting)
 
@@ -101,13 +107,44 @@ sense!
     header file where the whole function declaration and definition fit on one
     line.
 
-Examples: `if (conditional) { stuff(); } else { otherstuff() }
-` `switch (conditional) { case foo: dostuff(); break; case bar: otherstuff()
-break; default: WTFBBQ(); }
-` `class MyClass : public Foo { public: MyClass(); ~MyClass() {}; private:
-DISALLOW_COPY_AND_ASSIGN(MyClass); };
-` `char *c; const string &str;
-`
+Examples:
+```
+if (conditional)
+{
+    stuff();
+}
+else
+{
+    otherstuff()
+}
+```
+```
+switch (conditional)
+{
+  case foo:
+    dostuff();
+    break;
+  case bar:
+    otherstuff();
+    break;
+  default:
+    WTFBBQ();
+}
+```
+```
+class MyClass : public Foo
+{
+  public:
+    MyClass();
+    ~MyClass() {};
+  private:
+    DISALLOW_COPY_AND_ASSIGN(MyClass);
+};
+```
+```
+char *c;
+const string &str;
+```
 
 ### [Exceptions to the Rules](http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions_to_the_Rules)
 

doc/Update20120704.md

@@ -25,17 +25,19 @@ ANGLE.
 
 ## Shader Compiler
 
-We have also made a number of improvements in the shader compiler. * We
-addressed a number of defects related to scoping differences between HLSL and
+We have also made a number of improvements in the shader compiler.
+* We addressed a number of defects related to scoping differences between HLSL and
 GLSL and improved the scoping support in ANGLE's compiler front-end. We also
 worked with The Khronos Group to get an ESSL spec bug fixed and several items
-clarified. * We addressed a number of correctness issues in the GLSL to HLSL
+clarified.
+* We addressed a number of correctness issues in the GLSL to HLSL
 translation process. We fixed some bugs related to constant propagation and
 comma conditional assignments. More importantly, we fully implemented support
 for short-circuiting boolean logic operations. In GLSL, Boolean expressions do
 short-circuit evaluation as in C, but HLSL evaluates them entirely. This only
 has an observable effect if a short-circuited operation has side effects, such
-as a function call that modifies global variables. * We implemented detection
+as a function call that modifies global variables.
+* We implemented detection
 for discontinuous gradient or derivative computations inside loops and replace
 them with explicitly defined continuous behaviour. HLSL and GLSL differ in their
 specified behaviour for operations which compute gradients or derivatives.
@@ -84,10 +86,13 @@ have changed this back to the original way it was implemented - textures are
 loaded and stored in the GL orientation, and the final rendered scene is flipped
 when it is displayed to a window by eglSwapBuffers. This should be essentially
 transparent to applications except that orientation of pbuffers will change.  In
-addition to fixing the pbuffer orientation, this change: * eliminates
+addition to fixing the pbuffer orientation, this change:
+* eliminates
 dependent-texture look-ups in the shaders, caused by flipping the texture
-y-coordinates, * rounding of texture coordinates (while previously within spec)
-will be more consistent with other implementations, and * allows potential
+y-coordinates
+* rounding of texture coordinates (while previously within spec)
+will be more consistent with other implementations, and
+* allows potential
 faster paths for loading texture data to be implemented. The only potential
 downside to this approach is that window-based rendering may be a bit slower for
 simple scenes. The good news is that this path is not used by browser

doc/Update20140325.md

@@ -13,9 +13,15 @@ will generally not be considered, and future work should be done on master.
 This merge doesn't signify completion of ES 3.0, as we have some features still
 left to implement there, but interested developers can explore the work in
 progress. A significant portion of 3.0 features have been implemented,
-including: * 2D array textures, 3D textures * Expanded texture format support *
-Uniform Buffer Objects * Vertex Array Objects * Sampler objects, expanded
-sampler types * Transform Feedback * Texture Swizzle * GLSL integer support
+including:
+* 2D array textures, 3D textures
+* Expanded texture format support
+* Uniform Buffer Objects
+* Vertex Array Objects
+* Sampler objects, expanded sampler types
+* Transform Feedback
+* Texture Swizzle
+* GLSL integer support
 
 ES 3.0 features should not yet be considered stable, even where implemented, and
 some features are present only via naive implementation so far. There is still

doc/Update20150105.md

@@ -21,14 +21,23 @@ implementations compatible with OS X and Linux.
 
 Our ES 3.0 development branch was merged into mainline ANGLE in April 2014, but
 ES 3.0 support is not yet complete. The majority of API functionality has been
-implemented; features still pending include: * ETC2/EAC support * primitive
-restart index * drawRangeElements * full GetProgramBinary support in core
+implemented; features still pending include:
+* ETC2/EAC support
+* primitive restart index
+* drawRangeElements
+* full GetProgramBinary support in core
 
-Additional work remains in the compiler, including: * Array .length() * inf/nan
-detection * math utility functions, rounding * VertexID/InstanceID support *
-floating point packing functions * operators new in ES 3.0 * name redeclaration
-* relaxed array indexing * switch statement support * loop & iteration
-improvements
+Additional work remains in the compiler, including:
+* Array .length()
+* inf/nan detection
+* math utility functions, rounding
+* VertexID/InstanceID support
+* floating point packing functions
+* operators new in ES 3.0
+* name redeclaration
+* relaxed array indexing
+* switch statement support
+* loop & iteration improvements
 
 ES 3.0 features should not be considered stable, even where implemented, and
 some features are present only via naive implementation so far, but we welcome