The content here is provided for developers implementing SERA or working with
an existing SERA parser.
SERA provides a special purpose escape mechanism that may be applied for software specific implementations
of SERA when an existing SERA definition is not available. The escape is \~ followed by
an identifying key term given in the 7-bit ASCII range and terminated by the first
white space character. A trailing space, `` '', character does not appear in the output.
\~u and \~b might start and stop ``underline'' and ``bold'' for example. The \~ escape may
also be used for extensions to font tables for special symbols. Extended descriptions
should be bracketed between { and } as per \~{my processing directive...}.
A second SERA parser that does not have the escape sequence defined, should simply ignore
the escape.
The principle consideration for HTML and SERA is that SERA parsers should give
HTML defined escapes precedence over SERA definitions. Hence, < and > ,
and & with ; should be parsed first as appropriate HTML escapes. When the
syntax does not qualify as HTML, the parser should proceed to SERA transliteration.
Mule with the
W3 web browser demonstrate
the ideal implementation of SERA in HTML. W3 convert SERA text between <sera> and
</sera> markups automatically into Fidel (the HTML 3.0 ``lang'' attribute
should be used here in the future).
Any number of extended labiovelar forms may be constructed from consonant classes in the
Fidel domain. Some not already found in the modern Fidel may actually be in low frequency
use in Eritrea and Ethiopia, others are useful for representing sounds from foreign languages
phonetically with Fidel script. (bWe), (pWE), (fWE), (mWi) are for example but a few of the
extensions introduced for Chaha. The transliteration of these extended forms is left to
individual developers.
Existing SERA parsers return unique addresses for ``We'', ``Wu'' (also ``W''), ``Wi'', ``Wa''
and ``WE''. Developers using these parsers are welcome to render or ignore the returned
code points as they wish. Transliteration of ``pWe'' would return an address for (p) and
an address for (We). Applications could reconstruct (pWe) from the address pairs of (p)+(We)
or render two glyphs (p)(we) for example or (p)(We) where (We) is a specialized extension
for an 8th form of (we).
Amharic and Tigrigna writing conventions do not have a built in way to denote doubling
and stressing of characters and vowels. A convention for gemination of the consonant
component of a Fidel syllable is employed in a number of texts on the study of these
languages. The nonspacing gemination glyph appears as two square-like dots over the
character to be affected.
The gemination of a Fidel letter in SERA is made with '' following the letter to be
lengthened. Examples are shown the out dated
SERA 95 hypertext.
The 6th or ``sadis'' order of a syllabic series in Fidel is usually treated as
a natural consonant. In practice this is not always true and commonly a vowel component of
the 6th syllable is voiced. The correct enunciation of the vowel is of
importance to linguists and students of Fidel written natural languages.
SERA parsers will return a defined code number for SOFTSADIS when `' are found together.
It is then left to the software to ignore or provide a phonetic character, or other handling,
for the vowel component. The phonetic system output option of
sera2latex for
example, will provide a phonetic character for the vowel part of the sadis syllable when
`' are present.
Apostrophe ' may be used for the same purpose but will not have the SOFTSADIS code number
returned. Some examples are:
ysTlN = y'sT'l'N
tgrNa = tg'r'Na
alfelgm = alfel'g'm
TrE = T`'rE
Following the convention of two byte systems, when a line break (carriage return or newline)
is encountered when parsing a SERA buffer, text before and after the line break must be
transliterated as two different Fidel characters. In example, were ``pa'' written together
on a single line, the Fidel (pa) would be given. If ``p'' were found at the end of a
line, and ``a'' the first character on the next line; (p) \n (a) is the correct
transliteration.
An application programmer may still find instances where in a programming
language neither of the alternate identifiers ` and the number 2 are
permittable syntax (in the case of macro definitions in C and TeX for
instance).
It is suggested then that the SERA Input Method convention for keystrokes
be employed in these instances. Here, `se and s2e would become sse, `he
and h2e become hhe etc. It is emphasized that the representation is reserved
for IM or program-internal variable representation and is NOT used for
document transliteration.
At no point in the design of SERA is the issue of sorting considered nor
addressed. A sortable transliteration convention, sortable under Ethiopic
lexicography, would likely not be so human readable -essential criterion
in SERA.
SERA is an ASCII transliteration of Ethiopic, as such sorting should not
be attempted at the ASCII level. Sorting should only be applied when
SERA text has been tokenized back into some representation of Ethiopic such as
Unicode.
Recalling the rule that undefined special purpose escapes (\~x) will be
ignored, the SERA composer can take advantage of this rule to add ``comments''
or ``hidden text'' that will not appear after retransliteration into Ethiopic.
In Example:
\~this-is-hidden-text , \~<this_is_hidden_text> ,
\~"this-is-hidden-text" , \~#this_is_hidden_text , etc...