In https://github.com/OpenTechStrategies/ots-doctools/pull/10,
@choeppler points out (#pullrequestreview-425924575) that the "OTSDIR"
environment variable should not be required to be set, since only
"OTS_DOCTOOLS_DIR" is documented, and that furthermore if we are going
to check paths under "OTSDIR" we should at least do it in the same
order relative to "OTS_DOCTOOLS_DIR" that 'Makefile.docspecific' uses.

This commit is his suggested patch from that PR review.  (Note that
the commits in that PR are actually already applied.  There must have
been a rebasing somewhere along the way, as they all have different
commit IDs in master than they do in the PR.)

I don't actually use the venv, and I was tired of it littering.
Virtual environments are probably best left to the user to configure,
and not for us to force on the user.  It's still nice to have it as a
backup, but if the user has a way to satisfy those dependencies
without our intervention, don't intervene.

There are a few ways to supply the python submodules that aren't in a
local venv.  One might install systemwide, use direnv, or use a
centralized venv for all of ots, etc.  I use direnv, but this change
makes room for any scheme a user might want.  We force our own venv
only as a last resort.

Explain what reference system we're using in case somebody else is
interested in the plugin.

  * Detect inkscape version of 1.0 rc 1 or later and add some tex to
    call inkscape using new-style command line parameters.

  * Add a preambles loop to the base jinja template so we have an easy
    way to add preamble sections that doesn't require clobbering the
    existing preamble items

  * Add a dump function to pipeline.py so we can dump our output and
    inspect it during debugging.

As promised in commit db47b65d.

Since commit 018499ec, when the bug-detection plugin is enabled
(e.g. "bugs: True" in the header) then on detecting a bug in the
document we stop the build, unless in draft mode ("draft: True").

There are thus three ways to fix such a build:

  1) Fix whatever the bug is in the document.
  2) Turn on draft mode.
  3) Turn off bug-detection mode.

Since our bug-detection module is not perfect, (1) is not always an
option because there might not actually be a bug in the document.
That's what happened in this case: the module's attempt to detect
proper formatting of footnotes by looking for the leading backslash
(e.g., "\footnote" instead of "footnote") cries a false positive if
the document uses "\begin{footnotesize} ... \end{footnotesize}" to set
the font size.

I'll improve that bug-detection case in a subsequent commit.  In the
meantime, this commit improves the error message to inform the user
about possibilities (2) and (3), which are not otherwise obvious.

This fixes the problems described in issue #11, but is not a solution
that anyone should invite home to dinner.  See issue #15 for details.

Before this change, a section would have a small (5pt) title size, but
then subsections within it would have a larger title size -- I don't
know exactly what size, because it was some LaTeX default, but it was
clearly larger than 5pt in any case.

Probably the reason we never noticed this before is that our contracts
tended not to have subsections.  But then we wrote one that included
an SOW in the contract, and the SOW's subsections looked all wonky:
their title lines were larger than those of the containing sections.
This fixes the problem; I know not whether it introduces new problems.

This follows up to commit 018499ec, which introduced a pytest import.

This plugin provides general infrastructure for issuing warnings and
errors upon finding certain regexes. Right now, it just looks to see
that footnotes are formatted with the preceding slash.

The plugin has tests.

Karl called these build strings.  Much better name.

We had fields labelled svn and git, but no real explanation for them
in the string names, so I made them more explicitly refer to the
doctools and ots repos.

This undoes one part of commit 22ff9b53963f, at least for now.  The
ultimate decision is still up for discussion.  Maybe little solid
OTS-green dots as bullet points instead?

After we build a pdf, it is sometimes useful to attach some
information to the built file.  Here we do that as a YAML-formatted
block of lines appended to the PDF and marked in PDF syntax as
comments.  Our PDFs now carry some machine-readable metadata.

I've never liked the old letterhead styling.  This improves things a
bit.  This commit includes cc-licensed noun project icons.  I'll buy a
license to them so we don't have to include attribution on every doc
we send out.  We should consider doing attribution anyway when we can.

This might be useful for diffing against when your doc suddenly
doesn't build and you don't know why.  This doesn't save all the files
that go into making the doc.  It would be interesting to try to
snapshot them in some way.  It might even be interesting to collect
all the various files from all over and stik them in a dir so that
every build also makes a minimal one-dir version for slinging around.
Alas, this does none of that.