[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
VMs: Re: Weirdoes, ligatures
At 10:55 04/10/02 -0500, GC wrote:
This is at the core of my current effort, which BTW has nothing to
do with replacing EVA, and everything to do with providing myself
with a transcription that encodes as much information as possible,
so that each time my views change somewhat, I don't have to go
back and redo my transcription. If enough information were stored
in any current transcription, this would be unnecessary, as simple
global changes would suffice in all but a few cases.
BTW: apart from ligaturation and variant-loop <ch>'es, are there any other
types of information that you think are missing from current transcriptions?
On the good
side, once this transcription has been offered, argued out and
proofed by all interested parties, it's a simple matter (as Rene
points out) to port it to an extremely accurate EVA transcription.
I suppose my point is simply that, if you define your glyph alphabet in
terms of ligatured EVA, ie
K <--> (ckh)
...etc, then you shouldn't need to create a specific moving-target font, as
you can remap into EVA dynamically (stripping out the ligatures as you go).
Even if you were to edit your transcription using a glyph format, the most
flexible storage representation format would always be a ligatured EVA
representation, and the most universal display format would be EVA (but
probably with ligature brackets removed).
The key is, of course, making sure that the storage EVA is overcomplete
relative to the display EVA, such that it can automatically (and
deterministically) be converted to/from glyphs without problem.
stored in the same database, with a user's current set selected (and stored
in a cookie!) via a select box, and be used to generate the edited text on
the fly. As long as the underlying EVA is fully ligatured, then anyone
would be able to edit the same transcription using whatever glyph-set they
like - FSG, vgbt, EVA, whatever. :-)
Cheers, .....Nick Pelling.....