From b1085c6816c093409c745a41567c8c3009917e27 Mon Sep 17 00:00:00 2001 From: Sebastian Rasmussen Date: Wed, 4 Jan 2017 20:06:57 +0100 Subject: Fix typos. --- docs/overview.txt | 4 ++-- docs/progressive.txt | 14 +++++++------- 2 files changed, 9 insertions(+), 9 deletions(-) (limited to 'docs') 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. -- cgit v1.2.3