Merged 438:439, 440:441, and 442:457 from trunk/ to branches/1.1/, mostly major work done for 1.1.1 release.

- Various documentation updates
- Fixed fatal error in benchmark scripts, slightly augmented
- As far as possible, whitespace is preserved in-between table children
- Configuration option to optionally Tidy up output for indentation to make up for dropped whitespace by DOMLex (pretty-printing for the entire application should be done by a page-wide Tidy)
- Sample test-settings.php file included

Unrelated unmerged edit: removed irrelevant 1.2.0 release notes, those only exist in the trunk.

git-svn-id: http://htmlpurifier.org/svnroot/htmlpurifier/branches/1.1@458 48356398-32a2-884e-a903-53898d9a118a

SLOW

@@ -17,18 +17,23 @@ second tacked on to the load time probably isn't going to be that huge of
 a problem.  Then, displaying the content is a simple a manner of outputting
 it directly from your database/filesystem.  The trouble with this method is
 that your user loses the original text, and when doing edits, will be
-handling the filtered text.  Of course, maybe that's a good thing.  If you
-don't mind a little extra complexity, you can try...
+handling the filtered text.  While this may be a good thing, especially if
+you're using a WYSIWYG editor, it can also result in data-loss if a user
+expects a certain to be available but it doesn't.
 
 2. Caching the filtered output - accept the submitted text and put it
 unaltered into the database, but then also generate a filtered version and
 stash that in the database.  Serve the filtered version to readers, and the
 unaltered version to editors.  If need be, you can invalidate the cache and
 have the cached filtered version be regenerated on the first page view.  Pros?
-Full data retention.  Cons?  It's more complicated.
+Full data retention.  Cons?  It's more complicated, and opens other editors
+up to XSS if they are using a WYSIWYG editor (to fix that, they'd have to
+be able to get their hands on the *really* original text served in plaintext
+mode).
 
 In short, inbound filtering is almost as simple as outbound filtering, but
 it has some drawbacks which cannot be fixed unless you save both the original
 and the filtered versions.
 
-There is a third option: profile and optimize HTMLPurifier yourself.  ;-)
+There is a third option: profile and optimize HTMLPurifier yourself.  Be sure
+to tell me if you decide to do that!  ;-)