1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
|
Date: 15 Sep 1993 16:34:45 -0400 (EDT)
From: Michael Downes <MJD@MATH.AMS.ORG>
Subject: Around the Bend #11
To: info-tex@shsu.edu
X-ListName: TeX-Related Network Discussion List <INFO-TeX@SHSU.edu>
The answer to Exercise 10, posted a couple of days ago, noted the
unsatisfactory fourfold bloating of the encoded text. This leads to
Exercise 11, which is rather difficult (double-dangerous bend level).
************************************************************************
*** Exercise 11 (hard):
Write your own decoder to solve the problem I set for myself in
Exercise 10: Using as few lines of TeX code as possible, set up an
Around the Bend post containing a typical exercise so that it can be
processed by plain TeX to (a) skip over the exercise text and (b)
decode an embedded encoded answer. Come up with a better encoding idea
than my previous one, that doesn't increase the size of the text by
300% during encoding.
************************************************************************
Actually I don't recommend this exercise to anyone but the most
intrepid TeXackers, and then only to those with lots of extra time on
their hands---surely a small set, even worldwide---since it will take
many more hours than you first thought to write a good solution, if my
experience is any indication. Issuing the problem now as an exercise
is more to place it on record, since I'm working on it anyway, than to
instigate serious attempts at a solution by other people.
The answer to Exercise 10 mentioned four design goals: (1) small
decoder (2) minimum expansion of text during encoding (3) avoidance of
special characters that tend to be corrupted by mailers or network
gateways (4) supported character set ASCII 9,13,32--126 in the text to
be encoded.
However, in my ongoing efforts to wrassle with this problem, I have
since decided to drop ASCII 9 [tab] from (4), and to eliminate (3),
because it seems to be an independent issue: If mistranslated
characters are a problem for the reader then they are a problem for
the unencoded exercise text as well, and not just for the encoded
answer. So now I am assuming that the reader has in hand a reliable
copy of the posting with newlines and all visible ASCII 32---126
accurately transmitted, and I am using basically a simple translation
table for the encoding and decoding (beware: oversimplification).
Since the text to be encoded will be under my control, I don't
anticipate ever needing to include an actual tab character that cannot
be converted to spaces or written in TeX notation as ^^I.
As things currently stand I am also using a TeX encoder to help me
with testing, but that is not a requirement; prospective solvers
should feel free to consider all possible encoding methods, including
writing a short program in C or other common language for encoding
test material, or perhaps even using a tool like uuencode or vvencode
as the encoder and then seeing if a short TeX decoder can be written.
A summary of solutions, or more likely, `the' solution (mine), will be
posted December 31, 1993. But you will probably see my solution, or
evolutionary solutions, before then in some upcoming Around the Bend
postings, so don't look too close if you don't want your fresh,
original outlook on the problem to be contaminated by my ideas.
If any readers do have difficulties with mistranslated characters in
Around the Bend postings, I would like to hear the details. For
checking, I give an ordered list of the ASCII characters 32--126
below.
Michael Downes %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
mjd@math.ams.org (Internet) ASCII 32--54,55--126: !"#$%&'()*+,-./0123456
789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
|
