add spell checker in CI/CD and Makefile

applications/NXapm.nxdl.xml

@@ -84,7 +84,7 @@
         is considered as a narrow synonym for crystal defects.
 
         The aim of the NXapm application definition is to provide a general yet specific enough
-        solution to serialize artifacts for virtually all atom probe and field-ion microcopy experiments.
+        solution to serialize artifacts for virtually all atom probe and field-ion microscopy experiments.
 
         Before summarizing the design of the base classes and the parts of the NXapm application definition,
         it is worthwhile to recall and distinguish concepts that are related to atom extraction
@@ -187,7 +187,7 @@
         NXapm defines constraints on the existence and cardinality of concepts and its concept branches but seeks to
         offer a compromise. The key design pattern followed is that most branches are made optional or at most recommended
         but their child concepts are conditionally required. Thereby, NXapm can cover a variety of simple but also complex
-        use cases. An example of this parent-optional-but-childs-stronger-restricted design is the combination of the
+        use cases. An example of this parent-optional-but-children-stronger-restricted design is the combination of the
         optional group ``measurement`` with its required child ``measurement/instrument``:
         Users which report simulations are not forced to document the instrument but users which have characterized
         a specimen are motivated to report about the instrument. They are though not  necessarily required to report all
@@ -203,7 +203,7 @@
         events that can be time-stamped individually.
         Each instance of a group ``measurement/eventID`` contains ``measurement/instrument`` whose purpose is to
         store those specific state and settings of the instrument that was present during the collection of the event.
-        Thereby, changing conditions such as compaigns with different target detection rate can be stored.
+        Thereby, changing conditions such as campaigns with different target detection rate can be stored.
 
         Noteworthy, such an approach of the atom probe detecting groups of events and storing these as groups has also
         been in use in the proprietary software via CamecaRoot, a set of customized data structures and file formats that use
@@ -215,7 +215,7 @@
         considered best practice by AMETEK/Cameca, ``raw_data`` for delay-line timing data, ``hit_finding`` for details of the
         hit finding algorithm, ``hit_spatial_filtering`` a process that filters hits of too low quality and those laying outside the about
         to be computed reconstruction volume. Furthermore, group ``voltage_and_bowl`` offers a place for documenting calibrations
-        and processing non-linearities. Group ``mass_to_charge_conversion`` is used to document the mass calibration and the
+        and processing nonlinearities. Group ``mass_to_charge_conversion`` is used to document the mass calibration and the
         conversion from time-of-flight to mass-to-charge-state-ratio values.
 
         Finally, the groups ``reconstruction`` and ``ranging`` were designed to match and document the classical approaches how
@@ -979,7 +979,7 @@
 
                         In the case of an open-source instrument, like P. Felfer's Oxcart or G. Schmitz's
                         M-TAP instruments, also use program1, program2, ... with program1 representing
-                        the control software e.g. `M. Monajem and P. Felfer pyCCAPT <https://pyccapt.readthedocs.io/en/latest/>`_.
+                        the control software e.g. `M. Monajem and P. Felfer PYCCAPT <https://pyccapt.readthedocs.io/en/latest/>`_.
                         Further instances (program2, ...) can be used to list the dependencies, the
                         python virtual environment.
                     </doc>

applications/NXarchive.nxdl.xml

@@ -3,7 +3,7 @@
 <!--
 # NeXus - Neutron and X-ray Common Data Format
 # 
-# Copyright (C) 2008-2024 NeXus International Advisory Committee (NIAC)
+# Copyright (C) 2008-2025 NeXus International Advisory Committee (NIAC)
 # 
 # This library is free software; you can redistribute it and/or
 # modify it under the terms of the GNU Lesser General Public

applications/NXcanSAS.nxdl.xml

@@ -3,7 +3,7 @@
 <!--
 # NeXus - Neutron and X-ray Common Data Format
 # 
-# Copyright (C) 2012-2024 NeXus International Advisory Committee (NIAC)
+# Copyright (C) 2012-2025 NeXus International Advisory Committee (NIAC)
 # 
 # This library is free software; you can redistribute it and/or
 # modify it under the terms of the GNU Lesser General Public
@@ -72,7 +72,7 @@
         * NXcanSAS is for reduced SAS data and metadata to be stored together in one file.
         * *Reduced* SAS data consists of :math:`I(\vec{Q})` or :math:`I(|\vec{Q}|)`
         * External file links are not to be used for the reduced data. 
-        * A good practice/practise is, at least, to include a reference to how the data was acquired and processed.  Yet this is not a requirement.
+        * A good practice is, at least, to include a reference to how the data was acquired and processed.  Yet this is not a requirement.
         * There is no need for NXcanSAS to refer to any raw data.
 
         The canSAS data format has a structure similar to NeXus, not identical.

applications/NXdirecttof.nxdl.xml

@@ -3,7 +3,7 @@
 <!--
 # NeXus - Neutron and X-ray Common Data Format
 # 
-# Copyright (C) 2008-2024 NeXus International Advisory Committee (NIAC)
+# Copyright (C) 2008-2025 NeXus International Advisory Committee (NIAC)
 # 
 # This library is free software; you can redistribute it and/or
 # modify it under the terms of the GNU Lesser General Public

applications/NXem.nxdl.xml

@@ -89,7 +89,7 @@
         relevant. NXem defines constraints on the existence and cardinality of concepts and its concept branches
         but seeks to offer a compromise. The key design pattern followed is that most branches are made optional
         or at most recommended but their child concepts conditional required. Thereby, NXem can cover a variety
-        of simple but also complex use cases. An example of this parent-optional-but-childs-stronger-restricted design
+        of simple but also complex use cases. An example of this parent-optional-but-children-stronger-restricted design
         is the combination of the optional group ``measurement`` with its required child
         ``measurement/instrument``: Users which report simulations are not forced to document the instrument
         but users which have characterized a sample are motivated to report about the instrument. They are though not
@@ -407,8 +407,8 @@
 
                     The information is recorded to qualify if the beam used was likely
                     able to shine through the specimen. For scanning electron microscopy,
-                    in many cases the specimen is typically thicker than what is
-                    illuminatable by the electron beam.
+                    in many cases the specimen is typically thicker than what is illuminable
+                    by the electron beam.
 
                     In this case the value should be set to the actual thickness of the specimen
                     viewed for an illumination situation where the nominal surface normal of the

applications/NXlauetof.nxdl.xml

@@ -3,7 +3,7 @@
 <!--
 # NeXus - Neutron and X-ray Common Data Format
 # 
-# Copyright (C) 2008-2024 NeXus International Advisory Committee (NIAC)
+# Copyright (C) 2008-2025 NeXus International Advisory Committee (NIAC)
 # 
 # This library is free software; you can redistribute it and/or
 # modify it under the terms of the GNU Lesser General Public

applications/NXmx.nxdl.xml

@@ -3,7 +3,7 @@
 <!--
   # NeXus - Neutron and X-ray Common Data Format
   #
-  # Copyright (C) 2013-2024 NeXus International Advisory Committee (NIAC)
+  # Copyright (C) 2013-2025 NeXus International Advisory Committee (NIAC)
   #
   # This library is free software; you can redistribute it and/or
   # modify it under the terms of the GNU Lesser General Public

applications/NXxps.nxdl.xml

@@ -142,7 +142,7 @@
                     <doc>
                         Reference to the transformation describing the direction of the beam
                         relative to a defined coordinate system.
-
+                        
                         Should point to /entry/instrument/beam_probe/transformations/beam_direction.
                     </doc>
                 </field>
@@ -199,7 +199,8 @@
                         </attribute>
                         <attribute name="depends_on">
                             <doc>
-                                This should point to the coordinate system defined in /entry/xps_coordinate_system.
+                                This should point to the coordinate system defined in
+                                /entry/xps_coordinate_system.
                             </doc>
                         </attribute>
                     </field>
@@ -251,7 +252,8 @@
                     </field>
                     <field name="analyzer_take_off_azimuth_angle" type="NX_NUMBER" units="NX_ANGLE">
                         <doc>
-                            Azimuthal rotation of the analyzer from the y-direction defined by the sample stage.
+                            Azimuthal rotation of the analyzer from the y-direction defined by the sample
+                            stage.
                         </doc>
                         <attribute name="transformation_type">
                             <enumeration>
@@ -265,7 +267,8 @@
                         </attribute>
                         <attribute name="depends_on">
                             <doc>
-                                This should point to the coordinate system defined in /entry/xps_coordinate_system.
+                                This should point to the coordinate system defined in
+                                /entry/xps_coordinate_system.
                             </doc>
                         </attribute>
                     </field>
@@ -481,7 +484,7 @@
                                 Area of the peak.
                             </doc>
                         </field>
-                         <field name="width" type="NX_NUMBER" units="NX_ENERGY" optional="true">
+                        <field name="width" type="NX_NUMBER" units="NX_ENERGY" optional="true">
                             <doc>
                                 Width of a peak at a defined fraction of the peak height.
 
@@ -578,7 +581,7 @@
                                     modeling the XPS background in situations where the background is integrated from the peak
                                     intensities at each binding energy to higher kinetic energies. It is useful when fitting the
                                     background in spectra that display significant low-energy tailing or when the background
-                                    exhibits a non-linear rise with binding energy.
+                                    exhibits a nonlinear rise with binding energy.
 
                                     The model incorporates the notion of electron energy loss and the behavior of the photoelectrons
                                     as they travel through the material and lose energy. It is a more sophisticated background
@@ -708,7 +711,8 @@
                 </field>
                 <field name="sample_normal_tilt_azimuth_angle" type="NX_NUMBER" units="NX_ANGLE">
                     <doc>
-                        Azimuthal rotation of the sample from the y-direction defined by the sample stage.
+                        Azimuthal rotation of the sample from the y-direction defined by the sample
+                        stage.
                     </doc>
                     <attribute name="transformation_type">
                         <enumeration>
@@ -722,7 +726,8 @@
                     </attribute>
                     <attribute name="depends_on">
                         <doc>
-                            This should point to the coordinate system defined in /entry/xps_coordinate_system.
+                            This should point to the coordinate system defined in
+                            /entry/xps_coordinate_system.
                         </doc>
                     </attribute>
                 </field>

base_classes/NXatom.nxdl.xml

@@ -191,7 +191,7 @@
     <field name="nuclide_list" type="NX_UINT" units="NX_UNITLESS">
         <doc>
             Table which decodes the entries in nuclide_hash into a human-readable matrix
-            instances for either nuclids or elements. Specifically, the first row specifies the
+            instances for either nuclides or elements. Specifically, the first row specifies the
             nuclide mass number. When the nuclide_hash values are used this means
             the row should report the sum :math:`Z + N` or 0. The value 0 documents that
             an element from the IUPAC periodic table is meant.

base_classes/NXattenuator.nxdl.xml

@@ -3,7 +3,7 @@
 <!--
 # NeXus - Neutron and X-ray Common Data Format
 # 
-# Copyright (C) 2008-2024 NeXus International Advisory Committee (NIAC)
+# Copyright (C) 2008-2025 NeXus International Advisory Committee (NIAC)
 # 
 # This library is free software; you can redistribute it and/or
 # modify it under the terms of the GNU Lesser General Public

base_classes/NXbeam.nxdl.xml

@@ -55,7 +55,7 @@
 
         Note that ``incident_wavelength``, ``incident_energy``, and related fields can be a scalar values or arrays, depending on the use case.
         To support these use cases, the explicit dimensionality of these fields is not specified, but it can be inferred
-        by the presense of and shape of accompanying fields, such as incident_wavelength_weights for a polychromatic beam.
+        by the presence of and shape of accompanying fields, such as incident_wavelength_weights for a polychromatic beam.
         </doc>
     <field name="distance" type="NX_FLOAT" units="NX_LENGTH">
         <doc>Distance from sample. Note, it is recommended to use NXtransformations instead.</doc>

base_classes/NXcalibration.nxdl.xml

@@ -3,7 +3,7 @@
 <!--
 # NeXus - Neutron and X-ray Common Data Format
 #
-# Copyright (C) 2024-2024 NeXus International Advisory Committee (NIAC)
+# Copyright (C) 2024-2025 NeXus International Advisory Committee (NIAC)
 #
 # This library is free software; you can redistribute it and/or
 # modify it under the terms of the GNU Lesser General Public
@@ -126,11 +126,11 @@
         <doc>
             Fit coefficients to be used in ``fit_formula_description``.
 
-            As an example, for non-linear energy calibrations, e.g. in a time-of-flight (TOF) detector, a polynomial 
+            As an example, for nonlinear energy calibrations, e.g. in a time-of-flight (TOF) detector, a polynomial
             function is fitted to a set of features (peaks) at well defined energy positions to determine
             E(TOF). Here we can store the fit coefficients for that procedure.
         </doc>
-        <field name="aN" nameType="partial" type="NX_NUMBER">
+        <field name="aN" type="NX_NUMBER" nameType="partial">
             <doc>
                 Use a0, a1, ..., an for the coefficients of a polynomial fit, corresponding to the values in the
                 ``fit_formula_description``.
@@ -140,17 +140,17 @@
             <doc>
                 For linear calibration. Scaling parameter.
                 This should yield the relation `calibrated_axis` = (`original_axis` + `offset`) * `scaling_factor`.
-
-                For a more detailed description of scaling factors, see 
+                
+                For a more detailed description of scaling factors, see
                 :ref:`/NXdata/FIELDNAME_scaling_factor &lt;/NXdata/FIELDNAME_scaling_factor-field&gt;`.
             </doc>
         </field>
         <field name="offset" type="NX_FLOAT" units="NX_ANY">
             <doc>
                 For linear calibration. Offset parameter.
                 This should yield the relation `calibrated_axis` = (`original_axis` + `offset`) * `scaling_factor`.
-
-                For a more detailed description of offset, see 
+                
+                For a more detailed description of offset, see
                 :ref:`/NXdata/FIELDNAME_offset &lt;/NXdata/FIELDNAME_offset-field&gt;`.
             </doc>
         </field>
@@ -159,19 +159,19 @@
         <doc>
             Here we can store a description of the formula used for the fit function.
 
-            For polynomial fits, use a0, a1, ..., an for the coefficients, corresponding to the values in the 
+            For polynomial fits, use a0, a1, ..., an for the coefficients, corresponding to the values in the
             coefficients group. Use x0, x1, ..., xm for the mth position in the `original_axis` field.
-
+            
             If there is the symbol attribute specified for the `original_axis` this may be used instead of x.
             If you want to use the whole axis use `x`.
-
+            
             Alternate axis can also be available as specified by the `fit_formula_inputs` group.
             The data should then be referred here by the `SYMBOL` name, e.g., for a field
             name ``my_field`` in ``fit_formula_inputs``, it should be referred here by ``my_field`` or ``my_field0``
             if you want to read the zeroth element of the array.
         </doc>
     </field>
-    <field name="mapping_MAPPING" nameType="partial" type="NX_FLOAT" >
+    <field name="mapping_MAPPING" type="NX_FLOAT" nameType="partial">
         <doc>
             Mapping data for calibration.
 

base_classes/NXcg_parallelogram.nxdl.xml

@@ -65,7 +65,7 @@
 
         An optimal bounding box is a common data object which provides the best, i.e.
         most tightly fitting box about an arbitrary object. In general such boxes are
-        rotated. Other than in 3D dimensions, the rotation calipher method offers
+        rotated. Other than in 3D dimensions, the rotation caliper method offers
         a rigorous approach to compute an optimal bounding box to a point set in 2D.
     </doc>
     <!--qualifiers and properties of parallelograms-->

base_classes/NXcomponent.nxdl.xml

@@ -74,7 +74,7 @@
             via the NXtransformations group.
 
             NeXus positions components by applying a set of translations and rotations
-            to the component starting from 0, 0, 0. The order of these operations
+            to apply to the component starting from 0, 0, 0. The order of these operations
             is critical and forms what NeXus calls a dependency chain. The depends_on
             field defines the path to the top most operation of the dependency chain or the
             string "." if located in the origin. Usually these operations are stored in a

base_classes/NXelectromagnetic_lens.nxdl.xml

@@ -26,7 +26,7 @@
         Base class for an electro-magnetic lens or a compound lens.
 
         For :ref:`NXtransformations` the origin of the coordinate system is placed
-        in the center of the lens its polepiece, pinhole, or another point of reference.
+        in the center of the lens its pole piece, pinhole, or another point of reference.
         The origin should be specified in the :ref:`NXtransformations`.
 
         For details of electro-magnetic lenses in the literature see e.g.

base_classes/NXem_ebsd.nxdl.xml

@@ -78,7 +78,7 @@
         From this point onwards typically the microscope runs automatically.
 
         Diffraction pattern get collected until the queue finishes or gets interrupted by
-        either errors or arrival at the end of the users' allocated timeslot at the instrument.
+        either errors or arrival at the end of the users' allocated time slot at the instrument.
 
         Kikuchi pattern (EBSP) are usually indexed on-the-fly. These patterns are the raw data.
         Once indexed, these patterns are often not stored.