2003-12-07 00:13:30 +00:00
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
< html xmlns = "http://www.w3.org/1999/xhtml" >
<!-- @author David Chandler -->
<!-- @editor Emacs, baby! -->
< head >
< title > ACIP To Tibetan Converters< / title >
< meta http-equiv = "Content-Type" content = "text/html; charset=utf-8" / >
< script type = "text/javascript" src = "http://iris.lib.virginia.edu/tibet/scripts/thdl_scripts.js" > < / script >
< link rel = "stylesheet" type = "text/css" href = "http://iris.lib.virginia.edu/tibet/style/thdl-styles.css" / >
< / head >
< body >
< div id = "banner" >
< a id = "logo" href = "http://iris.lib.virginia.edu/tibet/index.html" > < img id = "test" alt = "THDL Logo" src = "http://iris.lib.virginia.edu/tibet/images/logo.png" / > < / a >
< h1 > The Tibetan & Himalayan Digital Library< / h1 >
< div id = "menubar" >
< script type = 'text/javascript' > function Go ( ) { return } < / script >
< script type = 'text/javascript' src = 'http://iris.lib.virginia.edu/tibet/scripts/new/thdl_menu_config.js' > < / script >
< script type = 'text/javascript' src = 'http://iris.lib.virginia.edu/tibet/scripts/new/menu_new.js' > < / script >
< script type = 'text/javascript' src = 'http://iris.lib.virginia.edu/tibet/scripts/new/menu9_com.js' > < / script >
< noscript > < p > Your browser does not support javascript.< / p > < / noscript >
< div id = 'MenuPos' > Menu Loading... < / div >
< / div > <!-- END menubar -->
< / div > <!-- END banner -->
< div id = "sub_banner" >
< div id = "search" >
< form method = "get" action = "http://www.google.com/u/thdl" >
< p >
< input type = "text" name = "q" id = "q" size = "15" maxlength = "255" value = "" / >
< input type = "submit" name = "sa" id = "sa" value = "Search" / >
< input type = "hidden" name = "hq" id = "hq" value = "inurl:iris.lib.virginia.edu" / >
< / p >
< / form >
< / div >
< div id = "breadcrumbs" >
< a href = "http://iris.lib.virginia.edu/tibet/index.html" > Home< / a > > < a href = "index.html" > Tools< / a > > < a href = "http://iris.lib.virginia.edu/tibet/tools/allfonts.html" > Fonts & Input< / a > > < a href = "http://iris.lib.virginia.edu/tibet/tools/conv.html" > Converters< / a > > < a href = "TMW_RTF_TO_THDL_WYLIE.html" > Converters in Jskad< / a > > ACIP To Tibetan Converters
< / div >
< / div > <!-- END banner -->
< div id = "main" >
< h2 > ACIP To Tibetan Converters< / h2 >
< p >
This document describes the ACIP-> Tibetan converters built atop
< a
href="http://iris.lib.virginia.edu/tibet/tools/jskad.html">Jskad< / a > .
These converters were initially written by David Chandler, a
volunteer with the < a
href="http://iris.lib.virginia.edu/tibet/index.html">Tibetan and
Himalayan Digital Library< / a > , in the latter half of 2003.
They built upon the work of Tony Duff, Edward Garrett, and Than
Garson, and they would not be possible without the assistance of
David Chapman, Robert Chilton, and André s Montano
Pellegrini. (Please correct, and forgive, any omissions from
these lists.)
< / p >
< p >
These converters accept < a href = "http://asianclassics.org" > Asian
Classics Input Project< / a > (ACIP) transliteration of Tibetan (using
ACIP's < a
href="http://asianclassics.org/download/tibetancode/ticode.pdf">Tibetan
Input Code< / a > ), a Roman transliteration scheme. ACIP has many
Buddhist texts available in ACIP transliteration, which alone makes
ACIP transliteration (or just ACIP for short) important.
< / p >
< p >
The converters here accept a text file of ACIP and output either a
Unicode UTF-8-encoded text file or a Rich Text Format (RTF) file of
< a href = "http://iris.lib.virginia.edu/tibet/tools/tmw.html" > Tibetan
Machine Web< / a > (TMW). The latter is ready to use onscreen and
to make beautiful hardcopy today; the former will be understood by
software for a long time to come.
< / p >
< p >
The converters are meant to produce perfect results even for
imperfect input. To give you an idea of the thought and care
that went into these converters, consider the following partial list
of features:
< / p >
< ul >
< li >
Four tiers of < a href = "#diagnostics" > warning and error
messages< / a > are available.
< / li >
< li >
Some transliterations specified by the ACIP standard are not
accepted (i.e., they cause < a href = "#diagnostics" > errors< / a > )
2003-12-15 08:15:39 +00:00
because they are used too often improperly in Release V texts
2003-12-07 00:13:30 +00:00
(e.g., {\}); some non-standard transliteration is understood
2003-12-15 08:15:39 +00:00
because it is used in ACIP Release V texts (e.g., {[DD1]}).
2003-12-07 00:13:30 +00:00
< / li >
< li >
Non-standard < a href = "#escapes" > Unicode character escapes< / a > are
supported. (In this way, the glyph that the ACIP {\} refers
to according to the standard can in fact be represented, via
{\u0F84}.)
< / li >
< li >
< a href = "#colors" > Color-coding< / a > can help find typos in the
input.
< / li >
< li >
A < a href = "#sub" > substitution< / a > mechanism allows for correcting
erroneous documents on the fly.
< / li >
< li >
The converters can output frequency < a
href="#stats">statistics< / a > .
< / li >
< li >
The < a href = "#lex" > " lexical analyzer" < / a > and < a
href="#parse">" parser" < / a > handle every intricacy of
2003-12-15 08:15:39 +00:00
real ACIP Release V texts.
2003-12-07 00:13:30 +00:00
< / li >
< li >
The knowledge regarding the TMW font has been verified by
independent teams as described < a
href="TMW_or_TM_To_X_Converters.html#vv">here< / a > .
< / li >
< / ul >
< p >
The ACIP-> Unicode and ACIP-> TMW converters are equally
good. There are some differences between the two,
though. The TMW font has only a fixed set of glyphs, whereas
Unicode can encode arbitrary Tibetan glyphs. Thus, the
hypothetical ACIP {GAI}, which parses as {G+AI} due to < a
href="#prefix">prefix rules< / a > , will give an error in an
ACIP-> TMW conversion because no glyph exists for this
stack. The ACIP-> Unicode conversion will succeed, having
generated correct Unicode. This is the only difference between
the two conversions.
< / p >
< p >
The converters are actively maintained; your < a
href="mailto:thdltools-devel@lists.sourceforge.net">feedback< / a > is
valued.
< / p >
< p >
Note that there are also < a
href="TMW_or_TM_To_X_Converters.html">TMW-> ACIP< / a > converters
available; this document does not cover them.
< / p >
< p >
In what follows, you will learn < a href = "#using" > how to use< / a > the
converters, including all the features listed above, and you'll find
a list of < a href = "#bugs" > known bugs< / a > and places where there is
< a href = "#room" > room for improvement< / a > .
< / p >
< a name = "using" > < / a > < h2 > Using the Converters< / h2 >
< p >
This section briefly describes how the converters are best used.
< / p >
< p >
The GUI and command-line interfaces are both sufficient; the GUI
interface is your best bet if you've not used the converters
before. To learn how to invoke these interfaces, read < a
href="TMW_RTF_TO_THDL_WYLIE.html#invok">these instructions< / a > .
< / p >
< p >
First, review the < a href = "#bugs" > known bugs< / a > and be sure you can
live with them.
< / p >
< p >
Now perform a trial conversion of your document with < a
href="#diagnostics">warnings< / a > disabled. You will first
ensure that no outright < a href = "#diagnostics" > errors< / a > appear in
the input. If any do, make a copy of the input, edit the
input, and feed it through again. Feel free to try this out as
soon as you're comfortable; the error messages themselves are
sometimes self-explanatory.
< / p >
< p >
Once all errors have been corrected, do a conversion with warning
level 'Some'. If any warnings mark real problems, correct
those problems.
< / p >
< p >
If you have the patience, now do a conversion with warning level
'Most' and correct further problems. If any warnings mark real
problems, correct those problems.
< / p >
< p >
The 'All' warning level is pedantic; you might find it useful if
you're writing software that is to produce ACIP transliteration that
is easily read by machines. If you find any useful warnings at
this level, report it as a bug -- such warnings should be 'Most' or
'Some' level.
< / p >
< p >
For best results, produce < a href = "#colors" > color-coded
output< / a > . Scan the output for non-< a
href="#native">native< / a > < i > tsheg bar< / i > s and ensure that they
match the original document (the one from which the ACIP
transliteration was produced). Color-coding is useful because,
for example, {ZHIGN} is probably a typo for {ZHING}; {ZHIGN} will
appear colored, whereas {ZHING} is not colored.
< / p >
< p >
Note that the ACIP {%} gives a warning every time. Use the < a
href="#escapes">Unicode escape< / a > {\u0F35} if you want to avoid
this warning, but < i > note well< / i > that Unicode escapes are not part
of the ACIP standard. Thus, other tools that work with ACIP
transliteration will likely not understand {\u0F35}.
< / p >
< p >
To save time, you may use the < a href = "#sub" > < i > tsheg-bar< / i >
substitution< / a > mechanism when appropriate.
< / p >
< p >
Even if your desired end result is Unicode output, an ACIP-> TMW
conversion is sometimes useful. One benefit is that errors
will appear for any ACIP < i > tsheg bar< / i > that refers to a consonant
stack not included in TMW. These stacks should be scrutinized,
because TMW contains over 500 of the most common consonant stacks.
< / p >
< p >
Finally, check a few folios by hand against the original document to
be sure that you're satisfied with the conversion.
< / p >
< a name = "diagnostics" > < / a > < h2 > Diagnostics: Warnings and Errors< / h2 >
< p >
These converters are designed such that the output is just what you
yourself would create by hand. Whenever there is doubt about
what output is desired, a warning or error is issued. This
means that a helpful warning or error message will appear in the
output, and that you will be told at the end of the conversion that
one or more warnings or errors have indeed occurred. You can
then search your output document for the text < tt > [#ERROR< / tt > or
< tt > [#WARNING< / tt > .
< / p >
< p >
There are four warning levels: 'None', 'Some', 'Most', and
'All'. Choose 'None' if you don't want any warnings to appear
in your output and be brought to your attention at the end of
conversion. Choose 'Some' if you want to see the most
important warnings, 'Most' if you want some real confidence in your
output, and 'All' if you've absolutely got to know that the output
is right.
< / p >
< p >
Errors will always appear; you cannot disable them.
< / p >
< p >
The following are some (but not all) error and warning messages,
accompanied by further explication:
< / p >
< ul >
< li >
< tt > [#ERROR CONVERTING ACIP DOCUMENT: The Unicode escape with
ordinal 3912 does not match up with any TibetanMachineWeb
glyph.]< / tt > appears for the input {\u0F48} because there is no
character at the Unicode codepoint U+0F48 (decimal 3912).
< / li >
< li >
< tt > [#ERROR The ACIP {G+N+NA} cannot be represented with the
TibetanMachine or TibetanMachineWeb fonts because no such glyph
exists in these fonts.]< / tt > appears because the Tibetan Machine
Web font has only a limited number of ready-made, precomposed
glyphs, and {G+N+NA} is not one of them. You'll only see
this error in an ACIP-> TMW conversion, not an ACIP-> Unicode
conversion.
< / li >
< li >
< tt > [#ERROR CONVERTING ACIP DOCUMENT: This converter cannot
convert the ACIP {x} to Tibetan because it is unclear what the
result should be.]< / tt > appears because the appropriate output for
this likely requires special mark-up.
< / li >
< li >
< tt > [#ERROR CONVERTING ACIP DOCUMENT: Lexical error: The ACIP {^}
must precede a tsheg bar.]< / tt > appears for
{^ GONG SA}, for example, because only
{^GONG SA} and {^ GONG SA} are supported in this
implementation.
< / li >
< li >
< tt > [#ERROR CONVERTING ACIP DOCUMENT: The tsheg bar ("syllable") :
has these errors: Cannot convert ACIP A: because A: is a "vowel"
without an associated consonant]< / tt > appears for the input {:}
because {:} cannot appear alone. (Sloppily, this message
exposes you to the internals of the converter, where {:} is
thought of as {A:} in some contexts.)
< / li >
< li >
< tt > [#ERROR CONVERTING ACIP DOCUMENT: Lexical error: The ACIP x
must be glued to the end of a tsheg bar, but this one was
not]< / tt > appears because {%}, {o}, and {x} are really only to be
applied to whole < i > tsheg bar< / i > s, and should not occur alone.
< / li >
< li >
< tt > [#WARNING CONVERTING ACIP DOCUMENT: The ACIP DGYA has been
interpreted as two stacks, not one, but you may wish to confirm
that the original text had two stacks as it would be an easy
mistake to make to see one stack and forget to input it with '+'
characters.]< / tt > appears because it helps evince the impact of < a
href="#prefix">prefix rules< / a > , a subtle point with regards to
ACIP because they are implied, but not discussed explicitly in
depth, by the ACIP standard.
< / li >
< li >
< tt > [#WARNING CONVERTING ACIP DOCUMENT: Warning: We're going with
{B+NA}, but only because our knowledge of prefix rules says that
{B}{NA} is not a legal Tibetan tsheg bar ("syllable")]< / tt >
appears for the same reason as above.
< / li >
< li >
< tt > [#WARNING CONVERTING ACIP DOCUMENT: Lexical warning: The ACIP
{%} is treated by this converter as U+0F35, but sometimes might
represent U+0F14 in practice. To avoid seeing this warning again,
change the input to use {\u0F35} instead of {%}.]< / tt > appears
because some ACIP transliteration out there does use {%} to mean
U+0F14.
< / li >
< / ul >
< p >
When warning or error messages refer to a 'Lexical error', that is
an error that occurs when < a href = "#lex" > breaking an input text up
into < i > tsheg bar< / i > s< / a > . To fully understand all warning
and error messages, a thorough understanding of < a href = "#lex" > that
process< / a > and of the < a href = "#parse" > interpretation of ACIP
< i > tsheg bar< / i > s< / a > is required.
< / p >
< a name = "colors" > < / a > < h2 > Coloration< / h2 >
< p >
For ACIP-> TMW conversions (not ACIP-> Unicode), color-coding of
< i > tsheg bar< / i > s is an option. The command-line converters
accept a flag < tt > --colors yes|no< / tt > ; the conversion GUI in
Jskad has a checkbox for color-coding.
< / p >
< p >
Warnings and errors appear in < font color = "red" > red< / font > ; < i > tsheg
bar< / i > s that would parse differently if other < a
href="#prefix">prefix rules< / a > were used appear in < font
color="yellow">yellow< / font > ; non-< a href = "#native" > native< / a >
< i > tsheg bar< / i > s appear in < font color = "green" > green< / font > .
< / p >
< a name = "stats" > < / a > < h2 > < i > Tsheg-bar< / i > Statistics< / h2 >
< p >
The ACIP-> Tibetan converters provide a simple-minded accounting
mechanism with which one can determine which < i > tsheg bar< / i > s
appear in a conversion or how many times each < i > tsheg bar< / i >
appears. This mechanism is for power users only at this point;
its user interface leaves much to be desired. If you wish to
produce frequency information, and if you are not familiar with some
sort of scripting (via Excel macros, Unix shell scripts, etc.), then
the output produced will likely be useless to you.
< / p >
< p >
To support the calculation of frequency statistics, that is, how
many times each < i > tsheg bar< / i > appears, the converter can output
all < i > tsheg bar< / i > s to the Java error console (i.e.,
< tt > System.err< / tt > ). Each will appear on the console as many
times as it appears in the input. To activate this
functionality, < a href = "#sysprops" > set the system property< / a >
< tt > org.thdl.tib.text.ttt.OutputAllTshegBars< / tt > to < tt > true< / tt > ,
and be prepared for voluminous output. Massaging this output
into a friendly tabular format is quite possible but not described
here; contact < a
href="mailto:thdltools-devel@lists.sourceforge.net">the
developers< / a > for help.
< / p >
< p >
To support the generation of syllabaries, the converter can output
each < i > tsheg bar< / i > encountered to the Java error console (i.e.,
< tt > System.err< / tt > ). Each will appear on the console only
once, no matter how many times it appears in the input. To
activate this functionality, < a href = "#sysprops" > set the system
property< / a > < tt > org.thdl.tib.text.ttt.OutputUniqueTshegBars< / tt > to
< tt > true< / tt > , and be prepared for voluminous output.
< / p >
< p >
If desired, each < i > tsheg bar< / i > output can be prefixed with a
string of your choice by < a href = "#sysprops" > setting the system
property< / a > < tt > org.thdl.tib.text.ttt.PrefixForOutputTshegBars< / tt >
to that string. This is useful if the converter is producing
other output on the console and you want to separate that output
from the statistics.
< / p >
<!-- DLC LINK TO THE EXCEL SPREADSHEET OF STATS -->
< a name = "sub" > < / a > < h2 > < i > Tsheg-bar< / i > Substitution< / h2 >
<!-- NOTE WELL: The text here is largely the same as the text in the
class comment for org.thdl.tib.text.ttt.MidLexSubstitution. -->
< p >
The ACIP-> Tibetan converters provide a mechanism for
automatically correcting common transliteration typos. For
example, if your document contains 100 occurrences of {KAsh} that
all in fact intend {K+sh}, then you can specify just once the rule
< tt > {KAsh}-> {K+sh}< / tt > , and all 100 occurrences will be treated
correctly. This mechanism is not very easy to use, but it is
completely customizable; you can specify any number of rules.
You can only perform such substitutions at the < i > tsheg bar< / i >
level, though. This means, for example, that you cannot
specify the rule < tt > {GONG SA}-> {^GONG SA}< / tt > ; you can only
specify < tt > {GONG}-> {^GONG}< / tt > , which would affect {GONG LA}
just as it would affect {GONG SA}.
< / p >
< p >
To perform substitutions, < a href = "#sysprops" > set the system
property< / a > < tt > org.thdl.tib.text.ttt.ReplacementMap< / tt > to be a
comma-delimited list of < tt > x=> y< / tt > pairs. For example,
if you think BLKU, which parses as B+L+KU, should parse as B-L+KU,
and you want KAsh to be parsed as K+sh because the input operators
mistyped it, then set < tt > org.thdl.tib.text.ttt.ReplacementMap< / tt >
to < tt > BLKU=> B-L+KU,KAsh=> K+sh< / tt > . Note that this will
not cause {B+L+KU} to become {B-L+KU} -- we are doing the
replacement during lexical analysis of the input file, not during
parsing. And it will cause {SBLKU} to become {SB-L+KU}, which
is parsed as {S+B-L+KU}, probably not what you wanted. If you
fear such things, you can see if they happen by setting the system
property < tt > org.thdl.tib.text.ttt.VerboseReplacementMap< / tt > to
< tt > true< / tt > , which will cause an informational message to be
printed on the Java console every time a replacement is made.
< / p >
< p >
Furthermore, you can use the regular expression notations < tt > ^< / tt >
and < tt > $< / tt > to denote the beginning and end of the < i > tsheg
bar< / i > , respectively. For example, < tt > ^BLKU$=> B-L+KU< / tt >
is a useful rule. Note that full regular expressions are not
supported -- the tool just borrows a bit of the notation. The
rule < tt > ^BLKU=> B-L+KU< / tt > means that {BLKUM} and {BLKU} will
both be replaced, but {SBLKU} and {SBLKUM} will not be. The
caret, < tt > ^< / tt > , means that we only match if BLKU is at the
beginning. The dollar sign, < tt > $< / tt > , means that we only
match if the pattern is at the end. The rule
< tt > BLKU$=> B-L+KU< / tt > will cause {SBLKU} to be replaced, but not
{BLKUM}. Note that performance is far better for
< tt > ^FOO$< / tt > than for < tt > ^FOO< / tt > , < tt > FOO$< / tt > , or
< tt > FOO< / tt > alone.
< / p >
< p >
Only one substitution is made per < i > tsheg bar< / i > .
< tt > ^FOO$< / tt > -style mappings will be tried first, then
< tt > ^FOO< / tt > -style, then < tt > FOO$< / tt > -style, and finally
< tt > FOO< / tt > -style.
< / p >
< p >
An example of a useful substitution is < tt > o$=> \u0F35< / tt > .
This is useful because the converters interpret the ACIP {o} as
U+0F37 by default, but you might prefer U+0F35 in your output.
< / p >
< p >
Note that you cannot literally replace {FOO} with {BAR} using this
mechanism -- because {F} is not an ACIP character, the lex will not
get far enough to use this substitution mechanism. This is not
considered a design flaw -- serious errors require user
intervention. Sophisticated users can use something akin to
perl, sed, or awk scripts to preprocess the input.
< / p >
< p >
Note also that you cannot use the rule < tt > ONYA=> O& < / tt > ,
although it would be nice if you could. Technically, {& }
is considered to be punctuation (i.e., that which divides < i > tsheg
bar< / i > s) and is not understood inside a < i > tsheg bar< / i > .
< / p >
< p >
Note that this mechanism is also useful for fixing problems in the
converter itself rather than in the input.
< / p >
< a name = "escapes" > < / a > < h2 > Unicode Character Escapes< / h2 >
< p >
The ACIP-> Tibetan converters support some non-standard extensions
to the < a
href="http://asianclassics.org/download/tibetancode/ticode.pdf">ACIP
Tibetan Input Code Standard< / a > . One of those is Unicode
character escape sequences. This extension makes it possible
to represent characters that the < a
href="http://asianclassics.org/download/tibetancode/ticode.pdf">ACIP
standard< / a > does not address, and to represent one character,
U+0F84, that ACIP does address with the transliteration {\} but that
is misused in practice so often to refer to U+0F3C that the
ACIP-> Tibetan converters always produce an error upon seeing {\}.
< / p >
< p >
Outside of comments, {\uKLMN} is interpreted as referring to the
Unicode character with ordinal < i > KLMN< / i > , where each of K, L, M,
and N are case-insensitive hexadecimal digits. For example,
the ACIP {KA KHA GA NGA } is exactly equivalent to
{\u0F40\u0f0B\u0F41\u0F0B\u0F42\u0F0B\u0F44\u0f0b}. Unicode
escapes produce the obvious Unicode in an ACIP-> Unicode
conversion, and they produce the correct TMW glyph in an
ACIP-> TMW conversion. There are limits, though, when
converting to TMW; multiple escapes in sequence are not handled
correctly. It would take a Unicode to TMW converter to produce
the correct glyphs for {\u0F42\u0F92\u0FB7\u0F7C}. The escapes
for vowels and other characters that are mapped to multiple TMW
glyphs are also not handled perfectly. Best practice is to use
escapes only when necessary in an ACIP-> TMW conversion.
< / p >
< p >
The Unicode character represented need not be a Tibetan one; for
example, {\u0040} produces the at sign, < tt > @< / tt > .
< / p >
2003-12-08 07:21:45 +00:00
< p >
The latest < a
href="http://iris.lib.virginia.edu/tibet/collections/langling/ewts/">Extended
Wylie Transliteration Scheme< / a > standard has assigned private-use
area (PUA) Unicode codepoints to some TMW glyphs. ACIP
documents that have a < a href = "#escapes" > Unicode escape< / a > in the
range U+F021 to U+F0FF, inclusive, are interpreted as intending
these TMW glyphs. ACIP-> Unicode produces an error for such
an escape because it is font-dependent and not standard. Other
tools will likely not understand such Unicode, so the converter will
not produce it. If you want it in the output, it is there in
the error message.
< / p >
2003-12-07 00:13:30 +00:00
< p >
Note well the < a href = "#bugs" > known bug< / a > with regard to
whitespace in transliteration that follows a Unicode escape.
In large part, this bug affects characters that can be
transliterated by other, simpler, standard means.
< / p >
< p >
If you do want to disable the use of Unicode escapes, < a
href="#sysprops">set the system property< / a >
< tt > thdl.tib.text.disallow.unicode.character.escapes.in.acip< / tt > to
< tt > true< / tt > .
< / p >
< a name = "lex" > < / a > < h2 > Breaking a Text Up Into < i > tsheg bar< / i > s< / h2 >
< p >
The ACIP-> Tibetan converters all take ACIP transliteration as
input. The first step in conversion is to break up the input
into manageable pieces. (This is known as < i > lexical
analysis< / i > in the context of programming languages, and you may
see the term in diagnostic messages though a linguist who studies
human language like Tibetan might balk at the term.) The
correct pieces in this case are < i > tsheg bar< / i > s (in ACIP, {TSEG
BAR}), punctuation, comments, whitespace, folio markers, formatting
codes, etc. In this section, the intracacies of how the
converter does that will be laid bare. With luck, this will
help you understand why the converter treated one space character
(i.e, ' ', U+0020) as a < i > tsheg< / i > and another as Tibetan
whitespace.
< / p >
< p >
The Tibetan term < i > tsheg bar< / i > refers to " the stuff between
the dots" . In the ACIP {BKRA SHIS [# Notice that
this comment is embedded in the Tibetan greeting pronounced 'tashi
delay']BDE LEGS,}, there are four < i > tsheg bar< / i > s, 'BKRA',
'SHIS', 'BDE', and 'LEGS'. In this case 'BDE' is literally
" between the dots" ; i.e., it is sandwiched by two U+0F0B
characters (because comments are in a sense invisible). One of
the " dots" that touches 'LEGS' does not look like a dot --
it is a < i > shad< / i > , U+0F0D. The lexical analyzer also finds
one comment, which will appear in a Latin typeface in the output,
and it finds four pieces of punctuation -- three < i > tsheg< / i > s and a
< i > shad< / i > .
< / p >
< p >
The converter will not allow an illegal character into a < i > tsheg
bar< / i > . For example, {jA} is an error and causes an error
message to appear in the output.
< / p >
< p >
Now that the basic operation is clear from the above example, let's
cover the fine points of how standard ACIP is handled. We'll
also cover some non-standard constructs that appear commonly in
2003-12-15 08:15:39 +00:00
actual ACIP Release V texts.
2003-12-07 00:13:30 +00:00
< / p >
< p >
The first construct that deserves explanation is the line
break. By the ACIP standard, line breaks in the input do not
become line breaks in the output unless there are two line breaks in
the input. For example, the ACIP snippet below has only one
line break in the output although three line breaks appear in the
input:
< / p >
< pre >
BKRA SHIS
BDE LEGS,
THUGS RJE CHE ... and so on ...
< / pre >
< p >
One fine point is that the converter does not require a space before
a line break. If {SHIS} appears before a line break, the converter
inserts a space so that it's treated just like {SHIS } is
treated. This oddity is needed to convert real ACIP documents.
< / p >
< p >
Another fine point is that ACIP's {^} character " eats" a
following space or a newline. This is so that
{^ GONG SA } is treated identically to
{^GONG SA }.
< / p >
< p >
Comments appear in a Latin typeface always. Comments are not
allowed just anywhere -- a comment cannot occur within a single
< i > tsheg bar< / i > , for example, and it cannot appear between a
< i > tsheg bar< / i > and the < i > tsheg< / i > that follows it. That
is, {BD[#COMMENT]E} is not like {BDE}, and {BDE[#COMMENT] LEGS}
is not like {BDE LEGS} (though {BDE [#COMMENT]LEGS} is).
< / p >
< p >
Corrections are interpreted as Tibetan, not English, by default, but
there is a built-in list of corrections that should appear in the
output in a Latin typeface. (Actually, any correction that
starts with a certain string will appear in a Latin typeface.)
The full list is the following:
< / p >
< pre >
"LINE" // from KD0001I1.ACT
"DATA" // from KL0009I2.INC
"BLANK" // from KL0009I2.INC
"NOTE" // from R0001F.ACM
"alternate" // from R0018F.ACE
"02101-02150 missing" // from R1003A3.INC
"51501-51550 missing" // from R1003A52.ACT
"BRTAGS ETC" // from S0002N.ACT
"TSAN, ETC" // from S0015N.ACT
"SNYOMS, THROUGHOUT" // from S0016N.ACT
"KYIS ETC" // from S0019N.ACT
"MISSING" // from S0455M.ACT
"this" // from S6850I1B.ALT
"THIS" // from S0057M.ACT
< / pre >
< p >
Somewhat related is the converter's treatment of a few oddball
comments. The oddity is that these comments use the syntax
{[COMMENT]} rather than the standard syntax {[#COMMENT]}. The
converter will treat the following as comments:
< / p >
< pre >
From S5274I.ACT:
"[FIRST]"
From S5274I.ACT:
"[SECOND]"
From S0216M.ACT:
"[Additional verses added by Khen Rinpoche here are]"
From S0216M.ACT:
"[ADDENDUM: The text of]"
From S0216M.ACT:
"[END OF ADDENDUM]"
From S0216M.ACT:
"[Some of the verses added here by Khen Rinpoche include:]"
From S0216M.ACT (note the typo):
"[Note that, in the second verse, the {YUL LJONG} was orignally {GANG LJONG},
and is now recited this way since the ceremony is not only taking place in Tibet.]"
From S6954E1.ACT:
"[text missing]"
From TD3817I.INC:
"[INCOMPLETE]"
From S0935m.act:
"[MISSING PAGE]"
From S0975I.INC:
"[MISSING FOLIO]"
From S0839D1I.INC:
"[UNCLEAR LINE]"
From SE6260A.INC:
"[THE FOLLOWING TEXT HAS INCOMPLETE SECTIONS, WHICH ARE ON ORDER]"
From SE6260A.INC:
"[@DATA INCOMPLETE HERE]"
From SE6260A.INC:
"[@DATA MISSING HERE]"
From TD4035I.INC:
"[LINE APPARENTLY MISSING THIS PAGE]"
From TD4226I2.INC:
"[DATA INCOMPLETE HERE]"
To be consistent with the above:
"[DATA MISSING HERE]"
From S0018N.ACT:
"[FOLLOWING SECTION WAS NOT AVAILABLE WHEN THIS EDITION WAS
PRINTED, AND IS SUPPLIED FROM ANOTHER, PROBABLY THE ORIGINAL:]"
From S0018N.ACT:
"[THESE PAGE NUMBERS RESERVED IN THIS EDITION FOR PAGES
MISSING FROM ORIGINAL ON WHICH IT WAS BASED]"
From S0018N.ACT:
"[PAGE NUMBERS RESERVED FROM THIS EDITION FOR MISSING
SECTION SUPPLIED BY PRECEDING]"
From S0057M.ACT:
"[SW: OK]"
From S0057M.ACT:
"[m:ok]"
From S0057M.ACT:
"[A FIRST ONE
MISSING HERE?]"
From S0195A1.INC:
"[THE INITIAL PART OF THIS TEXT WAS INPUT BY THE SERA MEY LIBRARY IN
TIBETAN FONT AND NEEDS TO BE REDONE BY DOUBLE INPUT]"
< / pre >
< p >
The converter also supports several non-standard folio
2003-12-15 08:15:39 +00:00
markers. A review of ACIP Release V texts determined that the
2003-12-07 00:13:30 +00:00
following types of folio markers can appear:
< / p >
< pre >
@001
@001A
@001B
@01A.3
@012A.3
@[07B]
@00007B
@00007
@B00007
@[00007A]
< / pre >
< p >
2003-12-15 08:15:39 +00:00
Similarly, to support real ACIP Release V texts, the converter
2003-12-07 00:13:30 +00:00
treats {[DD1]}, {[DD2]}, {[ DD ]}, and {[DDD]} just like {[DD]}
(which is specified in the ACIP standard). It treats {[ BP ]}
and {[BLANK PAGE]} just like {[BP]}, also.
< / p >
< p >
The lists above were created by a most fallible process of reviewing
2003-12-15 08:15:39 +00:00
a large number of ACIP Release V texts. Your suggestions for
2003-12-07 00:13:30 +00:00
additions to these lists are highly valued; please contact < a
href="mailto:thdltools-devel@lists.sourceforge.net">the
developers< / a > .
< / p >
< p >
2003-12-10 06:57:12 +00:00
The converters will insert a < i > tsheg< / i > in some places where no ACIP
{ } appears; this happens after {PA} and {DANG,} below:
< / p >
< pre >
GA PA
GA PHA
DAM,
LHAG
GA CA,
GA
< / pre >
< p >
Note that a space appears after {PHA}, and a comma appears after
{CA}, but {PA} has nothing between it and a line break. The
converters are smart enough to insert a < i > tsheg< / i > regardless.
< / p >
< p >
Also missing from the above ACIP, but inserted automatically by the
converters, is Tibetan whitespace; the converter sees
{DAM, LHAG} instead of {DAM,LHAG} above.
< / p >
< p >
If such automatic corrections are not desired, try using a Unicode
< a href = "#escapes" > escape< / a > before the line break instead of {PA}
or {,}.
< / p >
< p >
The converters also treat {NGA,} as a typo for {NGA ,}
(actually, {NGA\u0F0C,} since one wouldn't want a line break to
occur after the < i > tsheg< / i > and cause a < i > shad< / i > to begin a
line; see the section on formatting Tibetan texts in the < i > Tibetan!
5.1< / i > documentation) because Tibetan typesetting requires that NGA
not appear directly before a < i > shad< / i > . (Perhaps {NGA,}
would look too much like {KA}.)
< / p >
< p >
The converters embody the rule that a < i > shad< / i > does not appear
after GA or KA unless a < i > shabs kyu< / i > vowel is on the GA or
KA. For example, the space in {MA ,HA} is a < i > tsheg< / i > ,
and the space in {KU ,HA} is a < i > tsheg< / i > , but the space in
{GA ,HA} is Tibetan whitespace.
< / p >
< p >
If you find that the converters put a < i > tsheg< / i > where it does not
belong, miss a < i > tsheg< / i > , or put whitespace where it does belong,
please contact < a
href="mailto:thdltools-devel@lists.sourceforge.net">the
developers< / a > .
< / p >
< p >
Though the ACIP standard does not mention it, it appears that some
2003-12-15 08:15:39 +00:00
ACIP Release V texts use a period (i.e., {.}) to indicate a
2003-12-10 06:57:12 +00:00
non-breaking tsheg (i.e., U+0F0C). Search for {NGO.,},
{....,DAM}, etc. Unless {,}, {.}, or a letter (i.e., a through
z) follows the {.}, it is only grudingly interpreted as a
non-breaking tsheg -- a warning is generated, too. FIXME: Is
this right? Allow for treating {.} as an outright error.<!--
DLC FIXME -->
< / p >
< p >
Note that the treatment of the very last line in an input text is
circumspect.<!-- DLC FIXME -->
< / p >
2003-12-07 00:13:30 +00:00
<!-- <h1>DLC</h1>
< pre >
DLC warn on BUR'ANG because BUR'ANG and BUR-'ANG both appear once in ACIP files. Tell RC. DLC: subst it!
lex: Spaces
DLC configurable tibetan spaces bhutan vs. tibet
{NGA,} -> {NGA ,}
DLC hyphens and ' end lines but shouldn't, eh?
DLC ACIP {.} is just an error! Have the error message mention {\u0F0C} for those desiring a non-breaking tsheg.
DLC whitespace -- newlines [final newline DLC?], spaces
< / pre > -->
< / p >
< a name = "parse" > < / a > < h2 > Parsing < i > tsheg bar< / i > s: Greedy Stacking and
Nativeness< / h2 >
< p >
This section is a technical reference sufficiently detailed so that
you can fully understand the inner workings of the converter as it
decides which Unicode or TMW to use for a given < i > tsheg
bar< / i > . The problem of < a href = "#lex" > breaking up a text into
< i > tsheg bar< / i > s< / a > is a separate issue; this section describes
what happens to a < i > tsheg bar< / i > after it's been chipped away from
the text.
< / p >
< a name = "native" > < / a >
< p >
The ACIP-> Tibetan converters have a notion of
< i > nativeness< / i > . Each < i > tsheg bar< / i > is either native
Tibetan or non-native. For example, in Buddhist texts written
in Tibetan, Sanskrit mantras often appear in Tibetan
characters. This " Tibetanized Sanskrit" is
non-native. The < i > tsheg bar< / i > s that make up this mantra
(and here, take " tsheg bar" somewhat literally to mean the
characters delimited by punctuation and whitespace) are some native
and some non-native in the converter's eyes. For example, the
< i > tsheg bar< / i > {MA } appears in some mantras, and is thus in
fact non-native. The converter, however, treats {MA } as
native in all contexts. Thus, " native" is a
technical term with a slightly different meaning than usual.
< / p >
< p >
The idea of nativeness is important because it affects how the
converter treats a < i > tsheg bar< / i > . In ACIP transliteration,
the rule is that consonants stack up until punctuation, whitespace,
or a vowel appears. For example, {RDZYA} is equivalent to
{R+DZ+YA}. ({DZA} always means the letter {DZA} itself, never
{D+ZA}.) But this greedy stacking does not apply to {SOGS},
which is equivalent to {SOG-S}, not {SOG+S}. Why not?
Because {SOGS} is a native < i > tsheg bar< / i > where GA is the suffix
and SA is the postsuffix. Similarly, {GNAD} is {G-NAD}, not
{G+NAD}. Why? Because GA is a prefix in this native
Tibetan < i > tsheg bar< / i > .
< / p >
< p >
In this section, we will illustrate the inner workings of this
aspect of the converter. You will be able to determine which
snippets of transliteration the converter considers to be native
< i > tsheg bar< / i > s, where greedy stacking does not apply except for
the root stack, and which snippets are non-native, and thus wholly
subject to greedy stacking.
< / p >
< h3 > Anatomy of a Native < i > tsheg bar< / i > < / h3 >
< p >
First, the < a href = "#lex" > lexical analyzer< / a > ensures that only the
Tibetan and Sanskrit consonants, the vowels {A}, {I}, {U}, {E}, {O},
{OO}, {EE}, {i}, {'A}, {'I}, {'U}, {'E}, {'O}, {'OO}, {'EE}, and
{'i}, and the adornments {m} and {:} are allowed in a < i > tsheg
bar< / i > .
< / p >
< p >
As far as the converter is concerned, a native < i > tsheg bar< / i >
consists of an optional prefix, a native root stack, an optional
suffix, an optional postsuffix (also known as a secondary suffix)
that may only be present if a suffix is present, and zero or more
< i > appendages< / i > (my term, created because I don't know what a
grammarian calls such a thing). An appendage is one of the
following stack sequences:
< / p >
< ul >
< li > {'E}< / li >
< li > {'I}< / li >
< li > {'O}< / li >
< li > {'U}< / li >
< li > {'US}< / li >
< li > {'UR}< / li >
< li > {'UM}< / li >
< li > {'ONG}< / li >
< li > {'ONGS}< / li >
< li > {'OS}< / li >
< li > {'IS}< / li >
< li > {'UNG}< / li >
< li > {'ANG}< / li >
< li > {'AM}< / li >
< / ul >
< p >
A < i > tsheg bar< / i > is non-native if it has a non-native root stack
or if it contains the {:} character. Any vowel is allowed on a
native root stack, even {'EEm}, {i}, or the like.
< / p >
< p >
The rule about native root stacks is important, for example, in
determining that {KTYAMS} is {K+T+YAM+SA} instead of {K+T+YAMASA}
(because K+T+YA is not a native stack). Another example is
{GNVA}, which is treated like {G+N+VA}, not {G-N+VA}, even though
{GNA} is treated like {G-NA} because NA can take a GA prefix.
The complete list of native stacks is the following:
< / p >
< ul >
< li > KA< / li >
< li > KHA< / li >
< li > GA< / li >
< li > NGA< / li >
< li > CA< / li >
< li > CHA< / li >
< li > JA< / li >
< li > NYA< / li >
< li > TA< / li >
< li > THA< / li >
< li > DA< / li >
< li > NA< / li >
< li > PA< / li >
< li > PHA< / li >
< li > BA< / li >
< li > MA< / li >
< li > TZA< / li >
< li > TSA< / li >
< li > DZA< / li >
< li > WA< / li >
< li > ZHA< / li >
< li > ZA< / li >
< li > 'A< / li >
< li > YA< / li >
< li > RA< / li >
< li > LA< / li >
< li > SHA< / li >
< li > SA< / li >
< li > HA< / li >
< li > AA< / li >
< li > R+KA (RKA)< / li >
< li > R+GA (RGA)< / li >
< li > R+NGA (RNGA)< / li >
< li > R+JA (RJA)< / li >
< li > R+NYA (RNYA)< / li >
< li > R+TA (RTA)< / li >
< li > R+DA (RDA)< / li >
< li > R+NA (RNA)< / li >
< li > R+BA (RBA)< / li >
< li > R+MA (RMA)< / li >
< li > R+TZA (RTZA)< / li >
< li > R+DZA (RDZA)< / li >
< li > L+KA (LKA)< / li >
< li > L+GA (LGA)< / li >
< li > L+NGA (LNGA)< / li >
< li > L+CA (LCA)< / li >
< li > L+JA (LJA)< / li >
< li > L+TA (LTA)< / li >
< li > L+DA (LDA)< / li >
< li > L+PA (LPA)< / li >
< li > L+BA (LBA)< / li >
< li > L+HA (LHA)< / li >
< li > S+KA (SKA)< / li >
< li > S+GA (SGA)< / li >
< li > S+NGA (SNGA)< / li >
< li > S+NYA (SNYA)< / li >
< li > S+TA (STA)< / li >
< li > S+DA (SDA)< / li >
< li > S+NA (SNA)< / li >
< li > S+PA (SPA)< / li >
< li > S+BA (SBA)< / li >
< li > S+MA (SMA)< / li >
< li > S+TZA (STZA)< / li >
< li > K+VA (KVA)< / li >
< li > KH+VA (KHVA)< / li >
< li > G+VA (GVA)< / li >
< li > C+VA (CVA)< / li >
< li > NY+VA (NYVA)< / li >
< li > T+VA (TVA)< / li >
< li > D+VA (DVA)< / li >
< li > TZ+VA (TZVA)< / li >
< li > TS+VA (TSVA)< / li >
< li > ZH+VA (ZHVA)< / li >
< li > Z+VA (ZVA)< / li >
< li > R+VA (RVA)< / li >
< li > SH+VA (SHVA)< / li >
< li > S+VA (SVA)< / li >
< li > H+VA (HVA)< / li >
< li > K+YA (KYA)< / li >
< li > KH+YA (KHYA)< / li >
< li > G+YA (GYA)< / li >
< li > P+YA (PYA)< / li >
< li > PH+YA (PHYA)< / li >
< li > B+YA (BYA)< / li >
< li > M+YA (MYA)< / li >
< li > K+RA (KRA)< / li >
< li > KH+RA (KHRA)< / li >
< li > G+RA (GRA)< / li >
< li > T+RA (TRA)< / li >
< li > TH+RA (THRA)< / li >
< li > D+RA (DRA)< / li >
< li > P+RA (PRA)< / li >
< li > PH+RA (PHRA)< / li >
< li > B+RA (BRA)< / li >
< li > M+RA (MRA)< / li >
< li > SH+RA (SHRA)< / li >
< li > S+RA (SRA)< / li >
< li > H+RA (HRA)< / li >
< li > K+LA (KLA)< / li >
< li > G+LA (GLA)< / li >
< li > B+LA (BLA)< / li >
< li > Z+LA (ZLA)< / li >
< li > R+LA (RLA)< / li >
< li > S+LA (SLA)< / li >
< li > R+K+YA (RKYA)< / li >
< li > R+G+YA (RGYA)< / li >
< li > R+M+YA (RMYA)< / li >
< li > R+G+VA (RGVA)< / li >
< li > R+TZ+VA (RTZVA)< / li >
< li > S+K+YA (SKYA)< / li >
< li > S+G+YA (SGYA)< / li >
< li > S+P+YA (SPYA)< / li >
< li > S+B+YA (SBYA)< / li >
< li > S+M+YA (SMYA)< / li >
< li > S+K+RA (SKRA)< / li >
< li > S+G+RA (SGRA)< / li >
< li > S+N+RA (SNRA)< / li >
< li > S+P+RA (SPRA)< / li >
< li > S+B+RA (SBRA)< / li >
< li > S+M+RA (SMRA)< / li >
< li > G+R+VA (GRVA)< / li >
< li > D+R+VA (DRVA)< / li >
< li > PH+Y+VA (PHYVA)< / li >
< / ul >
< p >
(Some would argue that LVA is notably absent. It is seen in
ACIP Buddhist texts in {AELVA}, {LVAm}, {LVU}, {LVUN}, {LVAR},
{LVE}, {LVANG}, and {LVA}. Greedy stacking affects none of
these < i > tsheg bar< / i > s' parsing, however.)
< / p >
< a name = "prefix" > < / a >
< p >
Not all characters can be prefixes and the like. Only the five
prefixes (GA, DA, BA, MA, 'A), ten suffixes (GA, NGA, DA, NA, BA,
MA, 'A, RA, LA, SA), and two postsuffixes (DA, SA) every Tibetan
student knows are allowed, and they cannot appear with vowels.
(In {LE'U}, {'} is not a suffix -- it is part of an
appendage.) In fact, certain prefixes may only appear with
certain root stacks. The reason that these prefix rules matter
is that they govern how < i > tsheg bar< / i > s are parsed. For
example, {GNA} is parsed like {G-NA}, because NA takes a GA
prefix. But {GPA} is parsed like {G+PA}, because PA does not
take a GA prefix.
< / p >
< p >
Prefix rules are a topic of some controversy; different grammars
give different lists of prefix rules. For a converter, it is
important that the converter's knowledge of prefix rules matches the
knowledge of the person who typed in the ACIP transliteration, not
that the converter agrees with a grammarian. For example, if
the input technician thought that PA could take a GA prefix, then
the converter will produce {G+PA} when {G-PA} was intended.
For this reason, the converter can produce a warning every time a
prefix rule prohibited the treatment of one of the five prefixes as
a prefix. For example, {GPA} produces this warning.
However, {GNA} produces no warning, because the converter assumes
that it is unlikely that an input technician would enter {GNA} upon
seeing {G+NA}. Part of the reason for this assumption is that
the < i > Asian Classics Input Project Entry Operator Transcription
Chart< / i > as of Spring, 1993, explicitly enumerates the following
cases for special treatment by input operators:
< / p >
< ul >
< li > {BDA'} vs. {B+DA}< / li >
< li > {DBANG} vs. {D+BA}< / li >
< li > {DGA'} vs. {D+GA}< / li >
< li > {DGRA} vs. {D+GRA}< / li >
< li > {DGYES} vs. {D+GYA}< / li >
< li > {DMAR} vs. {D+MA}< / li >
< li > {GDA'} vs. {G+DA}< / li >
< li > {GNAD} vs. {G+NA}< / li >
< li > {MNA'} vs. {M+NA}< / li >
< / ul >
< p >
Regardless, for best results, you should ensure that the input
technician's knowledge of prefix rules matches the converter's
knowledge. The following are the legal combinations of prefix
and root stack in the converter's eyes:
< / p >
< ul >
< li >
The BA prefix may occur with any of the following stacks:
< ul >
< li > KA< / li >
< li > SA< / li >
< li > CA< / li >
< li > TA< / li >
< li > TZA< / li >
< li > GA< / li >
< li > DA< / li >
< li > ZHA< / li >
< li > ZA< / li >
< li > SHA< / li >
< li > K+YA (KYA)< / li >
< li > G+YA (GYA)< / li >
< li > K+RA (KRA)< / li >
< li > G+RA (GRA)< / li >
< li > S+RA (SRA)< / li >
< li > G+LA (GLA)< / li >
< li > K+LA (KLA)< / li >
< li > Z+LA (ZLA)< / li >
< li > R+LA (RLA)< / li >
< li > S+LA (SLA)< / li >
< li > S+KA (SKA)< / li >
< li > S+GA (SGA)< / li >
< li > S+NGA (SNGA)< / li >
< li > S+NYA (SNYA)< / li >
< li > S+TA (STA)< / li >
< li > S+DA (SDA)< / li >
< li > S+NA (SNA)< / li >
< li > S+TZA (STZA)< / li >
< li > R+KA (RKA)< / li >
< li > R+GA (RGA)< / li >
< li > R+NGA (RNGA)< / li >
< li > R+JA (RJA)< / li >
< li > R+NYA (RNYA)< / li >
< li > R+TA (RTA)< / li >
< li > R+DA (RDA)< / li >
< li > R+NA (RNA)< / li >
< li > R+TZA (RTZA)< / li >
< li > R+DZA (RDZA)< / li >
< li > L+CA (LCA)< / li >
< li > L+TA (LTA)< / li >
< li > L+DA (LDA)< / li >
< li > R+K+YA (RKYA)< / li >
< li > R+G+YA (RGYA)< / li >
< li > S+K+YA (SKYA)< / li >
< li > S+G+YA (SGYA)< / li >
< li > S+K+RA (SKRA)< / li >
< li > S+G+RA (SGRA)< / li >
< / ul >
< / li >
< li >
The GA prefix may occur with any of the following stacks:
< ul >
< li > CA< / li >
< li > DA< / li >
< li > NA< / li >
< li > NYA< / li >
< li > SA< / li >
< li > SHA< / li >
< li > TA< / li >
< li > TZA< / li >
< li > YA< / li >
< li > ZA< / li >
< li > ZHA< / li >
< / ul >
< / li >
< li >
The 'A prefix may occur with any of the following stacks:
< ul >
< li > GA< / li >
< li > JA< / li >
< li > DA< / li >
< li > BA< / li >
< li > DZA< / li >
< li > KHA< / li >
< li > CHA< / li >
< li > THA< / li >
< li > PHA< / li >
< li > TSA< / li >
< li > PH+YA (PHYA)< / li >
< li > B+YA (BYA)< / li >
< li > KH+YA (KHYA)< / li >
< li > G+YA (GYA)< / li >
< li > B+RA (BRA)< / li >
< li > KH+RA (KHRA)< / li >
< li > G+RA (GRA)< / li >
< li > D+RA (DRA)< / li >
< li > PH+RA (PHRA)< / li >
< / ul >
< / li >
< li >
The MA prefix may occur with any of the following stacks:
< ul >
< li > KHA< / li >
< li > GA< / li >
< li > CHA< / li >
< li > JA< / li >
< li > THA< / li >
< li > TSA< / li >
< li > DA< / li >
< li > DZA< / li >
< li > NGA< / li >
< li > NYA< / li >
< li > NA< / li >
< li > KH+YA (KHYA)< / li >
< li > G+YA (GYA)< / li >
< li > KH+RA (KHRA)< / li >
< li > G+RA (GRA)< / li >
< / ul >
< / li >
< li >
The DA prefix may occur with any of the following stacks:
< ul >
< li > BA< / li >
< li > GA< / li >
< li > KA< / li >
< li > MA< / li >
< li > NGA< / li >
< li > PA< / li >
< li > B+RA (BRA)< / li >
< li > B+YA (BYA)< / li >
< li > G+RA (GRA)< / li >
< li > G+YA (GYA)< / li >
< li > K+RA (KRA)< / li >
< li > K+YA (KYA)< / li >
< li > M+YA (MYA)< / li >
< li > P+RA (PRA)< / li >
< li > P+YA (PYA)< / li >
< / ul >
< / li >
< / ul >
< p >
In the above list, the presence of wa-zur (ACIP {V}) does not
disallow a prefix-root combination; nor does the presence of any
vowel, even {'EEm}. The presence of {:} does disallow
prefix-root combinations; e.g., {GN'EEm} is {G-N'EEm}, but {GNA:} is
{G+NA:}. ({GNVA} is parsed as {G+N+VA} not because NVA cannot
take a GA prefix, but because NVA is not a native stack.)
< / p >
< p >
The converter will allow any suffix to go with any native root or
prefix-root combination; it will allow any postsuffix to follow any
suffix. It will allow any appendage on any native < i > tsheg
bar< / i > .
< / p >
< p >
For example, {SOGS}, {BSOGS}, {BS'EEmGS}, {LE'U'I'O} and
{BSKYABS-'UR-'UNG-'O} are all native < i > tsheg bar< / i > s in the
converter's eyes. Note the need for disambiguation: {PAM-'AM}
is a native < i > tsheg bar< / i > , but {PAM'AM}, which parses as the
three stacks {PA}, {M'A}, and {MA}, is not. (In practice,
appendages rarely occur after prefixes. {BUR-'ANG} appears at
least once in ACIP files and {DGA'-'AM} appears at least twice, but
these may be typos. The converter does allow it, though.
It thinks {BIR'U} and {WAN'U} (which also occur, but only very
rarely) are both non-native, though, and thus treats {'} as U+0F71
(subscribed) and not U+0F60 (full form) in each case.)
< / p >
< p >
Note a fine point. When turning a < i > tsheg bar< / i > into
Tibetan, the ACIP-> Tibetan converters assume that subjoined YA
and RA consonants are not fixed-form -- not U+0FBB and U+0FBC -- but
rather are the usual subjoined forms U+0FB1 and U+0FB2. The
only exceptions are the stacks R+Y, Y+Y, and n+d+Y, which are known
to have fixed-form subjoined YA, and the stacks n+d+R+Y (where RA
but not YA is full-form) and K+sh+R, which are known to have
2004-04-17 17:30:22 +00:00
fixed-form subjoined RA. (Wa-zur, U+0FAD, is never confused
with full-form subjoined WA, U+0FBA, because ACIP represents the
former with {V} and the latter with {W}.) Furthermore, the
converter only generates U+0F6A, the fixed-form RA (< i > rango< / i > ),
for the stacks R+W, R+Y, R+SH, R+SH+Y, R+sh, R+sh+n, R+sh+n+Y,
R+sh+M, R+sh+Y, and R+S; U+0F62 is always produced for the top-most
RA in any other stack. (Note that U+0F62 is sometimes
2003-12-07 00:13:30 +00:00
displayed as a fixed-form RA itself, as in {RNYA}.)
< / p >
2004-04-17 17:30:22 +00:00
< p >
Another fine point: The tool treats {N+DZYA} like {N+DZ+YA}, except
that it warns, "< tt > There is a stack of three or more consonants in
N+DZYA that uses at least one '+' but does not use a '+' between
each consonant.< / tt > ". The tool is inconsistent, however; it
will not treat {R+TS+NYA} like {R+T+S+N+YA} (and that would be a
terrible idea).
< / p >
2003-12-07 00:13:30 +00:00
< p >
So far, we have spoken about consonants and vowels. In fact,
it is not trivial to determine when something is a consonant and
when it is a vowel. {A} can represent U+0F68, the Tibetan
letter, or the implicit vowel. {'} can represent U+0F71, the
subscribed a-chung, or U+0F60, the full-sized consonant
a-chung. The converter treats {TAA} as {T+AA}, not {TA-AA},
but treats {TAAA} like {TA-AA}, not {T+AA-A}. It treats
{PA'AM} like {PA-'A-M}, not {P+A'A-M}. In short, it first
tries out treating {'} and {A} like vowels, but will backtrack if
that leads to a clearly invalid < i > tsheg bar< / i > .
< / p >
< p >
Finally, a string of numbers can be a < i > tsheg bar< / i > also.
It is illegal for numbers and consonants to appear together within
one < i > tsheg bar< / i > , however.
< / p >
< p >
The above is the complete understanding of the converter's
algorithms for parsing < i > tsheg bar< / i > s. You the native
Tibetan speaker may know that {BSKYABS-'UR-'UNG-'O} is not allowed
and thus think that {B+S+K+YAB+S-'UR-'UNG-'O} should be the result,
but the converter has no such knowledge, and thinks this is a native
tsheg bar equivalent to {B-S+K+YAB-S-'UR-'UNG-'O}.
< / p >
< a name = "sysprops" > < / a > < h2 > System Properties< / h2 >
< p >
The < a href = "#sub" > < i > tsheg-bar< / i > substitution< / a > mechanism is
customizable via system properties. Java developers likely
know what these are, but few users do. This section will
perhaps get a determined person started, but if you have trouble,
contact < a href = "mailto:thdltools-devel@lists.sourceforge.net" > the
developers< / a > so that we can improve this documentation or create a
better user interface.
< / p >
< p >
For the tool to respect the value of a system property, you must
invoke the tool from the command line as follows:
< / p >
< p >
< tt >
java
"-Dorg.thdl.tib.text.ttt.ReplacementMap=KAsh=> K+sh,ONYA=> [#ERROR-ONYA-IS-O& ]"
-Dorg.thdl.tib.text.ttt.VerboseReplacementMap=true
-jar Jskad.jar
< / tt >
< / p >
< a name = "bugs" > < / a > < h2 > Known Bugs< / h2 >
< p >
This section presents areas where the current tool's behavior is
wrong. Before doing serious work with the converter,
familiarize yourself with this section and develop a plan to work
around the bugs or to ensure that your documents will not trigger
the bugs. At the same time, if any of these bugs affects you,
contact < a href = "mailto:thdltools-devel@lists.sourceforge.net" > the
developers< / a > so that we can fix them. The squeaky wheel
surely gets the grease; these bugs may never be fixed if there are
no complaints.
< / p >
< p >
The following are all known bugs:
< / p >
< ul >
< li >
When ACIP {MTHARo} is given, the {o} glyph should be centered
under the THA glyph in ACIP-> TMW conversions. At present,
the {o} glyph appears underneath the rightmost stack.
Similarly, {\u0F35} and {\u0F37} are not centered properly.
[< a
href="http://sourceforge.net/tracker/index.php?func=detail& aid=838594& group_id=61934& atid=502515">838594< / a > ]
< / li >
< li >
ACIP-> TMW conversion for {\u0F3E} is not correct. Fear
not; the character U+0F3E is so rare that no ACIP transliteration
exists for it. [< a
href="http://sourceforge.net/tracker/index.php?func=detail& aid=855478& group_id=61934& atid=502515">855478< / a > ]
< / li >
< li >
In a command-line ACIP-> Unicode text file conversion, no
warning or error is given when the input is {KA (KHA)}. (The
output is a text file and does not have a mechanism for indicating
2004-03-14 23:29:47 +00:00
a change in font size, so the output has lost data. Thus,
such input would, in a perfect world, cause two errors bracketing
the small text along the lines of 'ERROR: the text should become
smaller [bigger] here'.) [< a
2003-12-07 00:13:30 +00:00
href="http://sourceforge.net/tracker/index.php?func=detail& aid=855519& group_id=61934& atid=502515">855519< / a > ]
< / li >
2003-12-10 06:57:12 +00:00
< li >
2003-12-15 08:15:39 +00:00
A folio marker {@0B1} can appear in ACIP Release V texts; it gives an error at present.
2003-12-10 06:57:12 +00:00
< / li >
< li >
The treatment of the very last line in an input text may be buggy
with regard to treatment of ACIP spaces, etc.<!-- DLC -->
< / li >
< li >
The treatment of {:} directly before a line break is likely
incorrect; a < i > tsheg< / i > is inserted right now after the
visarga.<!-- DLC FIXME -->
< / li >
2004-04-10 20:44:18 +00:00
< li >
<!-- DLC FIXME: --> The number of errors after which processing is
aborted (under the assumption that the input is probably not ACIP)
is absolute, not a per capita measurement (i.e., one error per 100
characters of input) and is not easily configured.
< / li >
2003-12-07 00:13:30 +00:00
< / ul >
< a name = "room" > < / a > < h2 > Room for Improvement< / h2 >
< p >
This section presents areas where the current tool could be
improved. None of the current behavior described here is
incontrovertibly flawed (i.e., there are no bugs described here, see
< a href = "#bugs" > known bugs< / a > for that); current behavior is
technically correct. However, the current behavior is not, in
everyone's eyes, perfect.
< / p >
< p >
The following are the current areas in which the tool could be
better:
< / p >
< ul >
2004-04-17 17:03:20 +00:00
< li >
At present, an error in ACIP-> TMW conversion is given when ACIP
like {RTSNY} or {NNY} is seen; this is because no glyph R+TS+NY or
N+NY is in the TMW font. For these snippets, though, there
is a significant possibility that R+T+S+N+Y or N+N+Y was intended
because TMW does have glyphs for both. It would be best to
give an error or stern warning when creating the Unicode for RTSNY
etc., and to give an error that is more specific when creating TMW
for RTSNY etc. See issue < a
href="http://sourceforge.net/tracker/index.php?func=detail& aid=936998& group_id=61934& atid=502518">936998< / a > .
< / li >
2004-04-11 15:26:54 +00:00
< li >
It would be best to produce a warning (but not an error) when
converting R+W, Y+Y, n+d+R+Y, K+sh+R, n+d+Y, R+Y, R+SH, R+SH+Y,
R+sh, R+sh+n, R+sh+n+Y, R+sh+M, R+sh+Y, or R+S to Tibetan.
The ACIP scheme does not really say when the unusual, full-formed
consonant is intended. See issue < a
href="http://sourceforge.net/tracker/index.php?func=detail& aid=933240& group_id=61934& atid=502518">933240< / a > .
< / li >
2004-04-10 20:44:18 +00:00
< li >
Some warnings are false alarms (false positives). The only
known false positive is the warning < tt > [#WARNING CONVERTING ACIP
DOCUMENT: There is a chance that the ACIP KshA was intended to
represent more consonants than we parsed it as representing --
NNYA, e.g., means N+NYA, but you can imagine seeing N+N+YA and
typing NNYA for it too.]< / tt > when it is given for ACIP
constructions that cannot possibly be interpreted any other
way. See issue < a
href="http://sourceforge.net/tracker/index.php?func=detail& aid=932896& group_id=61934& atid=502515">932896< / a > .
< / li >
< li >
The only time Unicode output will contain U+0F6A, full-formed RA,
instead of U+0F62, RA (possibly superscribed), is when a Unicode
escape sequence for U+0F6A is used or when one of the ten stacks
RY, RW, RSH, RSHY, Rsh, Rshn, RshnY, RshM, RshY, or RS
appears. The Unicode standard is not as clear as it could be
on the issue of when to use full-formed code points like U+0F6A,
so this treatment might not be the best.
< / li >
2003-12-07 00:13:30 +00:00
< li >
The glyph TibetanMachineWeb9.61 -- the {O'I} special combination
(i.e., the glyph for the Unicode string U+0F7C,U+0F60,U+0F72) --
is never output by the ACIP-> TMW converter. It is
sometimes more beautiful than the glyphs that are presently output
(three separate glyphs instead of the one).
< / li >
< li >
Though the ACIP standard disallows it, you will find in ACIP
documents from the Buddhist Canon things like {/NYA\} where the
standard demands {/NYA/}. Presently, this triggers an error;
it would be better if this were converted like {/NYA/} is, and
triggered only a < tt > Most< / tt > -level warning.
< / li >
< li >
The hypothetical comment {[# \u0F40 may have been intended...]}
should cause a warning saying that Unicode escapes do not apply
within comments.
< / li >
< li >
The whitespace after a < a href = "#escapes" > Unicode escape< / a > is
not interpreted correctly when that Unicode escape represents
something that is part of a < i > tsheg bar< / i > . For example,
the space in {KA KHA} is treated as a < i > tsheg< / i > (i.e., U+0F0B),
but the space in {\u0F40 KHA} is wrongly treated as Tibetan
whitespace. [< a
href="http://sourceforge.net/tracker/index.php?func=detail& aid=855482& group_id=61934& atid=502515">855482< / a > ]
< / li >
< li >
Though not standard, {:} and {:-} sometimes are intended to
represent U+0F14. The latter causes an error; it should
cause a warning suggested that the < a href = "#escapes" > Unicode
escape< / a > {\u0F14} be used instead. The former is always
treated as U+0F7F; it should cause a warning in some or all
contexts.
< / li >
< li >
The < a href = "#sub" > < i > tsheg-bar< / i > substitution< / a > mechanism
should be more general. The useful rule
2003-12-10 06:58:08 +00:00
< tt > ONYA=> O& < / tt > should be supported and used by default.
2003-12-07 00:13:30 +00:00
< / li >
< li >
The converters should support a white list of acceptable
non-native < i > tsheg bar< / i > s (where the term " tsheg bar"
is to be interpreted somewhat literally here as any characters
between punctuation). Non-native < i > tsheg bar< / i > s not on
the list should produce warnings or errors. Similarly, but
perhaps less urgently, a syllabary of native < i > tsheg bar< / i > s
should be supported too. (A workaround is to use < a
href="#colors">coloring< / a > , have your word processor delete
everything but the colored text, sort the colored < i > tsheg
bar< / i > s, and inspect them all by hand. Also, < a
href="#stats">< i > tsheg-bar< / i > statistics< / a > will help you to
find uncommon < i > tsheg bar< / i > s.)
< / li >
< li >
ACIP-> Unicode conversions produce Unicode text files at
present. While more compact than Rich Text Format (RTF)
files, a text file does not allow for supporting the two font
sizes in {KA (KA)}. A workaround is to use an ACIP-> TMW
conversion followed by a separate < a
href="TMW_or_TM_To_X_Converters.html">TMW-> Unicode< / a >
conversion.
< / li >
< li >
The converter should warn for each occurrence of the vowels {'E},
{'O}, {'EE}, or {'OO}.
< / li >
2003-12-10 06:57:12 +00:00
< li >
Default < a href = "#sub" > substitution< / a > rules should handle
2003-12-15 08:15:39 +00:00
{KAsh}, which seems to always mean {K+sh} in ACIP Release V texts.
2003-12-10 06:57:12 +00:00
< / li >
2003-12-07 00:13:30 +00:00
< / ul >
< h2 > License< / h2 >
< p > Both the ACIP-> Tibetan converters and this document are released
under the < a
href="http://iris.lib.virginia.edu/tibet/tools/thdl_license.txt">THDL
Open Community License Version 1.0< / a > .< / p >
< p >
Please
< a href = "mailto:thdltools-devel@lists.sourceforge.net" >
e-mail us< / a >
your comments about this page.
< / p >
< p >
The
< a href = "http://www.sourceforge.net/projects/thdltools" >
THDL Tools< / a >
project is generously hosted by:
<!--
DO NOT DELETE THE SF.NET LOGO.
We have a choice of colors and sizes for this logo (see
"https://sourceforge.net/docman/display_doc.php?docid=790& group_id=1"),
but we do not have the option of removing it. SourceForge requests
that we put it on each web page for our project, and to give us
incentive to do so, they will not track the number of hits for our
project web pages unless we put this link in. To track hits, see
"http://sourceforge.net/project/stats/index.php?report=months& group_id=61934".
-->
< a href = "http://sourceforge.net/" >
< img src = "http://sourceforge.net/sflogo.php?group_id=61934&type=1"
width="88" height="31" alt="SourceForge Logo" />
< / a >
<!-- AGAIN, DO NOT DELETE THE SF.NET LOGO. -->
< / p >
< / div >
< / body >
< / html >
