docs(manual): Fix spelling mistakes

documentation/c02-gettingstarted.sil

@@ -256,7 +256,7 @@ This can be done with:
 Now the \code{sile} command will be available from any directory.
 
 \begin{autodoc:note}
-If you wish you, can skip the install step and use the compiled SILE executable diretly from the source directory.
+If you wish you, can skip the install step and use the compiled SILE executable directly from the source directory.
 As configured above, this will only work from a shell with the CWD set to the SILE source.
 To make it usable from anywhere, you can configure it with the source directory baked in as the installation location.
 

documentation/c03-input.sil

@@ -8,7 +8,7 @@ It is even less true now that 3rd party plugins can add their own input formats.
 
 Hence this chanpter has been renamed.
 The original chapter title was "SILE’s Input Language", as if there was only one.
-The truth is there \em{is} an input syntax we call "SIL", but even that is perhaps best thought of as a structured data systax rather than a unique language.
+The truth is there \em{is} an input syntax we call "SIL", but even that is perhaps best thought of as a structured data syntax rather than a unique language.
 The input strings \code{\\em\{foo\}} in SIL input syntax is 100\% equivalent to \code{<em>foo</em>} in XML input syntax.
 The SIL input syntax is provided as an easier to type alternative than XML which can be a bit verbose and tedious to work with by hand.
 On the other hand if you're handling data written by some other program, XML might be a much better solution.

documentation/c05-packages.sil

@@ -98,7 +98,7 @@ As well as processing text, SILE can also include images.
 
 \section{Text & Characters}
 
-This section covers a range of diffent topics from initial capitals to text transforms, through URL formatting.
+This section covers a range of different topics from initial capitals to text transforms, through URL formatting.
 
 \subsection{dropcaps}
 \status:high

documentation/c06-macroscommands.sil

@@ -17,7 +17,7 @@ that you need to keep entering again and again.
 \define[command=SILE]{\font[family=Gentium Plus]{% Book Basic has no +smcp, but readers don't need to know, since we're only using Book Basic as a holdover from old SILE which did.
 S\lower[height=0.5ex]{I}L\kern[width=-.2em]\raise[height=0.6ex]{\font[features=+smcp]{e}}}}
 For instance, let’s suppose that we want to design a nice little
-“bumpy road” logo for SILE. (Afficionados of T\kern[width=-.1667em]\lower[height=0.5ex]{E}\kern[width=-.125em]X and friends will be familiar with the concept of
+“bumpy road” logo for SILE. (Aficionados of T\kern[width=-.1667em]\lower[height=0.5ex]{E}\kern[width=-.125em]X and friends will be familiar with the concept of
 bumpy road logos.) Our logo will look like this: \SILE. It’s not a great
 logo, but we’ll use it as \SILE’s logo for the purposes of this section.
 

documentation/c08-language.sil

@@ -25,7 +25,7 @@ Language support may include:
 \item{frame advance and writing direction}
 \item{spacing}
 \item{choice of glyphs within a font}
-\item{localization of programatically inserted strings}
+\item{localization of programmatically inserted strings}
 \end{itemize}
 
 For example, Sindhi and Urdu users will expect the Arabic letter \em{heh} (\font[family=LateefGR]{ه}) to combine with other letters in different ways to standard Arabic shaping.
@@ -95,7 +95,7 @@ To implement hyphenation for a new language, first check to see if TeX hyphenati
 
 \section{Localization}
 
-A small handful of strings may be programatically added to documents depending on language, context, and options.
+A small handful of strings may be programmatically added to documents depending on language, context, and options.
 For example by default in English the \autodoc:class{book} class will prepend “Chapter ” before chapter numbers output by the \autodoc:command{\chapter} command.
 These localized strings are managed internally using the Fluent localization system.%
 \footnote{See Project Fluent (\url{https://projectfluent.org}) for details on the data format and uses.}
@@ -180,7 +180,7 @@ SILE aims to conform with the W3G document “Requirements for Japanese Text Lay
 Breaking rules \em{(kinzoku shori)} and intercharacter spacing is fully supported on selecting the Japanese language.
 The easiest way to set up the other elements of Japanese typesetting such as the \em{hanmen} grid and optional vertical typesetting support is by using the \autodoc:class{jplain} or \autodoc:class{jbook} classes.
 For other languages with similar layout requirements, more generic \autodoc:class{tplain} and \autodoc:class{tbook} classes are available that setup the layout elements without also setting the default language and font to Japanese specific values.
-These are also good condidates to use as base classes and extend for more language-specific classes.
+These are also good candidates to use as base classes and extend for more language-specific classes.
 
 \package-documentation{hanmenkyoshi}
 

documentation/c10-classdesign.sil

@@ -169,7 +169,7 @@ end
 
 \subsection{Defining raw handlers}
 
-“Raw handlers” allow packages to register new handlers (or callbacks) for use with the \autodoc:environment{raw} environment, which content is read as-is by SILE, without being interpretated.
+“Raw handlers” allow packages to register new handlers (or callbacks) for use with the \autodoc:environment{raw} environment, which content is read as-is by SILE, without being interpreted.
 This is intended for advanced use cases where you may want to provide a way for users to embed arbitrary content (likely in another syntax), and you will provide the complete parsing and handling for it.\footnote{%
 This may be used to implement a “clever” verbatim environment.
 It is also used, for instance, by the \strong{markdown.sile} 3rd-party collection to embed Markdown or Djot content directly in a (SIL or XML) document.}

documentation/c11-inputoutput.sil

@@ -75,7 +75,7 @@ We must code up a few real functions now.
 \subsection{Content appropriation}
 
 What we first need is to tell SILE how to choose our inputter when it is given a file in our input format.
-The \code{appropriate()} method of our inputter is reponsible for providing the corresponding logic.
+The \code{appropriate()} method of our inputter is responsible for providing the corresponding logic.
 It is a static method (so it does not have a \code{self} argument), and it takes up to three arguments:
 \begin{itemize}
 \item{the round, an integer between 1 and 3.}
@@ -87,10 +87,10 @@ It is expected to return a boolean value, \code{true} if this handler is appropr
 Earlier, we said that inputters were checked in their priority order.
 This was not fully complete.
 Let’s add another piece to our puzzle: Inputters are actually checked orderly indeed, but three times.
-This allows for quick compatiblitity checks to supercede resource-intensive ones.
+This allows for quick compatiblitity checks to supersede resource-intensive ones.
 \begin{itemize}
 \item{Round 1 expects the file name to be checked: for instance, we could base our decision on recognized file extensions.}
-\item{Round 2 expects some portion of the content string to be checked: for instance, we could base our decision on sniffing for some sequence of characters expected to occurr early in the document (or any other content inspection strategy).}
+\item{Round 2 expects some portion of the content string to be checked: for instance, we could base our decision on sniffing for some sequence of characters expected to occur early in the document (or any other content inspection strategy).}
 \item{Round 3 expects the entire content to be successfully parsed.}
 \end{itemize}
 
@@ -178,7 +178,7 @@ In particular, options passed to the \autodoc:command{\include} commands are pas
 
 Outputters usually live somewhere in the \code{outputters/} subdirectory of either where your first input file is located, your current working directory, or your SILE path.
 
-All ouput handlers inherit from a \autodoc:package{base} outputter.
+All output handlers inherit from a \autodoc:package{base} outputter.
 It is an abstract class, providing just one concrete method, and defining a bunch of methods that any actual outputter has to override for the specifics of its target format.
 
 We first need to declare the name of our new outputter, as well as the default file extension for the output file, which will be appended to the base name of the main input file if the user does not provide an explicit output file name on their command line.

documentation/c12-xmlproc.sil

@@ -10,7 +10,7 @@ Since DocDook itself doesn’t specify anything about presentation such as paper
 When you use the \code{-c docbook} command line option to SILE, SILE will use the \autodoc:class{docbook} class in spite of any document declaration.
 In addition, options such as paper size could be set; for example, \code{-O papersize=legal}.
 
-The class initalization for DocBoox isn’t too fancy; it just loads up a couple packages that will get used later.
+The class initialization for DocBoox isn’t too fancy; it just loads up a couple packages that will get used later.
 
 \begin{autodoc:note}
 Much of the example code in this chapter is in SIL format using macros.