More formatting for readme while I'm thinking about it.

Author: xronosuf

README.md

@@ -5,8 +5,7 @@ refer to the Ximera manual, which explains things in more detail and in a more u
 
 # General Structure and Intent of this Repo
 
-This Repo (will) be structured as follows...
-
+* **This Repo (will eventually be) structured as follows...**
 
 - masterTestFolder
     - (DTXFileName)Test.tex files (e.g. problemTest.tex)
@@ -24,23 +23,20 @@ This Repo (will) be structured as follows...
         - (dtxFileName)Test.tex files for the dtx files with no testable elements (e.g. banner.dtx)
 
 
-**testFiles Folder at a glance**
-
+* **testFiles Folder at a glance**
 The testFiles folder is the folder that contains all the actual test ximera document class files
 that are loaded and used for demo/testing. Files in this folder should adhere to a specific naming
 scheme, and by large should not need to be edited after they have been finalized as testing bed files.
 (More on this below).
 
-**masterTestFolder Folder at a glance**
-
+* **masterTestFolder Folder at a glance**
 The masterTestFolder is the location of all the xourse files that represent tests for each of the
 possible (individual) areas for testing - e.g. ''problem'' type environments or ''maketitle'' command.
 Again, these all adhere to a specific naming scheme and should not need to be edited once they have
 been verified as valid testbed files until/unless more content is added to its category.
 (Again, more on this below).
 
-**testGroupings Folder at a glance**
-
+* **testGroupings Folder at a glance**
 Finally, the testGroupings folder is likely where most of the testing will actually take place. This
 folder should contain a list of folders that represent ''types'' of content that may need to be verified
 or tested - e.g. ''environments'', ''answerables'' or ''authorship tools''. More folders may be added here
@@ -50,8 +46,7 @@ like the ``\answer`` command is likely to show up under a lot of different categ
 testing (e.g. ''student interactions'', ''page credit generating elements'', and ''javascript elements'' would
 all have the ``\answer`` command as a relevant test).
 
-**Important Note About Test Groupings**
-
+* **Important Note About Test Groupings**
 To ensure all tests stay up to date in the relevant testGroupings (and to avoid version mismatch and general confusion)
 the files inside the testGroups will be symlinks to the relevant test xourse in the masterTestFolder. So the only
 real test xourses will be the files in the master test folder - meaning there is only one file to update and keep
@@ -60,7 +55,7 @@ track of, and any changes to that one file will automatically update all relevan
 
 # Naming Schemes
 
-* Each test xourse is named after a dtx file, and every dtx file should have a test xourse named after it (with some exceptions, see below).
+* **Each test xourse is named after a dtx file and every dtx file has a test xourse.**
 Since all development work must be implemented via dtx file (as per CTAN standards) and most development work
 tends to involve only a few dtx files (usually just one or two), it is often easiest to test the new code by testing
 everything that is implemented by the newly changed dtx code. This testing bed makes that easy to accomplish by merely
@@ -70,15 +65,16 @@ i.e. each command/environment (or reasonably obvious groupings, like all ``\newt
 in the same place) has its own testing tile, making it relatively easy to investigate updated content, even inside a given dtx.
 Thus **Each test xourse should be named  (dtxFileName)Test.tex** e.g. ''abstractTest.tex'' for the ''abstract.dtx'' file.
 
-* Each test file in the testFiles folder is named after the relevant command, environment, etc that it is testing.
+* **Each test file is named after the relevant command/environment/etc that it is testing.**
 In most cases, this means it will be named the same as the dtx file (e.g. the ''abstract'' test file for the ''abstractTest''
 xourse). However, often there are a number of options, or other elements that need to be demo'ed/testable for a given 
 command/environment/etc. We don't want to have a single test file that contains all the various complexities of these
 things, as it becomes difficult to see what aspect ended up generating issues (if there are issues from a new update).
 Thus test files should have a ''Base'' version that is the minimal implementation of the tested item, and then various
 other files that demo/test the other relevant aspects.
 
-* As a special note, some specific test files/xourses need to load specific options or alternative files as part of their
+* **When Preambles are Necessary**
+Some specific test files/xourses need to load specific options or alternative files as part of their
 testing (e.g. the graphics testing file needs to input graphics, and set graphics paths in the preamble). When this is
 necessary, **do note use the xmpreamble** for the test repo - instead you should make a preamble with the relevant test
 file (or xourse as appropriate) name, appended with ''preamble'' - e.g. ''imagePreamble.tex'' is the preamble file