Fix typos.

2 files changed, 9 insertions, 9 deletions

diff --git a/docs/overview.txt b/docs/overview.txt
index 0e558fe8..0a194948 100644
--- a/docs/overview.txt
+++ b/docs/overview.txt
@@ -19,7 +19,7 @@ using MuPDF should use the error handling strategies described below.
 Common function arguments
 =========================
 
-Most functions in MuPDFs interface take a context argument.
+Most functions in MuPDF's interface take a context argument.
 
 A context contains global state used by MuPDF inside functions when
 parsing or rendering pages of the document. It contains for example:
@@ -101,7 +101,7 @@ The macro based nature of this system has 3 main limitations:
 	in fz_try throwing an exception may become undefined as part
 	of the process of throwing that exception.
 
-	As a way of mitigating this problem, we provide an fz_var()
+	As a way of mitigating this problem, we provide a fz_var()
 	macro that tells the compiler to ensure that that variable is
 	not unset by the act of throwing the exception.
 
diff --git a/docs/progressive.txt b/docs/progressive.txt
index 081f599e..da33f961 100644
--- a/docs/progressive.txt
+++ b/docs/progressive.txt
@@ -73,7 +73,7 @@ progressive loading.
 
   + Progressive streams
 
-    At its lowest level MuPDF reads file data from an fz_stream,
+    At its lowest level MuPDF reads file data from a fz_stream,
     using the fz_open_document_with_stream call. (fz_open_document
     is implemented by calling this). We have extended the fz_stream
     slightly, giving the system a way to ask for meta information
@@ -95,13 +95,13 @@ progressive loading.
 
     When data is pulled from a progressive stream, if we attempt to
     read data that is not currently available, the stream should
-    throw an FZ_ERROR_TRYLATER error. This particular error code
+    throw a FZ_ERROR_TRYLATER error. This particular error code
     will be interpreted by the caller as an indication that it
     should retry the parsing of the current objects at a later time.
 
     When a MuPDF call is made on a progressive stream, such as
     fz_open_document_with_stream, or fz_load_page, the caller should
-    be prepared to handle an FZ_ERROR_TRYLATER error as meaning that
+    be prepared to handle a FZ_ERROR_TRYLATER error as meaning that
     more data is required before it can continue. No indication is
     directly given as to exactly how much more data is required, but
     as the caller will be implementing the progressive fz_stream
@@ -138,7 +138,7 @@ progressive loading.
 
     Callers prepared to tolerate such renderings should set the
     'incomplete_ok' flag in the cookie, then call fz_run_page etc
-    as normal. If an FZ_ERROR_TRYLATER error is thrown at any point
+    as normal. If a FZ_ERROR_TRYLATER error is thrown at any point
     during the page rendering, the error will be swallowed, the
     'incomplete' field in the cookie will become non-zero and
     rendering will continue. When control returns to the caller
@@ -228,7 +228,7 @@ a server.
    For a non-linearized PDF on a byte request capable stream:
 
    - MuPDF will immediately seek to the end of the file to attempt
-     to read the trailer. This will fail with an FZ_ERROR_TRYLATER
+     to read the trailer. This will fail with a FZ_ERROR_TRYLATER
      due to the data not being here yet, but the stream code should
      remember that this data is required and it should be prioritized
      in the background fetch process.
@@ -248,7 +248,7 @@ a server.
    For a non-linearized PDF on a non-byte request capable stream:
 
    - MuPDF will immediately seek to the end of the file to attempt
-     to read the trailer. This will fail with an FZ_ERROR_TRYLATER
+     to read the trailer. This will fail with a FZ_ERROR_TRYLATER
      due to the data not being here yet. Subsequent retries will
      continue to fail until the whole file has arrived, whereupon
      the whole file will be instantly available.
@@ -278,4 +278,4 @@ a server.
  + Whenever MuPDF attempts to read from the stream, we check to see if
    we have data for this area of the file already. If we do, we can
    return it. If not, we remember this as the next "fill point" for our
-   receiver process and throw an FZ_ERROR_TRYLATER error.
+   receiver process and throw a FZ_ERROR_TRYLATER error.