Fixes in html files and manifest from 2000

2000/bmeyer/README.md

@@ -14,7 +14,7 @@
 
 ## Try:
 
-In a video window (white text on black background):
+In a terminal window (white text on black background):
 
 ``` <!---sh-->
     ./try.sh
@@ -33,7 +33,7 @@ The author recommended on linux/x86, glibc 2.0, libc4/5:
 
 ``` <!---make-->
     bmeyer: bmeyer.c
-            CC -DY="__setfpucw(0x127f)" -O6 $? -o $@ -lm
+            cc -DY="__setfpucw(0x127f)" -O6 $? -o $@ -lm
 ```
 
 However many compilers use `-O3` as the maximum level for `-O` optimization.
@@ -74,9 +74,9 @@ This program is called `GLICBAWLS`
 Squares".
 
 And that's exactly what this program does --- feed it a .PGM file
-(either raw [i.e. P5] or ASCII [i.e. P2]) on stdin, and it will
-output a compressed version to stdout. Feed it a compressed file
-on stdin, and it will decompress it to stdout --- as either raw or
+(either raw [i.e. P5] or ASCII [i.e. P2]) on `stdin`, and it will
+output a compressed version to `stdout`. Feed it a compressed file
+on `stdin`, and it will decompress it to `stdout` --- as either raw or
 ASCII .PGM, depending on what format it was compressed from. For
 example:
 
@@ -215,7 +215,7 @@ In short --- running it through the preprocessor and the
 pretty-printer will give you something that looks slightly less
 like line noise and slightly more like a C program, but unless you
 are a true wizard, it is unlikely to gain you any insights into
-what is actually going on....[^0]
+what is actually going on....[^1]
 
 
 ### Bugs, Assumptions and TODO
@@ -269,7 +269,7 @@ ordering. For each pixel, an expected value is calculated by creating a least
 squares predictor of order 12 based on all of the previously encoded/decoded
 pixels. However, the contribution of each pixel is weighted according to its
 [Manhattan-distance](https://en.wikipedia.org/wiki/Taxicab_geometry) from the
-current pixel, `D`. That weight used is `pow(0.8,D)`. [^1] [^2] [^3]
+current pixel, `D`. That weight used is `pow(0.8,D)`. [^2] [^3] [^4]
 
 In a similar way, the prediction *errors* for all previous pixels
 are combined --- a weighted average (with weight `pow(0.7,D)`) of
@@ -293,27 +293,27 @@ arithmetic decoder provides the information which half the actual
 value is in.  In both cases, the interval borders are adjusted
 accordingly, the arithmetic coder/decoder updated, and the
 interval halving repeated until the precise value has been
-en/decoded[^4].
+en/decoded[^5].
 
 
-[^0]: Yes, this could be seen as a challenge....
-[^1]: Actually, the weight is `pow(0.8,D)/s`, where `s` is the sigma
+[^1]: Yes, this could be seen as a challenge....
+[^2]: Actually, the weight is `pow(0.8,D)/s`, where `s` is the sigma
     used for encoding/decoding the particular previous pixel. Dividing
     by `s` is a rather arbitrary action justified only by the
     improvement in results.  Mathematically, I can only justify
     dividing by `s^2`, or not dividing at all....
-[^2]: Obviously, these least squares predictors are not calculated
+[^3]: Obviously, these least squares predictors are not calculated
     from scratch for each pixel. Some clever reuse of earlier
     results allows `O(1)` calculation, rather than the
     `O(previous_rows*columns)` this description would suggest.
-[^3]: As anyone who has ever tried local least squares knows from
+[^4]: As anyone who has ever tried local least squares knows from
     bitter experience, there is a lot of numerical instability
     associated with them. So `glicbawls` adds a bias towards an
     averaging predictor to the equation system the least squares
     predictor is calculated from.  The weight that is given to
     this bias is constantly adjusted throughout coding/decoding,
     thus justifying the 'a' in `glicbawls`.
-[^4]: In the case of near-lossless coding, the interval is not
+[^5]: In the case of near-lossless coding, the interval is not
     necessarily *halved*, but rather split at a convenient point
     (the split points are chosen in such a way as to minimise the
     expected number of bits needed for coding). Also, the
@@ -324,7 +324,7 @@ en/decoded[^4].
 ### Photo Credit:
 
 [Lavabus](lavabus.pgm) was taken by the judge, Landon Curt Noll.
-[Michael](michael.pgm) was provided by the author.  [Lenna](%%REPO_URL%%/2000/bmeyer/lenna.glic) is a
+[Michael](michael.pgm) was provided by the author.  [Lenna](lenna.glic) is a
 1972 Playboy centerfold (doesn't show very much).
 
 - [michael.pgm](michael.pgm)
@@ -333,11 +333,11 @@ en/decoded[^4].
 
 - [lavabus.pgm](lavabus.pgm)
 
-    A bus that was trapped by lava from [Kilauea
-    volcano](https://en.wikipedia.org/wiki/Kīlauea) in Hawaii, US.  Nobody was
+    A bus that was trapped by lava from [K&imacr;lauea
+    volcano](https://en.wikipedia.org/wiki/K&imacr;lauea) in Hawaii, US.  Nobody was
     in the bus at the time, BTW.  Photo date: 1981.
 
-- [lenna.glic](%%REPO_URL%%/2000/bmeyer/lenna.glic)
+- [lenna.glic](lenna.glic)
 
     A November 1972 Playboy centerfold was scanned in long ago and has been used
     for image compression research since then.  Playboy originally threatened to