Still bikeshedding those diagrams.
Waste of time
This commit is contained in:
reaction.la
parent
b178405c44
commit
c3fa8fe004
@ -262,11 +262,6 @@ information from the peer that has the node with more children.
|
||||
style="background-color:ivory"
|
||||
stroke-width="1"
|
||||
stroke-linecap="round" >
|
||||
<!--
|
||||
viewBox="0 170 220 140"
|
||||
viewBox="10 216 100 59"
|
||||
viewBox="70 192 100 59"
|
||||
-->
|
||||
<g font-family="'Times New Roman'" font-size="10"
|
||||
font-weight="400" fill-rule="evenodd" fill="black" >
|
||||
<g id="blockchain_id" >
|
||||
@ -276,24 +271,24 @@ style="background-color:ivory"
|
||||
</text>
|
||||
</g>
|
||||
<path stroke="#0D0" fill="none" d="
|
||||
M15,238 c28,-12 -12,20 -12,28 S10,271 9,265
|
||||
M14,237 c29,-14 3,14 0,19 s6,3 6,-2
|
||||
M13,236 c30,-22 10,18 28,2
|
||||
M11,236 c30,-36 64,2 70,-14
|
||||
M9,236 c24,-36 55,-28 84,-28 s70,6 70,-9
|
||||
M11,236 c30,-36 64,2 70,-14
|
||||
M13,236 c20,-16 22,-6 22,0 c 0,3 0,6.3 2,6.3 q 2,0 3,-3.5
|
||||
M14,237 c29,-14 4,12 2,15c -2,3 -1,6.5 1,6.5 q 2,0 3,-3.5
|
||||
M15,238 c24,-10 -11,20.5 -11,28.5c -0,2 1,4 2,4 q 2,0 3,-4
|
||||
"/>
|
||||
<g id="balanced merkle tree" fill="none">
|
||||
<path stroke="#F00" d="
|
||||
M201,238 c16,-24 -12,51 6.7,28
|
||||
M164,200 c12,-26 30,60 37,38
|
||||
M164,200 c14,-26 1,78 17,54
|
||||
M164,200 c16,-26 -11,94 5.6,66
|
||||
M201,238 q 1,-4 4,-4 c6,0 -8,36.5 -2,36.5 q 2,0 3,-4
|
||||
M164,200 c1,-4 10,-6 16,-6 c22,0 10,48 17,48 q 2,0 3,-3.5
|
||||
M164,200 c2,-3 4,-4 10,-4 c22,0 -7,62 3,62 q 2,0 3,-3.5
|
||||
M164,200 c2,-2 2,-2.3 6,-2.3 c16,0 -12,73 -4,73 q 2,0 3,-4
|
||||
"/>
|
||||
<g id="height_4_tree" >
|
||||
<path stroke="#F00" d="
|
||||
M81,222 c14,-22 30,34 36.6,16
|
||||
M81,222 c14,-22 5,50 16.6,33
|
||||
M81,222 c14,-22 -10,68 5.6,45
|
||||
M82,221 c1,-4 6,-6 16,-6 c18,0 10, 27 16,27 q 2,0 3,-3
|
||||
M82,221 c2,-3 2,-4 10,-4 c18,0 12, 41.5 18,41.5 q 2,0 3,-3.5
|
||||
M82,221 c2,-2 2,-2.3 6,-2.3 c18,0 -14, 51.9 -5,51.9 q 2,0 3,-4
|
||||
"/>
|
||||
<path stroke="#000" d="
|
||||
M81,222 c -4,-20 80,0 83,-22
|
||||
@ -305,13 +300,13 @@ style="background-color:ivory"
|
||||
c 3,4 -6,8 -6,16
|
||||
"/>
|
||||
<path stroke="#F00" d="
|
||||
M41,238 c14,-20 0,36 14,16
|
||||
M41,238 c16,-19 -16,51 2.7,28
|
||||
M42,237 c1,-1 1,-4 6,-4 c7,0 -4,25.5 3,25.5 q 2,0 3,-3.5
|
||||
M42,237 c1,-1 2,-2.5 4,-2.5 c7,0 -14,36 -6,36 q 2,0 3,-4
|
||||
"/>
|
||||
<g id="height_2_tree">
|
||||
<path stroke="#F00"
|
||||
d="
|
||||
M21,254 c16,-19 -12,32 5.7,12
|
||||
M22,254 q 0,-4.5 3,-4.5 c5,0 -8,21 -3,21 q 2,0 3,-4
|
||||
"/>
|
||||
<path stroke="#000" d="
|
||||
M21,254
|
||||
|
||||
@ -36,24 +36,6 @@ 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.
|
||||
|
||||
Client side include works like this:
|
||||
|
||||
```html
|
||||
<script src="b.js" type="text/javascript">
|
||||
</script>
|
||||
```
|
||||
|
||||
Where the script b.js is:
|
||||
|
||||
```js
|
||||
document.write("…")
|
||||
document.write("…")
|
||||
…
|
||||
```
|
||||
When encountered, the browser downloads the script “b.js”, executes
|
||||
it, and prints any output that the script might generate as if it were
|
||||
inline HTML.
|
||||
|
||||
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
|
||||
@ -61,10 +43,6 @@ those documents from the markdown documents in that directory should
|
||||
also generate the javascript, concatenating all the javascripts of the parent
|
||||
directories into it.
|
||||
|
||||
Thus one final javascript file for each bottom level directory, which
|
||||
generates a sequence of horizontal bars corresponding to the path to
|
||||
that directory, followed by a horizontal bar for that directory.
|
||||
|
||||
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
|
||||
@ -74,6 +52,23 @@ 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
|
||||
@ -261,7 +256,7 @@ Without counting spaces, but without multiline
|
||||
|
||||
Pipe table:
|
||||
|
||||
| Right | Left | Default | Center |
|
||||
| Right | Left | Default | Centre |
|
||||
|------:|:-----|---------|:----------------------:|
|
||||
| 12 | 12 | 12 | 12 |
|
||||
| 123 | 123 | 123 | the quick brown fox jumped over the lazy dog |
|
||||
@ -442,6 +437,11 @@ 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
|
||||
```
|
||||
@ -456,13 +456,6 @@ takes through all subsequent t points, sometimes pushing the curve
|
||||
into pathological territory where bezier curves give unexpected and
|
||||
nasty results.
|
||||
|
||||
Sometimes you just have to calculate the average of previous and
|
||||
following control point, and make it the start point of a new c curve
|
||||
followed s curves, or a new q curve followed by t curves.
|
||||
|
||||
Or if the terminal curve is a given, calculate the prior control point as
|
||||
twice the start point minus the following control point.
|
||||
|
||||
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
|
||||
@ -511,8 +504,7 @@ defined by very small source code.
|
||||
font-weight="400"
|
||||
stroke-width="2">
|
||||
<path fill="none" stroke="#00f000"
|
||||
d="M14 101, c40 -20, 30 -56,
|
||||
54 -18, s60 15, 40 15"/>
|
||||
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
|
||||
|
||||
Loading…
Reference in New Issue
Block a user