Until this notice is removed this is a draft document. Comments and suggestions should be sent to LiveGeez@EthiopiaOnline.Net. The document will be submitted to the RFC Editor when the drafting stages are complete.
Network Working Group
Request for Comments: XXXX
Category: Experimental
Daniel Yacob
Ge'ez Frontiers Foundation
January 1999

The LiveGe'ez Remote Processing Protocol

Status of this Memo

This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.


Ethiopic web publishing is burdened with a legacy of numerous disparate systems. The probability is then very high that a document published in one encoding system becomes inaccessible to the majority of users who will wish to read the document. A conversion service is proposed to alleviate this problem.

This document describes a Common Gateway Interface API and Hypertext Markup Language extensions for the conversion of web documents on remote servers from one encoding system into another.


1. Motivation

Although Ethiopic character set / character code conversion software is available in the public domain it remains inaccessible to the average user wishing to publish with it. At issue in the foreseeable future are web hosting services reluctant to install said software. The need then arises for such users for access to a remote processing service.


2. Definitions, Conventions, and Generic BNF Grammar

Although the mechanisms specified in this document are all described in prose, most are also described formally in the augmented BNF notation of RFC 822. Implementors will need to be familiar with this notation in order to understand this document, and are referred to RFC 822 for a complete explanation of the augmented BNF notation.

All CGI parameter and HTML markup and parameter names as defined are case-insensitive. However, parameter values are case-sensitive unless otherwise specified for the specific parameter.

FORMATTING NOTE: Notes, such at this one, provide additional nonessential information which may be skipped by the reader without missing anything essential. The primary purpose of these nonessential notes is to convey information about the rationale of this documents or to place this document in the proper historical or evolutionary context. Such information may in particular be skipped by those who are focused entirely on building a conformant implementation, but may be of use to those who wish to understand why certain design choices were made.

2.1 Character Set

RFC 2045 provides our definition of character set:

The term "character set" is used in MIME to refer to a method of converting a sequence of octets into a sequence of characters. Note that unconditional and unambiguous conversion in the other direction is not required, in that not all characters may be representable by a given character set and a character set may provide more than one sequence of octets to represent a particular sequence of characters.

It is noted in the RFC that the above definition is intentionally very general and in some communities will be interchanged with the term "character encoding". A general definition for character sets is practical for discussion of Ethiopic encoding methods as a plethora of different methods have been applied to electronically encode the Ethiopic system of writing. The major systems addressed by this specification are encodings in computer fonts, transliteration, and transcription. A review of these approaches follows.

2.1.1 Computer Font Systems

Ethiopic fonts have been encoded on personal computer systems in one of three approaches. The governing design constraint in devising an encoding systems has been the address space limitation for encoding glyphs that many font systems impose.

1. Diacritic Based Systems whereby the character set is broken down into base glyphs and diacritic symbols. Usually more than one of a given diacritic symbol is given to enhance screen and printed rendering against the geometry of the base glyph. The use of diacritic symbols is a means to encode more characters into available space. Less frequently used characters may be omitted.

2. Whole Glyph Systems whereby glyphs remain intact, again less frequently used characters may be omitted to meet font space limitations.

3. Distributed Encoding Systems whereby approach (1) or (2) is taken but characters are spread over multiple physical fonts. In this way the less frequent characters need not be omitted from the character set.

It is important to note before continuing that in Approach 1 the resultant encoding scheme will be multibyte while using a single physical font. Base glyphs are themselves valid characters and will need only a single byte of encoding. While as many as 3 diacritic symbols along with a base glyph (4 bytes total) may be needed to encode other characters. In Approach 3 an Ethiopic "character set" becomes a collection of character encodings from each of the independent fonts. When diacritic symbols are in a different font file from the base glyphs the encoding of a single character becomes not only multi-byte but multi-typeface (encoded by two coded character sets).

2.1.2 Transliteration Systems

John Clews provides an apt definition of transliteration:

Transliteration is the process which consists of representing the characters of an alphabetical or syllabic system of writing by the characters of a conversion alphabet, this being the easiest way to ensure the complete and unambiguous reversibility of the conversion alphabet in the converted system.

2.1.3 Transcription Systems

Again John Clews writes:

Transcription is the process whereby the sounds of a given language are noted by the system of signs of a conversion language.

A transcription system is of necessity based on the orthographical conventions of the conversion language. Transcription is not strictly reversible.

Transcription may be used for the conversion of all writing systems. It is the only method that can be used for systems that are not entirely alphabetical or syllabic and for all ideophonographical systems of writing like Chinese.

2.2 Transfer Variant

A "Transfer Variant" refers to an additional encoding of a character set for purpose of information interchange. For instance a document composed in the "Geezigna" character set might be transfered as UTF-7, UTF-8, Quoted-Printable, or UUEncoded.

The UTF encodings may invoke some confusion as the Unicode character set is implied implicitly though it is not, ultimately, the target character set of the document.

2.3 Language and Locale Targets

Text may be formatted under the writing practices of a given linguistic region and period. The LiveGe'ez Remote Processing Protocol is designed to be language and locale aware for such services as date conversion and document formatting. No requirement is made however on the locales and languages supported by a LiveGe'ez implementation.


3 CGI Parameters

The LiveGe'ez Remote Processing Protocol exploits the HTTP Common Gateway Interface standard as a means to receive processing requests over the Internet. CGI services specified in this version of the protocol are those of document and string encoding and date conversions.

The grammar for LiveGe'ez processing requests through CGI is given as follows:

parameter := attribute "=" value

attribute := token 
             ; Matching of attributes
             ; is ALWAYS case-insensitive.

value     :=  token
           |  token "." token
           ;  The second token is some
           ;  modifier of the first.

token     := 1*<any alpha-numeric (US-ASCII) CHAR>

3.1 Universal Parameters

Essential parameters for an arbitrary stream translation are those that will inform the processing agent of:

  1. The character set of the stream (if not indicated within the stream itself).
  2. The translated character set to return.
  3. Locale request for a specific writing convention.
  4. Use/Not use HTML 7-bit character entity escapes.

Table 3.1 lists parameters that may be used throughout the LiveGe'ez Remote Processing Protocal in combination with other parameters associated with character code conversion.

Table 3.1 Universal Translation Parameters
Defined Attribute
. Defined Attribute
. Parameter Meaning

sys | sysOut LIVEGEEZSYS Output system request of processed document.
sysIn LIVEGEEZSYS Input system request of processed document.
xfer | xferOut TRANSFERVARIANT Output transfer encoding.
xferIn TRANSFERVARIANT Input transfer encoding.
lang LANG Language (really locale) setting for the document translation.
pragma "7-bit" Use HTML 7-bit escapes.
"gspace" Substitue ASCII spaces for Ethiopic Wordspace (U+1361) overriding locale settings.
"eqmark" Set default question mark to Ethiopic Question Mark (U+1367) overriding locale settings.

Multiple pragma directives can be given by combining pragma requests in a comma deliminated list or by appending digits to the pragma attribute (e.g. pragma1=value, pragma2=value, pragma3=value). This is intended to simplify sending multiple pragma directives through HTML forms vs the former approach.

The macros given in Table 3.1 can be expanded following the grammar shown below. Terms correspond to the definitions given in Section 2 and a comprehensive list of character set "SYSTEM" tokens is given in Appendix A.


              | TRANSLITSYSTEM
              | TRANSCRIPTSYSTEM



                  | SYSTEM "." LANG

                  | SYSTEM "." LANG

SYSTEM  :=  token
            ;  Any implementation supported system.
            ;  Appendix A lists defined system tokens.

         |  LOCALE

LOCALE  :=  <Any Implementation Supported Locale>

3.2 File Translation

Essential parameters for a document translation are those that will inform the processing agent of:

  1. How and where to access the document.
  2. The character set of the document (if not contained within the document itself).
  3. The translated character set to return.
  4. Locale request for a specific writing convention.
  5. Other processing directives such as not to use a cached translation of the document or to return the document in HTML 7-bit characters only.

The Universal Parameters combined with Table 3.2 provides attribute definitions for the LiveGe'ez Remote Processing Protocol that meet the above requirements:

Table 3.2 Document Translation Parameters
Defined Attribute
. Defined Attribute
. Parameter Meaning

file /full/path/to/file
Full file name from server root or a properly formed Uniform Resource Locator string.
pragma "no-cache" Explicit server requests.





NOTE: In general a document will in some form specify its own encoding system(s) and the "sysIn" parameter will not be required. When the sysIn parameter is given it should take precedence over the document specified encoding.

3.3 String Translation

String translation service is also specified in the LiveGe'ez Remote Processing Protocol and is analogous to the file translation service described in Subsection 3.2. The "string" attribute takes the place of the file attribute in Table 3.2 and may be any URL encoded string.



3.4 Date Translation

The essential parameters for a date translation are those that will inform the processing agent of:

  1. The date to be converted.
  2. The calendar system of the date parameter.
  3. The conversion calendar system.
  4. The character set in which to return the converted date.
  5. Locale request for a specific writing and formatting convention.
  6. Other processing directives.

Table 3.4.1 provides attribute definitions in addition to the Universal Parameters of the LiveGe'ez Remote Processing Protocol that meet the above requirements:

Table 3.4.1 Date Translation Parameters
Defined Attribute
. Defined Attribute
. Parameter Meaning

day 0?[1-9] | ([0-2])?[1-9] | 3[0-1] A valid numeric day of month for the given month.
month 0?[1-9] | 1[0-3] A valid numeric month for the given calendar system.
year -?[0-9]+ Any integer value.
cal | calIn CALSYS Calendar system of date parameters.
calOut CALSYS Conversion calendar system.
pragma "date-only" | "phrase" | "is-holiday" Explicit server requests.

The "CALSYS" macro expands according to:

CALSYS  :=  "ethio" | "euro" | "et" | "eu" 
            ; Support for Ethiopic and European calendars are minimal requirements





The response in the first example would be a formatted date in the European calendar of the form "Thursday January 7, 1999" though no formatting or language locale is specified as a default. The response in the second example would be the Tigrigna analog of the first example under "VG-Main" font encoding. The final example applies a pragma directive. Pragma values for date queries are presented in Table 3.4.2:

Table 3.4.2 Pragma of Date Queries
date-only day "," month "," year "\n" A comma separate list of digits terminated by newline.
phrase "Tahsas 29, 1991 is Thursday January 7th 1999...\n" A phrased response terminated by newline.
is-holiday "0" | "1" "\n" Boolean "0" or "1" response terminated by newline.
is-holiday,phrase "Tahsas 29, 1991 is Ethiopian Christmas\n" The two pragma directives passed together with a comma delimitor return a phrased response terminated by newline.

NOTE: There is an implicit assumption that the Ethiopic and European (Gregorian) calendars will be the primary interest of the user community. Accordingly, when the "calOut" attribute is omitted it is assumed that dates in the companion system are returned.

3.5 Numeral Translation

English to Ethiopic numeral translation service is specified in the LiveGe'ez Remote Processing Protocol. The "number" parameter with a positive or negative numeric value may be combined with the "sysOut", "xfer" and "phrase" attributes to request queries.



The "enumber" paramter for Ethiopic to English numeral translation is not a required part of the specification at this time. The paramter name will remain as a reserved term until its usefulness is further studied for a futre version of the specification.

3.6 Server Defaults

In both service areas (file translation and calendar conversion) it is left to the server administrator to set default language settings for when the "lang" attribute is omitted. It is also left to implementers to decide how to handle error responses when a parameter is left out.

3.7 Use With Persistant Cookies

The use of persistant cookies is practical for storing preferences such as "sys" and "lang" but explicit requests in a CGI string will take precedence over cookie values.


4. HTML Entity Extensions

The LiveGe'ez Remote Processing Protocol also specifies how the body of an HTML document is to be interpreted and provides useful extensions to the markup language itself.

When remote documents are being processed (those requested through the "file" parameter and containing the "protocol://" structure) the document root will be set using the "base" tag with the "file" cgi parameter value:

<base href="URL">

The base tag will not be inserted into the "head" section of the document only if one has not been provided.

After setting the base url in remote files, LiveGe'ez implementations will continue to process the content of the document "body" section. LiveGe'ez implementations will be required to:

  1. Detect an Ethiopic character set.
  2. Work only within the scope of the Ethiopic character set.
  3. Convert plain text and character entities (i.e. &eacute;) from the detected character set (unless over ridden by the "sysIn" cgi parameter) into the requested "sysOut" character set.
  4. Execute other predefined inline processing directives (discussed in Subsection 4.3).

The scope of an Ethiopic character set will of necessity fall between the "font" markup tags for TrueType font systems or the "span" tag for transliteration and transcription systems will be discussed shortly in Subsection 4.2.

NOTE: While the "basefont" markup support is available in many browsers however the "face" attribute of "basefont" is less universal. The basefont markup is not supported in this version of the LiveGe'ez Remote Processing Protocol for typeface setting. The basefont markup does not effect font typefaces used within tables nor headings. Further, using the basefont markup would invert the problem to one of using "font" tags for changes to Roman script (common for numerals and Roman punctuation mixed with Ethiopic script). Since there is no certainty of a specific Roman typeface being available on all window systems this version of the LiveGe'ez specification leave Roman script as the default underlying script.

4.2 Spanning Tags

The Hypertext Markup Language provides the generic "span" markup which has no function by itself. Its functionality comes through the attributes used with the entity.

LiveGe'ez document processors supporting transliteration and transcription systems should be enabled to detect the "trans", "lang" and "options" attributes in the span markup as per:

<span trans="TRANSLITSYSTEM">`selam `alem</span>
<span trans="TRANSLITSYSTEM" lang="LANG">`selam `alem</span>
<span trans="TRANSLITSYSTEM" lang="LANG" options="OPTIONS">`selam `alem</span>

The attribute order is not important. The "sera" tag with no attributes should be recognized by LiveGe'ez implementations supporting the SERA transliteration system. The "sera" markup dates from early 1995 and support for the markup is suggested for backwards compatibility with legacy systems.


<sera>`selam `alem</sera>
<span trans="sera">`selam `alem</span>
<span trans="ethiop.amh">'salAm `Alam</span>
<span trans="mainz" lang="amh.et">MalAm OAlam</span>
<span trans="dehai" lang="tir.er" options="key=value&key=value">selamat Alem</span>

Note that after the initial "lang" and "options" attributes are set they need not be respecified in subsequent markups.

<span trans="ethiop.amh.et">'salAm `alam</span>
Hello World
<span trans="ethiop">^cAw `alam</span>

The "lang" and "options" attributes would be employed again only to reset the attributes.

To simplify implementation, HTML documents should be preconditioned such that the scope of the Ethiopic character set is nested within markups where HTML renderers will reset typefaces.


    <h1>This is my Title</h1>
    This is
         some body text...
      <li> Item 1
      <li> Item 2
      <li> Item 3
    <h1><sera>This is my Title</sera></h1>
    This is
         some body text...
      <li><sera>Item 1</sera>
      <li><sera>Item 2</sera>
      <li><sera>Item 3</sera>

Where the "sera" tag above might also be "font" or "span". In the case of the Unordered List the scope of the "sera" markup does not include the list item to insure that the "bullet" glyph is rendered with the underlying Roman script font -as the bullet may not be found in the conversion Ethiopic character set.

4.2.1 Nesting of HTML Tags for Ethiopic Character Sets

The nesting of the HTML "span" tags for transliteration and the ""font" tag should be avoided to make implementation easier at this time.


  <span trans="mainz">MalAm OAlam</span><span trans="sera">`selam `alem</span>

  <span trans="mainz">MalAm OAlam<span trans="sera">`selam `alem</span></span>

4.3 Non-Spanning Tags

Unlike the generic "span" tag the HTML language does not provide an equivalent markup for in-place tags. Fortunately HTML interpreters will ignore unrecognized markups and we may introduce the "LIVEGEEZ" markup for LiveGe'ez processors to detect and interpret.

The LIVEGEEZ markup depends on its attributes to perform any service. The "date" and "fortune" attributes are the only specified at this time.

4.3.1 The Date Conversion Attribute

The date conversion attribute is analogous to the day, month and year CGI parameters of Subsection 3.4. The difference in using a single "date" attribute is that the day, month and year attribute values are grouped in a comma separated list to form the "date" attribute value. The calendar system of the date numeric values may be included as the last item of the list:

<LIVEGEEZ date="DATE" lang="LANG">
<LIVEGEEZ date="DATE" lang="LANG" cal="CALSYS">
<LIVEGEEZ date="DATE" lang="LANG" cal="CALSYS" xfer="LIVEGEEZSYS">

DATE    :=  "Now"
         |  day "," month "," year
         |  day "," month "," year "," CALSYS
         ;  day, month, and year tokens were defined in Table 3.3.1
         ;  CALSYS here corresponds to the calIn parameter.
         ;  Ethiopic calendar is assumed when CALSYS is omitted.

The "xfer" field would only be required when the markup is embedded in a block of non-Ethiopic text. Otherwise the current LIVEGEEZSYS is applied in the formatted date output.


Markup . Output

<LIVEGEEZ date="Now"> The current date using the default or current language and xfer setting.
<LIVEGEEZ date="29,4,1991,et" lang="tir"> Tahsas 29, 1991 in Tigrigna spelling in the current xfer setting.
<LIVEGEEZ date="29,4,1991,et" cal="eu" lang="fr.ch"> January 7, 1999 in Swiss French spelling and formatting.
<LIVEGEEZ date="7,1,1999,eu" cal="et" lang="amh"> Tahsas 29, 1991 in Amharic spelling in the current xfer setting.
<LIVEGEEZ date="29,4,1991" lang="amh" xfer="GFZemen"> Tahsas 29, 1991 in Amharic spelling using the Ge'ezFree Zemen character set.

4.3.2 The "Menu" Attribute

The "menu" attribute is provided such that implementation support Ethiopic character sets can be conveniently inserted into HTML forms as drop down selection menus. This approach is intended to facilitate maintenance of Ethiopic documents. The document composer need only apply the "LIVEGEEZ" markup a single time and be relieved of the burden of having to update documents following changes in supported systems on the server side, or when translating the document at different servers.

No menu attribute value other than "standard" is specified at this time. The menu attribute may be accompanied by "name" and "script" attributes for passing the values of the selection field name in the form and option scripting codes.


<LIVEGEEZ menu="standard" name="sysMenu" script="onChange="openLink(this.options[this.selectedIndex].value);">
<LIVEGEEZ menu="standard" name="sysMenu" script="js-standard selected="Addis98" ">

The "js-standard" script attribute value is an alias for the JavaScript sample passed in the first example. Both cases result in the same HTML form drop down select output given below:

<select name="sysMenu" onChange="openLink(this.options[this.selectedIndex].value);">
  <option value=Addis>Addis One</option> 
  <option value=AddisWP>Addis One</option> 
  <option value=Addis98 selected>Addis One</option> 
  <option value=Agaw>Agaw</option> 
  <option value=AGF-Dawit>AGF - Dawit</option>
  <option value=AGF-Zemen>AGF - Zemen</option>
  <option value=AGF-Ejji-Tsihuf>AGF - Ejji Tsihuf</option>
  <option value=AGF-Rejim>AGF - Rejim</option>
  <option value=AGF-Yigezu-Bisrat>AGF - Yigezu Bisrat</option>
  <option value=ALXethiopian>ALXethiopian</option> 

4.3.3 The "Game" Attribute

The "game" attribute is not a required part of the LIVEGEEZ markup specification. The implementation is optional; an API specification is given here for those devlopers wishing to provide an interface to available BSD style "games" available for Ethiopic languages such a fortune and banner:

<LIVEGEEZ game="fortune">
<LIVEGEEZ game="fortune" src="URLToAuthorDB" args="17" lang="amh">
<LIVEGEEZ game="banner" args="`selam `alem" lang="amh" xfer="LIVEGEEZSYS">

For the game "fortune" the "src" is optional to specify a URL to a specific (vs random) fortune format data base file of Qine, Geter, Enqoqlesh, Qeldoch, etc. A number passed in the "args" attribute requests a specific entry in the database.

With the game "banner" the expected "args" value is the string to be bannerized. For any game additional arguments may be passed through the args value a comma deliminated list. Additional arguments are not specified here but are left to implementers to provide.

4.4 Literal Terms

4.4.1 The "LIVEGEEZSYS" Literal

The literal term "LIVEGEEZSYS" found anywhere within the bounds of a markup will be exchanged with the requested Ethiopic character set "sys" attribute value. Experience has shown this to be a valuable device for presetting the character set JavaScript variables and in links to LiveGe'ez servers.


The Local Link:

  <a href="/cgi-bin/LiveGeez?day=29&month=4&year=1991&sys=LIVEGEEZSYS">


  <a href="/cgi-bin/LiveGeez?day=29&month=4&year=1991&sys=Washra">

The Local Link:

  <a href="http://www.xyz.com/LiveGeez/LIVEGEEZSYS/">


  <a href="http://www.xyz.com/LiveGeez/Washra/">

4.4.2 The "LIVEGEEZLINK" Literal

The "LIVEGEEZLINK" literal is provided to mark hypertext links that should reference the LiveGe'ez processor:


The Local Link:
<a href="newFile.html" LIVEGEEZLINK>
 <a href="http://www.xyz.com/LiveGeez?&file=/dir1/dir2/newFile.html&sys=ET-Saba">

Where "http://www.xyz.com" and "/dir1/dir2/" comes from the "href" attribute value of the "base" markup; and the "sys" value is that of the file being processed.



Appendix A

Colors indicate interdependent encoding schemes spread over multiple typefaces. Generally red indicates the base encoding and green the complimentary encoding.

Table A.1: CGI Parameter Values for Ethiopic Encoding Systems


TrueType Font Systems

VendorEncoding NameType FacesCGI Value
Hahu Lite Gothic
Hahu Lite Serif
Hahu Lite Times
Acuwork Acuwork ALXethiopian ALXethiopian
AddisWord Addis One
AddisWord1 Addis
Addis Two AddisWord2
Alpas Alpas ET-Saba
ET-Saba Bold
Amharisch (?) TFanus Amharisch Amharisch
Brana Brana I BranaI Brana
Brana II BranaII
C.B. Hale (?) C.B. Hale A Amharic-A Amharic-A
C.B. Hale B Amharic-B
EthCITA Uni-Font    
Bi-Font Primary    
Bi-Font Secondary    
Ethiopian Computers & Software Ge'ezEdit GeèzEdit Amharic P GeezEditAmharicP
Ge'ezEdit98 EG Amharic
Ethiopic (?) Ethiopic1 ETHIOPIC PIC-1-regular ETHIOPIC
Ethiopic2 ETHIOPIC PIC-2-bold
EthioSoft TFanus EthioSoft EthioSoft
EthiO Systems Ethiopian ASCII Primary Ethiopia Primary
Ethiopia Primary Slanted
Washra  Primary
Washrasl  Primary Slanted
Wookianos Primary
YebSe Primary
Ethiopian ASCII Secondary Ethiopia Secondary Ethiopia Secondary Slanted
Washrax Secondary
Washraxsl Secondary Slanted
Wookianos Secondary
YebSe Secondary
EthioWalia EthioWalia AMH3 AMH3
Fidel Software (?) Fidelxtr1 FIDEL~`_SOFTWARE Fidel
Fidelxtr2 EXTRA~`_FIDEL
GeezBausi (?) TFanus GeezBausi GeezBausi
Ge'ezFont Ge'ezFont GeezAddis
Ge'ezFontOld geezBasic
Ge'ez Frontiers Foundation Ethiopian ASCII Primary GF Zemen Primary
GF Abebe Giorgis Primary
GF Yigezu Bisrat Primary
Ethiopian ASCII Extended-Secondary GF Zemen Secondary
GF Abebe Giorgis Secondary
GF Yigezu Bisrat Secondary
PFR he ENH Zena he
GF Zemen2K Ahadu
PFR le ENH Zena le
GF Zemen2K Kileitu
PFR He GF Zemen2K Selestu
Feedel Ge'ezigna Geezigna Geezigna
Ge'ez I Geez Geez
Ge'ez II Geez II
Ge'ezNew A GeezA
Geez Demo
Ge'ezNew B GeezB
Ge'ezNew C GeezC
MahNishtahnah Project Ge'ezEdit AmharQ AmharQ
Monotype Monotype 1 Amharic 1
Amharic Book 1
Monotype 2 Amharic 2
Amharic Book 2
Monotype 3 Amharic 3
Amharic Book 3
Monotype Alt Amharic_Alt Amharic_Alt
Monotype Number Amharic_Num
ET-NCI Italic
ET-SAMI Normal
ET-SAMI Normal Italic
ET-SAMI Bold Italic
NCIC Agafari AGF - Zemen
AGF - Dawit
AGF - Rejim
AGF - Yigezu Bisrat
Agafari -Ejji Tsihuf AGF - Ejji Tsihuf AGF-Ejji-Tsihuf
Dejene1 Agaw Agaw
Dejene2 AgawBd
OmniTech NCI Amharic  Kechin Normal
Amharic Yigezu Bisrat Normal
Amharic Gazetta Ordinay
Phonetic Systems Phonetic Systems GeezType GeezType
Power Ge'ez Power Ge'ez Ge'ez-1
Power Ge'ez Number Ge'ez-1 Number, etc
Samawerfa AddisWP AddisWP AddisWP
Addis98 Addis98 Addis98
SIL Et 1 Et 1 SILAddisAbaba SILAddisAbaba
Et 2 Et 2 SILAddisAbaba
Et 3 Et 3 SILAddisAbaba
TFanus TFanus TfanusGeez01 TfanusGeez01
TFanus New GeezTimesNew GeezTimesNew
Visual Ge'ez Visual Ge'ez VG2-Agazian
Wazema Wazema1 A1 Desta
A1 Kidan
A1 Qelem
A1 Tesfa
Wazema2 A2 Desta
A2 Kidan
A2 Qelem
A2 Tesfa

Typeface Independent Systems

VendorEncoding NameType FacesCGI Name
Japanese Industrial Standard JIS NA JIS
Japanese Unix Network JUNET NA JUNET
Unicode UTF-7 NA UTF7

Transliteration Systems

VendorEncoding NameType FacesCGI Name
Dehai Dehai NA Dehai
Ethiop Ethiop NA Ethiop
Mainz Mainz NA Mainz

Transcription Systems

VendorEncoding NameType FacesCGI Name
Qubee Qubee NA Qubee

Miscellaneous Systems

VendorEncoding NameType FacesCGI Name
C-Like CLike (\xABCD) NA CLike
clike (\xabcd) NA clike
Ge'ez Frontiers Foundation Image NA Image
Sun MicroSystems Java (\uABCD) NA Java
java (\uabcd) NA java
U+ U Plus (U+ABCD) NA UPlus