Rewrite footnotes section. Fix typos.

.vscode/settings.json

@@ -0,0 +1,3 @@
+{
+    "grammarly.config.documentDialect": "british"
+}

chapters/copyediting/16-cop-metadata.qmd

@@ -447,7 +447,7 @@ keywords:
 
 Each item in the list is on a separate line, starting with a dash (`-`). 
 The dashes are aligned with the field's name (`keyword` here). Quotation
-marks can be used, as with one-line text values [@ec-one-line-text-values].
+marks can be used, as with one-line text values [@sec-one-line-text-values].
 
 An alternative, shorter way to enter a list of one-line values is to 
 use square brackets and commas, as in:

chapters/copyediting/161-cop-title-and-subtitle.qmd

@@ -1,7 +1,7 @@
 # Title and subtitle
 
-Title and (optionally) subtitle of an article are 
-entered in the metadata `title` and `subtitle` field:
+The title and, optionally, the subtitle of an article are 
+entered in the metadata `title` and `subtitle` fields:
 
 ``` yaml
 title: The Solution to the Problem that Plagued Everyone
@@ -20,8 +20,8 @@ The `title` and `subtitle` fields should *not* contain explicit linebreaks.
 (See @sec-linebreaks-genuine-visual-explicit on what explicit linebreaks are.)
 Not only it's best to let the reader's device set the linebreaks in 'fluid'
 outputs (HTML, EPUB), but these fields are also used for the table of contents
-and to send information to bibliographic database. They should thus be free
-or unnecessary formatting.
+and to send information to a bibliographic database. They should thus be free
+of unnecessary formatting.
 
 Sometimes, however, you need alternative forms of the title:
 

chapters/copyediting/162-cop-author-information.qmd

@@ -1,10 +1,11 @@
 # Author metadata
 
-**Requires extension: scholarly-metadata**.
+*Requires extension*: The `scholarly-metadata.lua` filter.
 
 The `author` field is a list, each item corresponding to 
 one author. Each item has `name`, `email`, `institute` fields, and 
-one author (the corresponding author) has `correspondence: true`:
+one author (the corresponding author) has a field `correspondence`
+set to `true`:
 
 ``` yaml
 author: 
@@ -19,7 +20,7 @@ author:
 
 Note that there is a dash (`-`) before the first line (`name` field) of each
 author, and that all the other lines for that author are indented to align 
-with that field [see @cop-metadata-lists-maps for background].
+with that field [see @sec-cop-metadata-lists-maps for background].
 
 ## Corresponding author
 
@@ -30,7 +31,7 @@ for that article.
 ## Institutions
 
 Institutions can be entered on one line, separated by commas, or as a list. 
-The two following declaration are equivalent:
+The two following declarations are equivalent:
 
 ```yaml
   institute: Princeton, Yale
@@ -70,7 +71,7 @@ author:
   institute: bedford
 ```
 
-Here `kcl`, `bedford` are used as internal identifiers to associate authors
+Here `kcl` and `bedford` are used as internal identifiers to associate authors
 with their affiliations---they won't be printed. Note that when an author
 has several, the institution identifiers should be listed in brackets, 
 separated by commas: `[kcl, bedford]`. When they have only one, the brackets 
@@ -96,7 +97,7 @@ See the [scholarly-metadata](https://github.com/pandoc/lua-filters/tree/master/s
 ## Multiple short institute names
 
 If an author's institute includes multiple short acronyms, e.g. "ENS, CNRS, EHESS" they may look awkward in the article signature, depending on how your journal template formats it. See your journal template's guidelines 
-on whether to handle these cases in a special manner. 
+on whether to handle these cases specially. 
 
 ## Author in page headers and table of contents
 
@@ -107,4 +108,3 @@ headers and the table of contents.
 Your journal template should provide extra fields for
 this. Dialectica uses `author-toc` and `author-header`,
 for instance. See your journal template's guidelines.
-

chapters/copyediting/163-cop-abstract-keywords-acknowledgments.qmd

@@ -61,7 +61,7 @@ Alternatively, you can enter abstract, acknowledgments,
 and keywords as metadata fields `abstract`, `thanks` and
 `keywords`, respectively. The `keywords` fields must be a list.
 As the other two are typically multiple lines long, they are
-better entered as text blocks [see @ssec-metadata-text-block-values]. 
+better entered as text blocks [see @sec-metadata-text-block-values]. 
 Make sure you indent each line of text blocks properly, without getting
 confused by genuine vs merely apparent linebreaks 
 [see @sec-linebreaks-genuine-visual-explicit]. To illustrate,