wallet/docs/writing_and_editing_documentation.md

---
# katex
title: >-
	Writing and Editing Documentation
...

# Organization

My stuff is currently an enormous pile of disorganized, and thus
inaccessible, documents.

The clean and elegant style of open source documentation always has a
header bar at the top, through which all documents can be accessed.  And a
moderately sized logo and title at the top.  I am thinking a rho, surrounded
by a flaming halo of green blue radial flames, followed by "Rhocoin"

Then a top level menu of five or six items, followed by lower level horizontal menus that depend on which higher level menus was selected.

The best layout I have seen the [wxWidgets style](https://docs.wxwidgets.org/3.0/functions.html){target="_blank"}  which has multiple bars,
and when you clicked on entry in one bar, the lower bars changed.
wxSqlite3 used to have this style. Now, has a [single bar with multilevel drop downs](https://utelle.github.io/wxsqlite3/docs/html/index.html){target="_blank"} , as does the [SQLite3 style](https://sqlite.org/docs.html){target="_blank"} , of which it is a direct copy,
but SQLite3 style lacks a way to handle the enormous number of SQLite3
documents, which can only be handled by a multi level bar, or by a page
full of links

Libsodium, on the other hand, has a [left hand bar with drop downs](https://doc.libsodium.org/secret-key_cryptography){target="_blank"}.  Which
is probably easier to implement, but that there is no documentation locally
installed suggests that it too is in some way server generated.  Apache2 and
nginx similarly, and handle the enormous number of documents by
bringing up pages full of links.  Which is OK, but means you do not have
navigation at your fingertips.]

This layout is in some way automatically generated on the server, which
sucks.  Probably relies on server side include, which is the easiest way to
do it.The documentation needs to be in every install and every repository. 
Thus wxWidgets documentation on the server has nice organizational
style, but on each person's individual installed copy, disorganized crap.

Each bottom level subtree should be a directory, and each html document
in that directory should call the script which generates the horizontal bars
on the path from the root to it.  The bash script that uses pandoc to generate
those documents from the markdown documents in that directory should
also generate the javascript, concatenating all the javascripts of the parent
directories into it.

One tricky bit is that you want the path highlighted.  In which case it is
probably easier for the bash script, which is recursing through the tree of
files and keeps track of the path by which it got there in an enormous
string variable, to insert a direct copy of the header bar into each html file,

The directory name is what appears in the top level bars, and the final bar
is a possibly multiline bar that is the titles of all the documents in the directory
and any subdirectories.

On reflection, we will not use any cleverness to have a single header bar
file that all html files use because each top bar of each html file will b
different, having different items highlighted, and according to its depth in
the tree, a different number of '../' prepended to the links in the top bar.  

Each markdown file and directory in a directory should have a short
human friendly name, which will correspond to the name in the top bar,
and for each directory `foo` there is a should be a file `foo.link` which is the
path from within that directory that will be the file that comes up when
that directory name in the top bar is clicked on.

We code a script runs through each directory twice constructing the
necessary bar, and then inserts it directly as a 'before' element in pandoc.
The script will be in `bash`, to run on all systems, and will use `sed` to
generate the bar, to run on all systems, because every computer system
everywhere has `sed` and `bash`.

# pandoc

Much documentation is in Pandoc markdown, because easier to write. But html
is easier to read, and allows superior control of appearance

To convert Pandoc markdown to its final html form, invoke `Pandoc` by the bash
shell file `./mkdoc.sh`, which generates html.

In the windows 10 environment, shell scripts used  in this project need to be
associated with [Git Bash](libraries/git_bash_undocumented.html) or run from within Git Bash.

If the title in the markdown file is followed by `# katex`, as in
the markdown form of this file, the shell script will tell Pandoc to display
any formulae using katex in the html file.

More precisely, if any of the first three lines in the yaml header specifying
the title at the start of the markdown file are `# katex`, the `./mkdoc.sh`
will tell Pandoc to use katex to display maths formula.

This vast pile of notes is out of control, and writing code and maths in
html leads to intolerable overheads.

Hence markdown, the popular markdown conversion program
being the open source Pandoc.

Markdown converters are apt to throw a flood of incomprehensible html code
into your final document, taking low level html control away from the writer.

Pandoc, however, will allow you to take control.  To integrate html and css
with markdown using Pandoc is a bit like rolling marbles with your
elbows through a cage. One has to work through and around the entry
points that Pandoc gives you, while if you were writing in html you could
just write what you damn well wanted directly, but having done the work,
Pandoc can then ensure it is done for every document in the same style in
the same way, and you can change the final form of every document in the
same way all at once.

Sphinx is very popular and widely used, and written in the far more
accessible language python, but to access the power of html, css, and
JavaScript one must write a Sphinx theme, and the creation of a Sphinx theme
is less than well documented and appears to be subject to change.

Visual Studio Code theoretically does automatic generation of the html
equivalents of markdown files, but I never was able to get it working
satisfactorily.

Pandoc has a number of powerful extensions that allow integration of html and
markdown, among them markdown native mode divs `:::`

```markdown
::: {style="…"}
	…
:::
```

And native mode spans `[…]{style="…"}`

Which extensions do not work correctly in Visual Studio Code.

These can be used to put an anchor in text, but the easiest and most
intelligible way to insert an anchor is as a header.

Pandoc can do a good job of rendering math markdown without invoking
katex, and in such cases, one should generate the html

```bash
fn=filename
 pandoc --toc --eol=lf	--wrap=preserve --from markdown+ascii_identifiers --to html --metadata=lang:en --verbose --include-in-header=./pandoc_templates/header.pandoc --include-before-body=./pandoc_templates/before.pandoc --include-after-body=./pandoc_templates/after.Pandoc -o $fn.html $fn.md
```

Since markdown has no concept of a title, Pandoc expects to find the
title in a yaml inline, which is most conveniently put at the top, which
renders it somewhat legible as a title.

Thus the markdown version of this document starts with:

```markdown
---
title: >-
	Writing and Editing Documentation
# katex
...
```

## Converting html source to markdown source

In bash

```bash
fn=foobar
git mv $fn.html $fn.md && cp $fn.md $fn.html && pandoc -s --to markdown-smart --eol=lf --wrap=preserve --verbose -o $fn.md $fn.html
```

## Math expressions and katex

Pandoc can render most maths markdown without needing katex, for example:
$${e}^{i\pi}+1=0$$
$$a=b+c$$
$$f(x) = x^2$$
$$\sin(\pi/6) = 0.5$$
$$\int_a^b f(x) dx$$
$$\int_a^b \tan(x) dx$$
$$\int \sin(x) dx = \cos(x)$$
$$\sum a_i$$
$$\lfloor{(x+5)÷6}\rfloor = \lceil{(x÷6}\rceil$$
$$\lfloor{(x+5)/6}\rfloor = \lceil{(x/6}\rceil$$
Use `\bigcirc`, not capital O for Omicron $\bigcirc$.  `\Omicron` will not always
compile correctly, but `\ln` and `\log` is more likely to compile correctly than
`ln` and `log`, which it tends to render as symbols multiplied, rather than one
symbol.
$$\ln(1+x)=x-\bigcirc(x^2)$$
$$H(a|b|v)$$

though it is subtly prettier with katex, and some maths expressions will
break Pandoc unless one tells it to use katex.

Some maths, Pandoc needs katex:

$$\sin(\frac{\pi}{6}) = \frac12$$
$$\displaystyle\frac{u(x)}{v(x)}$$
Inline equation $\displaystyle\sum\limits_{i=1}^n i^2 = \frac{n(n+1)(2n+1)}{6}$ text after inline equation

$$\displaystyle\sum\limits_{i} i^2 = \frac{i(i+1)(2i+1)}6$$
The square root of 100 is $\sqrt{100}=10$.\
The cubic root of 64 is $\sqrt[3]{64}=4$
$$\bigg\lfloor\frac{x+5)}{6}\bigg\rfloor = \bigg\lceil{\frac{x}{6}}\bigg\rceil$$

So for documents requiring some heavy maths display, we convert from markdown
to html with, in the bash script `./mkdoc.sh`:

```bash
fn=filename
pandoc --katex=./ --toc --eol=lf  --wrap=preserve --from markdown --to html --metadata=lang:en --verbose --include-in-header=./pandoc_templates/header.pandoc --include-before-body=./pandoc_templates/before.pandoc --include-after-body=./pandoc_templates/after.pandoc -o $fn.html $fn.md
```

The `./` tells `pandoc` to expect to find the files

```bash
./katex.min.css
./katex.min.js
```

That a file needs katex is flagged for `./mkdoc.sh` in the yaml header.

A file that does not need katex has the header:

```markdown
---
title: >-
	Document title
...
```

But if it does need katex, it has the header

```markdown
---
title: >-
	Document title
 # katex
...
```

So that the bash script file `./mkdoc.sh` will tell `Pandoc` to find the katex scripts.

For it offends me to put unnecessary fat in html files.

### overly clever katex tricks

$$k \approx \frac{m\,l\!n(2)}{n}%uses\, to increase spacing, uses \! to merge letters, uses % for comments $$

$$k \approx\frac{m\>\ln(2)}{n}%uses\> for a marginally larger increase in spacing and uses \ln, the escape for the well known function ln $$

$$ \exp\bigg(\frac{a+bt}{x}\bigg)=\huge e^{\bigg(\frac{a+bt}{x}\bigg)}%use the escape for well known functions, use text size sets$$

$$k\text{, the number of hashes} \approx \frac{m\ln(2)}{n}% \text{} for render as text$$

$$\def\mydef#1{\frac{#1}{1+#1}} \mydef{\mydef{\mydef{\mydef{y}}}}%katex macro $$

## Tables

### Pipe table with header and alignment control

Without counting spaces, but without multiline

Pipe table:

| Right | Left | Default | Centre |
|------:|:-----|---------|:----------------------:|
|   12  |  12 |    12   |    12  |
|  123  |  123 |   123   |   the quick brown fox jumped over the lazy dog  |
|    1  |  1 |     Carrian Corporation |     1  |

### And, with less mucking about, alignments

with alignment, without counting spaces, but without multiline

fruit| price
:-----|-----:
apple|2.05
pear|1.37
orange|3.09

### multiline without bothering with pipes

Counting spaces to align.  Only editable in fixed font

This allows multiline, but visual studio code does not like it.  Visual Studio Code only supports tables that can be intelligibly laid out in visual studio code.

-------------------------------------------------------------
 Centered   Default           Right Left
  Header    Aligned         Aligned Aligned
----------- ------- --------------- -------------------------
   First    row                12.0 Example of a row that
                                    spans multiple lines.

  Second    row            5.0      Here's another one. Note
                                    the blank line between
                                    rows.
-------------------------------------------------------------

### The header may be omitted in multiline tables as well as simple tables

Notice the alignment is controlled by the first item in a column

In this table, edited in a fixed font, you are using whitespace and blank lines to lay out  the table.  It is unintellible in a variable width font.

----------- ------- --------------- -------------------------
   First    row            12.0     Example of a row that
                                    spans multiple lines.

  Second    row                 5.0 Here's another one. Note
                                    the blank line between
                                    rows.
----------- ------- --------------- -------------------------

### Grid tables

Allows multiline, and alignment, but visual studio does not like it, and you still have to count those spacees

+---------------+---------------+--------------------+
| Fruit         | Price         | Advantages         |
+===============+==============:+====================+
| Bananas       | $1.34         | - built-in wrapper |
|               |               | - bright color     |
+---------------+---------------+--------------------+
| Oranges       | $2.10         | - cures scurvy     |
|               |               | - tasty            |
+---------------+---------------+--------------------+
| Durian        | $22.10        | - king of fruits   |
+---------------+---------------+--------------------+

Alignments can be specified as with pipe tables, by putting colons at the boundaries of the separator line after the header.

+------------+---------+---------------------+
| Left       |   Right | Centered            |
+:===========+========:+:===================:+
| Bananas    |  $1.34  | - built-in wrapper  |
|            |         | - bright color      |
+------------+---------+---------------------+
| Durian     | $22.10  | - king of fruits    |
+------------+---------+---------------------+

### For headerless tables, the colons go on the top line instead:

+--------------:+:--------------+:------------------:+
| Right         | Left          | Centered           |
+---------------+---------------+--------------------+

# diagrams

The best way to do diagrams is svg and the Visual Studio Code
scalable vector graphics extensions.

I decided to place the data directly inline in markdown because
interfacing scalable vector graphics files (`svg` files) to html can get
complicated, and interfacing the resulting complicated html to
markdown can get more complicated.

Inkscape files are unreadable, and once they are cleaned up,
Inkscape cannot read them.  To (irreversibly) clean up an Inkscape
file, minify it in Visual Studio Code to get rid of all confusing
mystery cruft inserted by Inkscape, edit it back into markdown
compatible form, and reinsert it in the markdown file.

A sequence of straight lines is M point, L point, L point.

Z and z draw a straight line back to the beginning, use in conjunction with
`fill="#red"` , for example `fill="#FF0000"`.  If the line is open, `fill="none"`

H and h draw horizontal lines, V and v vertical lines.  To see which line you are working on, convenient to temporarily begin and end it with a cross, h 3 h-6 h3 v3 v-6 v3

Drawing smooth curves by typing in text is painful and slow, but so
is drawing them in Inkscape.  Inkscape is apt to do a series of C
beziers with sharp corners between them, and when I try to fix the
sharp corners, the bezier goes weird.

If you can get your desired curve with a single `M point c point point point`
that causes the least grief, and gives you a nice smooth curve.

The first point is the starting position, the last point is the end
position.  The direction of the first control point sets the starting
direction, the direction of the second control point sets the end
direction, and how far the control points are out controls how
where the curve changes direction.  If the curve is weird and pathological, there is something funny with your control points.
Some control point positions lead to singularities in the derivative
of the curv but for reasonable control point positions, you get a
nice smooth curve.

Capital letters indicate absolute points, lower case relative points.

Before deciding you need to add additonal points to get the curve
you want, see if you are doing something dumb with your control
points.  You usually are.

If you want a sharp turn coming out, and a smooth curve, then a
sharp curve coming in to the destination, you do not put in a bunch
of intermediate points, you just put your control points close to the
beginning and end.

The further the control point is away from the end of the previous S
curve, the further its influence propagates into the next S curve.
Which can have surprising results if the next S curve is very short, so
that influence of the previous control point propagates far beyond its end.

If you want a smooth and gentle curve, you want the last C or S
control point to be around the middle of the curve, and its
reflection in the next S curve to be around the middle of the next S curve

You only need additional points when you want the curve to go
through a narrow pass, in which case you are going to have a C
curve going to the narrow pass, and an S curve going to the
destination or the next narrow pass.

When you want to join two points, and don't care about the path, use an L straight line

When you want to join two points, and you care about the direction
in which it starts, or the direction in which it finishes, but not both,
use a Q, which gives you one degree of control freedom.

When you want to join two points, and care about the direction it
starts, and the direction it ends, use a C, which gives you two
degrees of control freedom.

When you want to join two points, and care about the direction it
starts, the direction it ends, and you want it to go through a
gateway in the middle, use a C S, which gives you three degrees
of control freedom.  But watch out for the reflection of the last control
point in the C landing somewhere difficult inside the S curve.  If the last control point in the C is further from the end point of the C
than the end point of the S, things can get strange. Sometimes you
want to adjust the behavior of the S curve by moving the last
control point of the previous C or S to the right position.  A distant
previous control point is apt to have a big effect on the following S,
a near control point little effect, but likely to give you an
unpleasantly sharp turn at the join.

``` default
M point c point point point s point point
s point point ... s point
```

Is guaranteed to give you a smooth curve, for reasonably sane
control points, with the curve passing through the second point of
the s, and its direction set by the first point of the s.

You change a control point, the effect is entirely local, does not
propagate up and down the line.

If, however, you have a long move and a short move, your implied control
point is likely to be in a pathological location, in which case you have to
follow an S curve by a C curve, and manually calculate the first point of
the C to be in line with the last two points of the prior curve.

``` default
M point q point point t point t point ... t point
```

Is also guaranteed to give you a nice smooth curve for any
reasonably sane choice of the initial control point and the position
of the t points, but you cannot easily control the direction the curve
takes through the points.  Changing the control point of the first q
will result in things snaking all down the line, and changing any of
the intermediate t points will change the the direction the curve
takes through all subsequent t points, sometimes pushing the curve
into pathological territory where bezier curves give unexpected and
nasty results.

Scalable vector graphics are dimensionless, and the `<svg>` tag's
height, width, and ViewBox properties translate the dimensionless
quantities into pixels.  The graphics default to fixed aspect ratio, and
anything outside the viewbox is not drawn.  To adjust your image's
position within the viewbox, you put everything into a single big
group, and apply a translate to that group.

The enormous advantage of scalable vector graphics is that it handles
repetitious items in diagrams beautifully, because you can define an item
by reference to another item, thus very large hierarchical structure can be
defined by very small source code.

<svg
	xmlns="http://www.w3.org/2000/svg"
	width="29em"  height="12em"
	viewBox="40 60 60 50"
	style="background-color:ivory">
	<g  id="startblocks"
		font-family="'Times New Roman'" font-size="5"
		font-weight="400"
		stroke-width="2"
		style="text-decoration:underline; cursor:pointer;" >
		<line x1="22" y1="70" x2="28" y2="100" stroke="lightgrey"/>
		<rect style="fill:#FFFF00;"
			x="12" y="64" width="36" height="20">
			<animate attributeType="XML" attributeName="y"
				from="64" to="110"
				dur="5s" repeatCount="2" restart="always" />
		</rect>
		<text style="fill:blue;"  x="14" y="74">
			<animate attributeType="XML" attributeName="y"
				from="74" to="120"
				dur="5s" repeatCount="2" restart="always" />
			start animation
		</text>
	</g>
	<rect x="60" y="64" width="20" height="20">
		<animate attributeType="XML" attributeName="y"
			from="64" to="120"
			dur="3s" repeatCount="5" restart="whenNotActive"/>
		<animate attributeType="XML" attributeName="x"
			from="60" to="0"
			dur="3s" repeatCount="5" restart="whenNotActive"/></rect>
	<g
		font-family="'Times New Roman'" font-size="5"
		font-weight="400"
		stroke-width="2">
		<path fill="none" stroke="#00f000"
			d="M14 101,  c40 -20, 30 -56, 54 -18,  s60 15, 40 15  c -20,0  -10,-20  0,-20 q 5,0 10,10" />
		<ellipse cx="60" cy="85" rx="12" ry="5" style="fill:red" />
		<text  x="60" y="82" text-anchor="middle"  style="fill:#A050C0;" >
			A simple scalable vector graphic
			<tspan x="60" dy="8">
				directly embedded in markdown.
			</tspan>
		</text>
	</g>
</svg>

<script>
	document.getElementById("startblocks").addEventListener
	(
		"click", evt =>
		{
			document.querySelectorAll("animate").forEach
			(
				element =>
				{
					element.beginElement();
				}
			);
		}
	);
</script>

```svg
<svg
	xmlns="http://www.w3.org/2000/svg"
	width="29em"  height="12em"
	viewBox="40 60 60 50"
	style="background-color:ivory">
	<g  id="startblocks"
		font-family="'Times New Roman'" font-size="5"
		font-weight="400"
		stroke-width="2"
		style="text-decoration:underline; cursor:pointer;" >
		<line x1="22" y1="70" x2="28" y2="100" stroke="lightgrey"/>
		<rect style="fill:#FFFF00;"
			x="12" y="64" width="36" height="20">
			<animate attributeType="XML" attributeName="y"
				from="64" to="120"
				dur="5s" repeatCount="2" restart="always" />
		</rect>
		<text style="fill:blue;"  x="14" y="74">
			<animate attributeType="XML" attributeName="y"
				from="74" to="130"
				dur="5s" repeatCount="2" restart="always" />
			start animation
		</text>
	</g>
	<rect x="60" y="64" width="20" height="20">
		<animate attributeType="XML" attributeName="y"
			from="64" to="120"
			dur="5s" repeatCount="3" restart="whenNotActive"/>
	</rect>
	<g
		font-family="'Times New Roman'" font-size="5"
		font-weight="400"
		stroke-width="2">
		<path fill="none" stroke="#00f000"
			d="M14.629 101.381c25.856-20.072 50.69-56.814
			54.433-18.37 3.742 38.443 40.484 15.309 40.484 15.309"/>
		<ellipse cx="60" cy="85" rx="12" ry="5" style="fill:red" />
		<text  x="60" y="82" text-anchor="middle"  style="fill:#A050C0;" >
			A simple scalable vector graphic
			<tspan x="60" dy="8">
				directly embedded in markdown.
			</tspan>
		</text>
	</g>
</svg>
```

```script
<script>
	document.getElementById("startblocks").addEventListener
	(
		"click", evt =>
		{
			document.querySelectorAll("animate").forEach
			(
				element =>
				{
					element.beginElement();
				}
			);
		}
	);
</script>

# tables

 <table border="1" cellpadding="6" cellspacing="0" width="95%">
      <tbody>
        <tr>
          <td colspan="2" style="background-color: #99CC66;
	text-align:center;">May Scale of monetary hardness </td>
        </tr>
        <tr>
          <td style="text-align:center;"><b> Hardness</b> </td>
          <td> <br/>
          </td>
        </tr>
        <tr>
          <td colspan="2" style=" text-align:center;">Hard</td>
        </tr>
        <tr>
          <td class="center"><b>1</b></td>
          <td>Street cash, US dollars</td>
        </tr>
        <tr>
            <td class="center"><b>2</b></td>
          <td>Street cash, euro currencies, japan</td>
        </tr>
        <tr>
          <td class="center"><b>3</b></td>
          <td>Major crypto currencies, such as Bitcoin and Monaro</td>
        </tr>
        <tr>
          <td class="center"><b>4</b></td>
          <td>Street cash, other regions</td>
        </tr>
        <tr>
          <td class="center"><b>5</b></td>
          <td>Interbank transfers of various sorts (wires etc),
              bank checks</td>
        </tr>
        <tr>
          <td class="center"><b>6</b></td>
          <td>personal checks</td>
        </tr>
        <tr>
          <td class="center"><b>7</b>
            </td>
          <td>Consumer-level electronic account transfers (eg
              bPay)</td>
        </tr>
        <tr>
          <td class="center"><b>8</b></td>
          <td>Business-account-level retail transfer systems</td>
        </tr>
        <tr>
          <td colspan="2" style=" text-align:center;">Soft</td>
        </tr>
        <tr>
          <td class="center"><b>9</b></td>
          <td>Paypal and similar 'new money' entities, beenz</td>
        </tr>
        <tr>
         <td class="center"><b>10</b></td>
          <td>Credit cards</td>
        </tr>
      </tbody>
    </table>

```