Transliteration is changing one alphabet for another.
Transcription is writing or printing something, in the same alphabet.
The philosophical idea posited by ReneZ is nothing new - he has been involved in this since almost the beginning.
However, I am 100% behind his idea. Transliterating into our alphabet is going to cause problems. It would be far better to transliterate into You are not allowed to view links.
Register or
Login to view., something that didn't exist when EVA was being developed.
Many VMS-related conventions were developed during typewriter days.
Off-topic, but still related to VMS keyboard-mapping strategies in the computer age:
When I created my VMS documentation font (a font I designed from the ground up specifically for writing VMS papers), I used ALT characters for some of the letters. It's not as comfortable as typing regular keyboard letters, but is much more convenient than switching fonts several times per line.
It is not a transliteration font (it is not ideal for this purpose). It's a professional-quality publication font designed to facilitate the process of writing academic papers about the VMS. I made an effort to retain diacritical marks from major languages. This was a significant challenge since it leaves very little room for VMS glyphs, but I was able to come up with a workable system.
The uppercase VMS glyphs are shorter than the originals (this is a necessary compromise so that it can be interleaved with regular text), but they are readable as long as the font size is not too small:
[
attachment=4670]
Currently it works on OS X. Windows has an antiquated system for alternative keys and I don't have a solution yet but I may tackle it eventually.
It's a Roman-style font (I also have a non-serif version but I haven't double-checked it). There are hundreds of Roman-style fonts extant, but I designed my own because I wanted something the looks good on the screen and in PDFs. Many attractive Roman-style fonts look good in print but are not clear on the computer screen. I wanted this font to overcome that problem.
I plan to release it to the public at no charge for noncommercial scholarly use. Ideally, it should be widely disseminated so that the publishers (Wiley, T&F, Springer, universities, etc.) have it in their systems so they can accept PDFs and .doc files for peer review and publication. In the meantime, it can still be used to create PDFs for upload to various research sites and preprint servers.
(12-08-2020, 05:05 PM)-JKP- Wrote: You are not allowed to view links. Register or Login to view. (12-08-2020, 03:17 PM)nablator Wrote: You are not allowed to view links. Register or Login to view. (12-08-2020, 02:51 PM)farmerjohn Wrote: You are not allowed to view links. Register or Login to view.Using EVA-s both as standalone and as part of sh ligature is not extremely convenient, but normal parser can live with that: s before h - ligature, otherwise - standalone.
Yes, but there are a few instances of standalone EVA-S. Information is lost when converting to lowercase EVA, in these rare cases.
76r: qoteS
106v: toloS
Indeed, they are not common, but for the record, here is another one:
You are not allowed to view links. Register or Login to view. 04:05: Sody Sody
Yes, but here are gets into the area of rare characters, and one has to use the full extended Eva (or v101 for that matter). Notations in this case are different.
The following table may give an overview of all
Sh-like characters that have been observed in the ZL and v101 transliterations.
[
attachment=4671]
If Sh SH is a ligature (two glyphs combined), as it would be in Latin, then you don't need rare characters. So and Sy are easily represented with Basic EVA. If parsing is a concern, then a flag can be used, which is far more expedient than a list of rare characters.
We don't know if it's a ligature, that's still unknown, but if it is, then a chart full of rare characters is not needed to represent it when it combines with other characters.
In medieval scripts, using ligatures and abbreviations was normal and prevalent.
If it were Latin, it would actually be represented with three characters: the left side of the ligature, the right side of the ligature, and the macron.
Sh might not be a ligature, but on You are not allowed to view links. Register or Login to view. the two parts are disconnected in several places (I have posted examples on my blog), and there are a number of places throughout the manuscript where both c and S are combined with glyphs other than h. There are also places where the macron is association with other characters, like ii and qo. It is not just Sh that has a macron-like shape hovering over it.
The variations posted as part of V101 is a more complicated issue.
We don't know if the bewildering variations in the macron-like VMS glyph are meaningful differences. Macrons varied quite widely in medieval scripts but they all meant the same thing, so variations in shape didn't matter.
But the VMS is different, and the macron-like shapes vary even more than was normal for medieval scripts.
Are the differences meaningful? I don't know. But if they are, then there might be numerous meanings for Sh.
JKP, the rules for Eva state that {aa} and Aa are two equally valid notations for the same thing.
So, according to the rules for Eva, one can write {sh} and Sh, or {so} and So, but by convention the latter is written as {c'o} precisely because the "quote" can also appear with other characters.
The capitalised way is a bit less easy to recognise, but allows accurate rendition in the TT font.
For example: cTHhy looks like cTHhy , but when writing {cthh}y it is easier to see which characters are connected.
Due to the high frequency, Sh is usually simply written as sh.
When talking about ligatures and abbreviations, then one is of course talking about interpretation rather than transliteration.
(13-08-2020, 05:45 AM)ReneZ Wrote: You are not allowed to view links. Register or Login to view.
...
When talking about ligatures and abbreviations, then one is of course talking about interpretation rather than transliteration.
Yes. But you have to interpret before you know what to transliterate. Or, alternately, have a variety of transliterations for the different interpretations.
(13-08-2020, 03:58 AM)-JKP- Wrote: You are not allowed to view links. Register or Login to view.Many VMS-related conventions were developed during typewriter days.
Off-topic, but still related to VMS keyboard-mapping strategies in the computer age:
When I created my VMS documentation font (a font I designed from the ground up specifically for writing VMS papers), I used ALT characters for some of the letters. It's not as comfortable as typing regular keyboard letters, but is much more convenient than switching fonts several times per line.
It is not a transliteration font (it is not ideal for this purpose). It's a professional-quality publication font designed to facilitate the process of writing academic papers about the VMS. I made an effort to retain diacritical marks from major languages. This was a significant challenge since it leaves very little room for VMS glyphs, but I was able to come up with a workable system.
The uppercase VMS glyphs are shorter than the originals (this is a necessary compromise so that it can be interleaved with regular text), but they are readable as long as the font size is not too small:
Currently it works on OS X. Windows has an antiquated system for alternative keys and I don't have a solution yet but I may tackle it eventually.
It's a Roman-style font (I also have a non-serif version but I haven't double-checked it). There are hundreds of Roman-style fonts extant, but I designed my own because I wanted something the looks good on the screen and in PDFs. Many attractive Roman-style fonts look good in print but are not clear on the computer screen. I wanted this font to overcome that problem.
I plan to release it to the public at no charge for noncommercial scholarly use. Ideally, it should be widely disseminated so that the publishers (Wiley, T&F, Springer, universities, etc.) have it in their systems so they can accept PDFs and .doc files for peer review and publication. In the meantime, it can still be used to create PDFs for upload to various research sites and preprint servers.
During coronavirus quarantine I also made an attempt to create Voynich font, which on the one hand is based on EVA (so mostly compatible with current instruments) and on the other hand is able to render properly s (differently as single s and as part of sh), ckh (so you don't need to type cKh or {ckh}), complex ligatures, etc. That is far from easy task. The results may be found You are not allowed to view links.
Register or
Login to view..
Rene. Although the following examples contradict your decomposition method (bench wich apostrophe) , they should appear in your published table.
[attachment=4674]
Hello Vladimir,
my table is based on published transliterations, and the symbols that have been recognised by the people creating these.
It is adopting an approach that can be extended, namely grouping characters into 'families' based on generic or high-level appearance.
This makes the identification of any character a two-step approach:
- which family does it belong to?
- which family member is it.
From the existing transliterations, the answer to the first question is (of course) much more consistent, but it is also not possible to define clearly bounded families. There are always marginal cases.
There are still a great number of symbols in the MS that require a better representation in the transliteration files.