Fixed typos in doc

doc/user_guide/supported_formats/digitalsurf.rst

@@ -3,31 +3,30 @@
 DigitalSurf format (SUR & PRO)
 ------------------------------
 
-``.sur`` and ``.pro`` is format developed by digitalsurf to import/export data in their MountainsMap scientific 
-analysis software. Target datasets originally result from (micro)-topography and imaging instruments: SEM, AFM, 
-profilometer. RGB(A) images, multilayer surfaces and profiles are also supported. Even though it is essentially 
-a surfaces format, 1D signals are supported for spectra and spectral maps. Specifically, this is the fileformat 
-used by Attolight SA for its scanning electron microscope cathodoluminescence (SEM-CL) hyperspectral maps. This 
-plugin was developed based on the MountainsMap software documentation.
-
-Support for loading ``.sur`` and ``.pro`` datasets is complete, including parsing of user/customer-specific 
-metadata, and opening of files containing multiple objects. Some rare specific objects (e.g. force curves) 
-are not supported, due to no example data being available. Those can be added upon request and providing of 
-example datasets. Heterogeneous data can be represented in ``.sur`` and ``.pro`` objects, for instance 
-floating-point/topography and rgb data can coexist along the same navigation dimension. Those are casted to 
-a homogeneous floating-point representation upon loading.
-
-Support for data saving is partial as ``.sur`` and ``.pro`` do not support all features of hyperspy signals. 
-First, they have limited dimensionality. Up to 3d data arrays with either 1d (series of images) or 2d 
-(hyperspectral studiable) navigation space can be saved. Also, ``.sur`` and ``.pro`` do not support non-uniform 
-axes and saving of models. Finally, ``.sur`` / ``.pro`` linearize intensities along a uniform axis to enforce 
-an integer-representation of the data (with scaling and offset). This means that export from float-type hyperspy 
-signals is inherently lossy.
-
-Within these limitations, all features from ``.sur`` and ``.pro`` fileformats are supported, notably data 
-compression and setting of custom metadata. The file writer splits a signal into the suitable digitalsurf
-dataobject primarily by inspecting its dimensions and its datatype, ultimately how various axes and signal 
-quantity are named. The criteria are listed here below:
+``.sur`` and ``.pro`` is a format developed by digitalsurf to import/export data in the MountainsMap scientific 
+analysis software. Target datasets are originally (micro)-topography maps and profile from imaging instruments: 
+SEM, AFM, profilometery etc. RGB(A) images, multilayer surfaces and profiles are also supported. Even though it 
+is essentially a surfaces format, 1D signals are supported for spectra and spectral maps. Specifically, this is 
+the format used by Attolight for saving SEM-cathodoluminescence (SEM-CL) hyperspectral maps. This plugin was 
+developed based on the MountainsMap software documentation.
+
+Support for loading ``.sur`` and ``.pro`` files is complete, including parsing of custom metadata, and opening of 
+files containing multiple objects. Some rare, deprecated object types (e.g. force curves) are not supported, due 
+to no example data being available. Those can be added upon request to the module, if provided with example data
+and a explanations. Unlike hyperspy.signal, ``.sur`` and ``.pro`` objects can be used to represent heterogeneous
+data. For instance, float (topography) and int (rgb data) data can coexist along the same navigation dimension. 
+Those are casted to a homogeneous floating-point representation upon loading.
+
+Support for data saving is partial, as ``.sur`` and ``.pro`` do not support all features of hyperspy signals. Up 
+to 3d data arrays with either 1d (series of images) or 2d (spectral maps) navigation space can be saved. ``.sur`` 
+and ``.pro`` also do not support non-uniform axes and fitted models. Finally, MountainsMap maps intensities along 
+an axis with constant spacing between numbers by enforcing an integer-representation of the data with scaling and 
+offset. This means that export from float data is inherently lossy.
+
+Within these limitations, all features from ``.sur`` and ``.pro`` fileformats are supported. Data compression and
+custom metadata allows a good interoperability of hyperspy and Mountainsmap. The file writer splits a signal into 
+the suitable digitalsurf dataobject. Primarily by inspecting its dimension and datatype. If ambiguity remains, it
+inspects the names of signal axes and ``metadata.Signal.quantity``. The criteria are listed here below:
 
 +-----------------+---------------+------------------------------------------------------------------------------+
 | Nav. dimension  | Sig dimension | Extension and MountainsMap subclass                                          |
@@ -48,11 +47,10 @@ quantity are named. The criteria are listed here below:
 | 2               | 1             | ``.sur``: hyperspectralMap (default)                                         |
 +-----------------+---------------+------------------------------------------------------------------------------+
 
-Axes named one of ``Wavelength``, ``Energy``, ``Energy Loss``, ``E``, are considered spectral, and quantities
-named one of ``Height``, ``Altitude``, ``Elevation``, ``Depth``, ``Z`` are considered surface. The difference
-between Surface and IntensitySurface stems from the AFM / profilometry origin of MountainsMap. "Surface" has
-the proper meaning of an open boundary of 3d space, whereas "IntensitySurface" is a mere 2D mapping of an arbitrary
-quantity.
+Axes named one of ``Wavelength``, ``Energy``, ``Energy Loss`` or  ``E`` are considered spectral. A quantity named 
+one of ``Height``, ``Altitude``, ``Elevation``, ``Depth`` or ``Z`` is  considered a surface. The difference between 
+Surface and IntensitySurface stems from the AFM / profilometry origin of MountainsMap. "Surface" has its proper 
+meaning of being a 2d-subset of 3d space, whereas "IntensitySurface" is a mere 2D mapping of an arbitrary quantity.
 
 API functions
 ^^^^^^^^^^^^^

rsciio/digitalsurf/_api.py

@@ -2361,15 +2361,16 @@ def file_writer(
     %s
     %s
     set_comments : str , default = 'auto'
-        Whether comments should be a simplified original_metadata ('auto'),
-        exported as the raw original_metadata dictionary ('raw'), skipped ('off'),
-        or supplied by the user as an additional kwarg ('custom').
+        Whether comments should be a simplified version original_metadata ('auto'),
+        the raw original_metadata dictionary ('raw'), skipped ('off'), or supplied 
+        by the user as an additional kwarg ('custom').
     is_special : bool , default = False
-        If True, NaN values in the dataset or integers reaching boundary values are
-        flagged in the export as non-measured and saturating, respectively. If False,
-        those values are kept as-is.
+        If True, NaN values in the dataset or integers reaching the boundary of the 
+        signed int-representation are flagged as non-measured or saturating, 
+        respectively. If False, those values are not flagged (converted to valid points).
     compressed : bool, default =True
-        If True, compress the data in the export file using zlib.
+        If True, compress the data in the export file using zlib. Can help dramatically 
+        reduce the file size.
     comments : dict, default = {}
         Set a custom dictionnary in the comments field of the exported file.
         Ignored if set_comments is not set to 'custom'.
@@ -2386,7 +2387,7 @@ def file_writer(
         Maximum size is 32.0 kB and content will be cropped if this size is exceeded.
     client_zone : bytes, default = b''
         Set arbitrary byte-content in the client_zone field of exported file metadata.
-        Maximum size is 128B and and content will be cropped if this size is exceeded.
+        Maximum size is 128 B and and content will be cropped if this size is exceeded.
     """
     ds = DigitalSurfHandler(filename=filename)
     ds.signal_dict = signal