[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: VMs: truncated repeating sequences
On Thu, 9 Sep 2004, Marke Fincher wrote:
> So far I have found 10 related sets and I'm still picking them out
> manually. Shortly I will add some code to look for them and we'll see
> how many I can find in total.
> The next step is to see if >99% of the VMs can be created by pasting
> together decent sized chunks taken from a small set of "master
That's what I was thinking in regard to your initial "Fincher Grill"
suggestion. If this is how it was done, then it should be possible to
deduce (most of) the original page(s).
There do seem to be at least two issues that you need to take into
account, however, in doing this.
1. Don't rush to the assumption that the window is n x m EVA characters
- It might well be n x m units of length over a manuscript original.
- It might be n x m characters in a resolution of the VMs. graphs into
characters that doesn't match the EVA resolution. For example, (to use
EVA forms) aiin or eed or y, etc., might be counted as one or two
characters each (initial sequence plus terminal flourish).
- Or the count could be by individual graphs, in which case aiin might
count as 5 or 6, eed as 4, y as 2, and so on.
Fortunately, the first of these alternatives seems most likely to me, and
it tends to make the approach independent of the structure of the
orthography, though you might have fuzziness resulting from given "glyphs"
being on the edge of the window. The author might include or exclude one
of these "on teh edge" glyphs at whim. Anyway, the EVA scheme of
rendering the orthography has the advantage for you of tending to map
sequences to Roman character strings of approximately the same measurement
(or pixel) length.
2. Don't rush to the assumption that the window technique is applied
exclusively. An author applying this approach free-hand to generate text
with images embedded in it might well vary it, e.g., to generate labels,
or to embed the labels in surrounding text.
And, of course, one might well use a window-based scheme to encrypt a
running text, perhaps to surround a critical character by noise
characters. Though I don't see how to combine that neatly with labels.
That is, labels seem to lack "room" for noise.
Supposing the text were generated in this way, why would the constituent
words of the final text show the internal structure that folks like Jorge
Stofi (and others before) have observed in it?
One would also have to wonder if any disputed "notational variants"
occurred across "same (sub)sequences" in your examples. If o = b, does
that affect the count? Or if m = z?
To unsubscribe, send mail to majordomo@xxxxxxxxxxx with a body saying: