Re: Tachygraphy : was RE: VMs: F66r

["GC" <gc-@xxxxxxxxxxxxx>]

Jeff,

I'm just in the process of completing f1r, sad to say.  f1r was my nemesis,
the one folio I couldn't get a clear handle on, but the new images have
cleared up a lot that was in question.  My opinion that the paragraphs were
added at different times seems to hold, if I'm recording the glyphs
correctly :-)  This is one of a handful of folios where the fingers start
searching for different keys between paragraphs.  That's hardly a quantified
observation at present, but there nonetheless.  Once I get past this
fascinating folio, the pace will pick up.  I have had a pretty firm grip on
the bulk of the herbal section for some time, a folio or two holding out in
respect of the author, possibly for someone more skilled than myself?

As to the transcription, I'd like some feedback if you don't mind.  As Jim
Gillogly expressed, my natural inclination was to use 'space' for space, but
EVA took a different route with '.' for space and '-' for end of line.  I
originally used those markers in my text files, though they do not exist in
my actual transcription files.  Standard text files already have a
non-visible "end-of-line" marker, and two of these together form an "end of
paragraph" mark, so the '=' is probably not necessary either.  For purposes
of readability, it is probably wise to exclude these.  My eyesight is
apparently headed along the same lines, if you get my 1.75 magnification
drift.

My current transcription is up to f111r, in my old style method.  This style
needs some improvement however.  Originally I started out by assigning what
I considered 'common glyphs' to standard keys, and assigning 'rare glyphs'
to oddball places.  It turns out that a lot of those I considered 'rare' are
far more common, and the strange assignment of glyphs makes the text
difficult to read without a font overlay.  That's not a problem, because I
can re-order the font assignments globally and rework the font to match.

The problem lies in certain considerations for keyboard assignment, and a
proper scheme to make things more visually pleasing and mnemonically
oriented.  Instances of this - "c" is a mnemonic for "c", but there are "c"s
without ligatured tails and "c"s with tails.  'c' can stand for the "c", and
a simple shift - 'C' can stand for the "c" with a tail.   This standard
could apply to "m" with and without a tail, or "n" with and without a tail.
It can even mnemonically distinguish between an EVA <r> or <s> for standard
glyph keyboard input.  Then you have the double "cc" with and without a
tail, and the triple "ccc" with and without a tail.  There are the EVA
<iiin> that is an 'm' with an extra stroke and a tail, but this also exists
without a tail.  These can also be handled by the "shift" keyboard function.
There is an "8" that should be mnemonically representated as an '8', and a
shift of this would give you the '*' symbol to represent an '8' with a tail.
Mnemonically speaking, if you're uncertain what an asterisk stands for, you
simply look at the "8" key on your keyboard and there's your remembrance
mechanism.

The gallows glyphs differ in that they stand in sets of four most commonly,
while simple key assignments only allow for two variations.  In the
"unstandard" set, there are a minimum of three variations on each standard
gallows glyph, and this is where assignments really get hard to perform
mnemonically.  You have gallows combos that begin and end with "o", "a" and
"9".  These I properly term "combinations" or "combos" because I understand
the purpose of these.  They are indeed two or more glyphs, but their
combination informs you to take them from the same location before
progressing, and not taken sequentially.  The same with the "c" attached to
the "8" or "*", only two of numerous examples of this "markup" language.  A
good transcription however, does not allow for me to insert my own
identification of the meaning, but rather to record simply what is written
on vellum.  So where do you stuff these suckers, since key assignment only
allows for two variations?

A good transcription includes as much information as possible, and allows
for user interpretation.  If I record a "cc" as a 'u', anyone who thinks
these should be two separate "c"s can simply replace all 'u's with their
interpretation.  But if I record a "cc" as <ee> without using the EVA
capitalization rule (i.e. "Ee"), then information is lost and unrecoverable
in the transcription.  This is especially important in such glyphs as "ccc",
where it is sometimes written as "c u" or "u c".  If these were at least
recorded as half-spaces, say <e-ee> or <ee-e>, information loss would not be
a problem.

As I mentioned above, the <r> and <s> glyphs can be handled by a simple
keystroke, but I forgot to include one glyph that fits here, the EVA <c>
with a hook, resembling, but not akin to, the two mentioned before.  Again,
you can assign a key to the EVA <c> and use the shift function to add the
hook or tail, but the the EVA <c> is not that prevalent, and neither is its
sister.  What to do?  Standard key space is limited to binary assignment -
key and shift - but there are more variations on a theme than our binary
world allows us to connect mnemonically.

I will revise my current transcription based on my former key assignments,
and make global changes at the end to rearrange key assignments to fit a
scheme, primarily based on frequency of glyph and mnemonic assignment.  In
the end it should be something easily viewed, remembered and written,
without information loss.  I also invite the creators of EVA to pick up the
ball on this and move forward - we have entered a new era of VMS research,
one where the script can be analysed and encoded based on the spaces between
the glyphs.  No one has published detailed analysis using the five strokes
of <daiin> as a basis for glyph assignment, and even Rene uses a modified
glyph-based script for his own analyses.  It's a sad thing, but I had to
dump two previous transcriptions and all the work that went into them when I
began to gain focus, and this didn't happen until I progressed from poor
copyflo to microfilm images.  With the sid images available, the
transcription effort should progress accordingly, with many of the old
issues resolved.  My attitude toward my old transcriptions was that I was
not discarding them, only building on them with new understanding.  The EVMT
project needs to update, and understand that the specific glyphs I've been
speaking about are not a matter of visual interpretation, but actual
structures in the system.  The sid's make my case most eloquently.

GC



----- Original Message ----- 
From: "Jeff" <jeff@xxxxxxxxxxxxxxxxxxxxxx>
To: <vms-list@xxxxxxxxxxx>
Sent: Sunday, June 20, 2004 11:06 AM
Subject: Re: Tachygraphy : was RE: VMs: F66r


> I have had a look at the transcription files but haven't saved them
anywhere
> as yet. They look interesting to say the least. I would like to see the
> files with spacing symbols present. Have you any idea when this will be
> ready? I also want to run some analysis on what you have produced. This
> means writing more code but should be worth it.
>
> Jeff
>
> ----- Original Message -----
> From: "GC" <gc-@xxxxxxxxxxxxx>
> To: <vms-list@xxxxxxxxxxx>
> Sent: 16 June 2004 07:28
> Subject: Re: Tachygraphy : was RE: VMs: F66r
>
>
> > Jeff wrote:
> > > I would be VERY interested to see your transcription. One question I
> have
> > to
> > > ask is your opinion on verbose groupings. ie 'ol' or 'or' that seem to
> be
> > > glued
> > > together a lot.
> >
> > The best way to view my transcription at present is to download the
> > following TrueType font, and apply it to the quire text files.  (If I
> > remember, IE with security settings above medium won't allow you to
> download
> > a .ttf file, so you may have to alter your security settings temporarily
> to
> > get this file.)   I wouldn't waste my time on the large pdf's since the
> > transcription will be undergoing a change soon.  Input is appreciated,
of
> > course.  Many of these folios (at least 30) will be suffering little or
no
> > alteration, since they're pretty straight forward and unambiguous.
> There's
> > the occasional "cc" ambiguity that throws of the numbering by one, but
> there
> > were work-arounds for that before we had the sid files, so most of these
> > should have already been straightened out.
> >
>
>
> ______________________________________________________________________
> To unsubscribe, send mail to majordomo@xxxxxxxxxxx with a body saying:
> unsubscribe vms-list

______________________________________________________________________
To unsubscribe, send mail to majordomo@xxxxxxxxxxx with a body saying:
unsubscribe vms-list