Fix documentation: grammar, typos, and clarity improvements

Co-authored-by: DimitriPapadopoulos <3234522+DimitriPapadopoulos@users.noreply.github.com>

Author: 2 people

ANNOUNCE.md

@@ -14,10 +14,10 @@ https://github.com/Blosc/c-blosc2/blob/main/RELEASE_NOTES.md
 
 Blosc2 is a high-performance data container optimized for binary data.
 Blosc2 is the next generation of Blosc, an [award-winning]
-(https://www.blosc.org/posts/prize-push-Blosc2)` library that has been
+(https://www.blosc.org/posts/prize-push-Blosc2) library that has been
 around for more than a decade.
 
-Blosc2 expands the capabilities of Blosc by providing a higher lever
+Blosc2 expands the capabilities of Blosc by providing a higher level
 container that is able to store many chunks on it (hence the super-block name).
 It supports storing data on both memory and disk using the same API.
 Also, it adds more compressors and filters.

COMPILING_WITH_WHEELS.rst

@@ -13,7 +13,7 @@ C-Blosc2 binary libraries (including plugins functionality) can easily be instal
         Installing collected packages: blosc2
         Successfully installed blosc2-0.1.8 
 
-As a result, one can easily update to the latest version of C-Blosc2 binaries without the need to manually compile the thing. Following are instructions on how to use the libraries in wheels for different platforms.
+As a result, one can easily update to the latest version of C-Blosc2 binaries without the need to manually compile it. Following are instructions on how to use the libraries in wheels for different platforms.
 
 Compiling C files with Blosc2 wheels on Windows
 ----------------------------------------------
@@ -31,7 +31,7 @@ Compiling C files with Blosc2 wheels on Windows
     usage: cl [ option... ] filename... [ /link linkoption... ]
 
 
-- Make the compiler available. Its typical installation location uses to be `C:\\Program files (x86)\\Microsoft Visual Studio`, so change your current directory there. Then, to set up the build architecture environment you can open a command prompt window in the `VC\\Auxiliary\\Build` subdirectory and execute `vcvarsall.bat x64` if your architecture is 64 bits or `vcvarsall.bat x86` if it is 32 bits.
+- Make the compiler available. Its typical installation location is `C:\\Program files (x86)\\Microsoft Visual Studio`, so change your current directory there. Then, to set up the build architecture environment you can open a command prompt window in the `VC\\Auxiliary\\Build` subdirectory and execute `vcvarsall.bat x64` if your architecture is 64 bits or `vcvarsall.bat x86` if it is 32 bits.
 
 - You will need to know the path where the Blosc2 wheel has installed its files.  For this we will use the `dir /s` command (but you can use your preferred location method):
 

FAQ.md

@@ -2,8 +2,8 @@
 
 ### Compatibility among libraries with different minor versions
 
-The compatibility between minor versions (e.g. 2.0 <-> 2.1) will always be *both* backward and forward.  This means that any version of the library will be able to read any data produced with another version differing only in the patch level or minor version. Not being able to achieve that will be considered a bug, and action will be taken to fix that as soon as possible (see e.g.https://github.com/Blosc/c-blosc/issues/215).
+The compatibility between minor versions (e.g. 2.0 <-> 2.1) will always be *both* backward and forward.  This means that any version of the library will be able to read any data produced with another version differing only in the patch level or minor version. Not being able to achieve that will be considered a bug, and action will be taken to fix that as soon as possible (see e.g. https://github.com/Blosc/c-blosc/issues/215).
 
 ### Compatibility among libraries with different major versions
 
-There will be an *attempt* (but not an absolute guarantee) of backward compatibility, but it won’t be an effort for guaranteeing forward compatibility.  For example, Blosc2 2.1 is be able to read any data produced by Blosc 1.x, but Blosc 1.x are not able to read data produced by Blosc2 2.x.
+There will be an *attempt* (but not an absolute guarantee) of backward compatibility, but it won’t be an effort for guaranteeing forward compatibility.  For example, Blosc2 2.1 is able to read any data produced by Blosc 1.x, but Blosc 1.x are not able to read data produced by Blosc2 2.x.

README.rst

@@ -35,18 +35,18 @@ What is it?
 
 C-Blosc2 is the new major version of `C-Blosc <https://github.com/Blosc/c-blosc>`_, and is backward compatible with both the C-Blosc1 API and its in-memory format.  However, the reverse thing is generally not true for the format; buffers generated with C-Blosc2 are not format-compatible with C-Blosc1 (i.e. forward compatibility is not supported).  In case you want to ensure full API compatibility with C-Blosc1 API, define the `BLOSC1_COMPAT` symbol.
 
-See a 3 minutes  `introductory video to Blosc2 <https://www.youtube.com/watch?v=ER12R7FXosk>`_.
+See a 3-minute `introductory video to Blosc2 <https://www.youtube.com/watch?v=ER12R7FXosk>`_.
 
 
 Blosc2 NDim: an N-Dimensional store
 ===================================
 
-One of more exciting additions in C-Blosc2 is the `Blosc2 NDim layer <https://www.blosc.org/c-blosc2/reference/b2nd.html>`_ (or B2ND for short), allowing to create *and* read n-dimensional datasets in an extremely efficient way thanks to a n-dim 2-level partitioning, that allows to slice and dice arbitrary large and compressed data in a more fine-grained way:
+One of more exciting additions in C-Blosc2 is the `Blosc2 NDim layer <https://www.blosc.org/c-blosc2/reference/b2nd.html>`_ (or B2ND for short), which allows creating *and* reading n-dimensional datasets in an extremely efficient way thanks to a n-dim 2-level partitioning, that allows slicing and dicing arbitrary large and compressed data in a more fine-grained way:
 
 .. image:: https://github.com/Blosc/c-blosc2/blob/main/images/b2nd-2level-parts.png?raw=true
   :width: 75%
 
-To wet you appetite, here it is how the `NDArray` object in the  `Python wrapper`_ performs on getting slices orthogonal to the different axis of a 4-dim dataset:
+To whet your appetite, here is how the `NDArray` object in the  `Python wrapper`_ performs on getting slices orthogonal to the different axis of a 4-dim dataset:
 
 .. image:: https://github.com/Blosc/c-blosc2/blob/main/images/Read-Partial-Slices-B2ND.png?raw=true
   :width: 75%
@@ -181,7 +181,7 @@ Contributing
 If you want to collaborate in this development you are welcome.  We need help in the different areas listed at the `ROADMAP <https://github.com/Blosc/c-blosc2/blob/main/ROADMAP-TO-3.0.rst>`_; also, be sure to read our `DEVELOPING-GUIDE <https://github.com/Blosc/c-blosc2/blob/main/DEVELOPING-GUIDE.rst>`_ and our `Code of Conduct <https://github.com/Blosc/community/blob/master/code_of_conduct.md>`_.  Blosc is distributed using the `BSD license <https://github.com/Blosc/c-blosc2/blob/main/LICENSE.txt>`_.
 
 
-Tweeter feed
+Twitter feed
 ============
 
 Follow `@Blosc2 <https://twitter.com/Blosc2>`_ so as to get informed about the latest developments.

README_ARM.rst

@@ -12,7 +12,7 @@ arm64 implementation.  Currently, you can compile C-Blosc2 with:
 
 The NEON extensions are used automatically in this case.
 
-Here it is a couple of benchmarks on BloscLZ and LZ4 codecs running on a MacBook Air
+Here are a couple of benchmarks on BloscLZ and LZ4 codecs running on a MacBook Air
 with a new M1 arm64 processor:
 
 .. code-block:: console

README_CFRAME_FORMAT.rst

@@ -78,7 +78,7 @@ possible filter meta-info in `filters_meta`::
 
 The last section of the header is for the *metalayers*, which contain meta-information about the data in the
 frame.  It is mandatory the use of the msgpack format for storing them, although the user may use another format
-(e.g. json) encoded as msgpack (in this case as a string). Here it is the format for the *metalayers*::
+(e.g. json) encoded as msgpack (in this case as a string). Here is the format for the *metalayers*::
 
     |-57|-58|-59|-5A|-5B|-5C|-5D|====================|---|---|---|================|
     | 93| cd| idx   | de| size  | meta keys/values   | dc|  idy  | meta content   |
@@ -213,7 +213,7 @@ Dumping info in metalayers
 
 **Note:** The method in this section only works for Unix.
 
-Here it is a trick for printing the content of metalayers using the nice set of
+Here is a trick for printing the content of metalayers using the nice set of
 `msgpack-tools <https://github.com/ludocode/msgpack-tools>`_ command line utilities.  After installing the package we
 can do e.g.::
 

README_THREADED.rst

@@ -3,7 +3,7 @@ Blosc supports threading
 
 Threads are the most efficient way to program parallel code for
 multi-core processors, but also the more difficult to program well.
-Also, they has a non-negligible start-up time that does not fit well
+Also, they have a non-negligible start-up time that does not fit well
 with a high-performance compressor as Blosc tries to be.
 
 In order to reduce the overhead of threads as much as possible, I've

ROADMAP-TO-3.0.rst

@@ -25,7 +25,7 @@ General improvements
 
 * **Multiple index chunks in frames:** right now, only `one chunk <https://github.com/Blosc/c-blosc2/blob/main/README_CFRAME_FORMAT.rst#chunks>`_ is allowed for indexing other chunks.  Provided the 2GB limit for a chunksize, that means that 'only' 256 million of chunks can be stored in a frame.  Allowing for more than one index chunk would overcome this limitation.
 
-* **More robust detection of CPU capabilities:** although currently this detection is quite sophisticated, the code responsible for that has organically grow for more than 10 years and it is time to come with a more modern and robust way of doing this. https://github.com/google/cpu_features may be a good helper for doing this refactoring.
+* **More robust detection of CPU capabilities:** although currently this detection is quite sophisticated, the code responsible for that has organically grown for more than 10 years and it is time to come with a more modern and robust way of doing this. https://github.com/google/cpu_features may be a good helper for doing this refactoring.
 
 * **Documentation:** utterly important for attracting new users and making the life easier for existing ones.  Important points to have in mind here:
 

WHATS-NEW.rst

@@ -13,9 +13,9 @@ Right now, the next features are already implemented (although they may require
 
 * **A filter pipeline:** the different filters can be pipelined so that the output of one can be the input for the other.  A possible example is a `delta` followed by `shuffle`, or as described above, `trunc_prec` followed by `bitshuffle`.
 
-* **Prefilters:** allows to apply user-defined C callbacks **prior** the filter pipeline during compression.  See `test_prefilter.c <https://github.com/Blosc/c-blosc2/blob/main/tests/test_prefilter.c>`_ for an example of use.
+* **Prefilters:** allows applying user-defined C callbacks **prior to** the filter pipeline during compression.  See `test_prefilter.c <https://github.com/Blosc/c-blosc2/blob/main/tests/test_prefilter.c>`_ for an example of use.
 
-* **Postfilters:** allows to apply user-defined C callbacks **after** the filter pipeline during decompression. The combination of prefilters and postfilters could be interesting for supporting e.g. encryption (via prefilters) and decryption (via postfilters).  Also, a postfilter alone can be used to produce on-the-flight computation based on existing data (or other metadata, like e.g. coordinates). See `test_postfilter.c <https://github.com/Blosc/c-blosc2/blob/main/tests/test_postfilter.c>`_ for an example of use.
+* **Postfilters:** allows applying user-defined C callbacks **after** the filter pipeline during decompression. The combination of prefilters and postfilters could be interesting for supporting e.g. encryption (via prefilters) and decryption (via postfilters).  Also, a postfilter alone can be used to produce on-the-fly computation based on existing data (or other metadata, like e.g. coordinates). See `test_postfilter.c <https://github.com/Blosc/c-blosc2/blob/main/tests/test_postfilter.c>`_ for an example of use.
 
 * **SIMD support for ARM (NEON):** this allows for faster operation on ARM architectures.  Only `shuffle` is supported right now, but the idea is to implement `bitshuffle` for NEON too.  Thanks to Lucian Marc.
 

plugins/README.md

@@ -18,7 +18,7 @@ A codec is a program that compresses and decompresses digital data streams with
 
 A filter is a program that rearranges data without changing its size, so that the initial and final sizes remain equal. A filter consists of an encoder and decoder. The filter encoder is applied before using the codec compressor (or codec encoder) to make the data easier to compress, while the filter decoder is used after the codec decompressor (or codec decoder) to restore the original data arrangement. Some filters used by Blosc include SHUFFLE, which rearranges data based on the type size, and TRUNC, which zeroes the mantissa bits to reduce the precision of (floating point) data and increase the compression ratio.
 
-Here it is an example on how the compression process goes:
+Here is an example on how the compression process goes:
 
 
     --------------------   filter encoder  -------------------   codec encoder   -------
@@ -60,7 +60,7 @@ that their code must satisfy:
 - First, the plugin code must be **developed in C**, have a relatively small footprint
   and meet decent quality code standards.
 
-- Second, users must develop a test suite which prove that the plugin works correctly.
+- Second, users must develop a test suite that proves that the plugin works correctly.
 
 Finally, even if these requirements are completely satisfied, it is not
 guaranteed that the plugin will be useful or contribute something