run it through a smelling checker

git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@9192 57a11ea4-9604-0410-9ed3-97b8803252fd

src/doc/books.txt

@@ -30,7 +30,7 @@ other similar accounting concepts requires 'Lots' to be correctly
 handled.  Lots are a way of identifying that an item bought in one
 transaction is the same as that sold in another transaction. 
 When a book is closed, the entire lot must be brought forward,
-and not just the account balance, because depreciation, captial
+and not just the account balance, because depreciation, capital
 gains, taxes, etc. depend on the dates of the originating
 transaction.  See 'lots.txt' for details.
 
@@ -64,7 +64,7 @@ this.  More specifically: Split one file into two, with only 'old'
 transactions in one, and only 'new' transactions in the other.
 
 I believe that this can be 'easily' coded by creating a second instance
-of a gnc-book structure in memory, copying all the account info 
+of a qofbook structure in memory, copying all the account info 
 into it, and using Query.c to copy in only the 'old' transactions.
 (and v.v. using Query.c to delete the old transactions in the other copy.)
 Then, look up the ending balance on all asset/liability accounts
@@ -74,7 +74,7 @@ The transfer description is, of course, 'opening balance'.
 Balances of income/expense accounts are zeroed out.
 
 I believe this code would be easy to write in C or scheme. There may be
-a few bugs/difficulties lurking in gnc-book that might trip things up.
+a few bugs/difficulties lurking in qofbook that might trip things up.
 Also, at a minimum, there needs to be a GUI dialog, asking for the 
 date on which to close the books.
 
@@ -233,20 +233,20 @@ Pro's & Con's
 -------------
 I am not aware of any con's to plan A at this point.
 
-Imlementation Overview
+Implementation Overview
 ----------------------
 Plan A has been implemented in the engine.  To quickly summarize:
 -- Partitioning involves splitting one book into two, called the
    "old, closing book", and the "current open book".
 
 -- Accounts are copied between old and new books.  One of the copies
-   is issued new GUID's, but the rest of teh account data is copied.
+   is issued new GUID's, but the rest of the account data is copied.
    KVP pairs are then added so that each copy points at the other,
    and can thus be easily found.  The "gemini" KVP keyword is used.
    The opening balance is zeroed for income accounts.  A transaction
    is created to set the correct opening balance on asset accounts. 
-   The transaction is a tranfer from equity.  An equity account is
-   created automagically, if neeeded.
+   The transaction is a transfer from equity.  An equity account is
+   created automagically, if needed.
 
 -- Transactions. Transactions are partitioned, and end up either
    in the old or the new book.  Splits move with transactions.
@@ -265,7 +265,7 @@ Plan A has been implemented in the engine.  To quickly summarize:
 
 -- Scheduled transactions/recurring transactions.  These are left
    in the new book, untouched.   They are not copied into the old
-   book, and no trace of thier existance is left in the old book.
+   book, and no trace of their existence is left in the old book.
 
 -- Business Objects. Not implemented.
 
@@ -304,15 +304,15 @@ Implementation Notes:
    because they can be easily picked apart by an appropriate SQL query.
    (Not tested, probably borken).
 
-   Period-closing does not delete enything from the SQL database.  That's
+   Period-closing does not delete anything from the SQL database.  That's
    the design.  The core assumption is that having lots of old data in the
-   sql db wouldn't slow it down, and thus, nothing needed to be actually
+   SQL DB wouldn't slow it down, and thus, nothing needed to be actually
    deleted. So it doesn't delete anything.
                                                                                 
-   However, an sql admin, if they were desperate to trim the db size, 
+   However, an SQL admin, if they were desperate to trim the DB size, 
    could DELETE FROM * WHERE bookguid='asdfasdfasdf';
 
--- The xml-file backend can store multiple books in one file.  There 
+-- The XML-file backend can store multiple books in one file.  There 
    is currently minimal support for writing out multiple books, 
    one per file (this enables faster load, by not loading old books).  
    There is currently no support for loading multiple books from multiple
@@ -335,7 +335,7 @@ a long time ago.
 
 The biggest drawback to the automatic computation of the gains/losses
 is that there is no GUI to specify alternate accounting methods
-(e.g. LIFO, or hand-picked lots, etc.)  There is bascially no practical
+(e.g. LIFO, or hand-picked lots, etc.)  There is basically no practical
 way to 'undo' the results of the gain/loss computations.
 
 The other main drawback to book closing is that this will prevent
@@ -343,17 +343,11 @@ multi-year (multi-period) reports & graphs from being generated.
 The old data will be in separate files, and there is currently no
 way to load several files at once.
 
-I would like to hear some thoughts/discussion on these issues. 
-Bug reports, too.  A ranking of 'the most important related
-task to do next' would be good.  One, um, uncomfortable remark:  
-I am so flooded in email that I may not be able to react for a while.  
-(Like a week or more).
-
 
 Open Issues/Questions that Need Discussion:
 -------------------------------------------
 *) How to handle business objects? e.g. vendors, customers should be
-   copied into both old and new books.  But invocies should be in one 
+   copied into both old and new books.  But invoices should be in one 
    or the other.  Need to document which is which.
 
 *) Discussion Q: What should the naming convention be for the different 
@@ -365,7 +359,7 @@ Open Issues/Questions that Need Discussion:
 
    where the number is the GUID of the closed book (needed to be able to
    quickly find the book/file) and 'my-gnucash-file.xac' is the name of
-   the orignial file whose books were closed.
+   the original file whose books were closed.
 
    Need to change the name to include the word "archive".
 
@@ -420,7 +414,7 @@ Open Issues / ToDo
 
 *) add 13-period support to FreqSpec and the FreqSpec widget.  
    e.g. from the mailing list:
-   One of the calenders my company uses is like this:
+   One of the calendars my company uses is like this:
    13 periods
    1st period begins jan 1st, partial first week plus 4 weeks.
    2nd - 13th period begins on a sunday every four weeks.