khm
(The initial translation table for a translation is determined by the selected template, and may be changed using the Document / Translation Tables menu. Using those menus does not involve explicit use of the table designator. However, in cases where it is necessary to switch to a different translation table partway through a file, the designator for the table being switched to is required; see the general description of the [lnb~...] command for further details.)
The Khmer (Cambodian) tables support print-to-braille translation of Khmer-language literary text entered in Khmer script, following codes and customs as practiced at the Cambodian foundation Krousar Thmey. Latin script may also be present in the input file, and if so it is transcribed in uncontracted braille according to English/American conventions as defined by the Braille Authority of North America (BANA). Technical codes for math and science (Nemeth Code) and computer notation (Computer Braille Code) are also supported, again following BANA conventions.
Normally, the text is first prepared on Microsoft Word using a Unicode font such as KhmerOS, and imported to DBT prior to translation. For word breaking at ends of lines to be carried out properly in braille (and also for best use of the word-processing capabilities of Word), it is important that word boundaries within unspaced Khmer letter sequences be entered as "zero width spaces". The KhmerOS typing facilities make this character easy to enter, and Word display options also provide a way for it to be "visible" when that is desirable.
True braille-to-print translation is supported within English text and Computer Braille Code, but not in languages other than English nor in mathematics. This means that any mathematics, Khmer or other non-English portions of a braille file will not translate correctly to print. It also means that the "translated line" will typically contain gibberish when the cursor is in mathematics or Khmer, or in any language other than English. For this reason you may prefer to turn the translated line off when working with Khmer literary braille -- under the View menu, or even under Global/Default if you wish it to be off by default.
Khmer characters may not be shown normally on the "print file" view of DBT. This is the main reason that Microsoft Word should normally be used for entering, editing and viewing the print text and the DBT print view is used only as an intermediary step enroute to the braille.
English grade 1 (uncontracted) is supported, as noted above. Language switching codes, i.e. [lng~en] to introduce an English passage and [lng] or [lng~km] to revert to Khmer, may be used but are actually not necessary, as the distinction between languages is made on the basis of the script.
Note that in addition to the abovementioned "secondary language" support within the Khmer table itself, it is also possible to switch to any of the available translation tables listed in DBT. (See the [lnb~...] code below.)
The BANA math and science code, i.e. Nemeth Code, and the BANA computer notation code, i.e. CBC, are supported. See the relevant documentation under "Help".
In addition, it is possible to switch to any of the available translation tables listed in DBT (see the [lnb~...]code below), many of which do support various technical codes, such as for mathematics or computer notation, or which support “unified” treatment of technical notation as well as literary text in the base language associated with the table.
The following DBT translation codes are available when using the Khmer table. Any other translation codes used will be ignored, or indeed may cause unexpected results. If using an alternative translation table, i.e when switching to another base language table by means of the[lnb~...] code, please refer to the relevant topic and available codes for that table.
[/]
[ab] is equivalent to [g2] and has no effect in this table.
[atx0] turns off the "all ASCII is literal" mode (see next code description), so that certain traditional "codes" typed in as direct text will continue to have effect. (For a list of these, see "Special Print Text Codes" within the "Codes Quick Reference" on DBT's Help menu.) This is presently the default (initial) condition, but as that is likely to change in future versions, it is advisable to put an [atx0] code at the beginning of any file in which the traditional in-text codes are used.
[atx1] turns on an "all ASCII is literal" mode, which will cause all ordinary printable ASCII characters to be considered as literal text, even those sequences that have traditionally been used as special "codes".
[bar]
[be]
[bline]
[bs0] is a special variant form of the [bs] code that forces omission of the subscript indicator (dots 5-6).
[bs1] is a special variant form of the [bs] code that forces use of the subscript indicator (dots 5-6).
[bs]
[cap-invert]
[cap-normal]
[cb-&]
[cb-de]
[cb-ds]
[cb-ee]
[cb-es]
[cb-ne]
[cb-ns]
[cb-se]
[cb-ss]
[cb-t1]
[cb-t2]
[cb-ue]
[cb-us]
[cb]
[cbi]
[cbn]
[cs-off]
[cs]
[cz]
[e]
[ecane]
[ecans]
[enclis]
[eqvn]
[evb]
[fe0] is a special variant form of the [fe] code for ending the fractional portion of a mixed number.
[fe1] is a special variant form of the [fe] code for ending a fraction that includes another fraction (one level only) (i.e. a complex fraction).
[fe2] is a special variant form of the [fe] code for ending a fraction that includes two levels of other fractions (i.e. a hypercomplex fraction).
[fe]
[fl-lifg]
[fl-none]
[fl-span]
[fl1] is a special variant form of the [fl] code for entering the fraction line for a fraction that includes another fraction (one level only) (i.e. a complex fraction).
[fl2] is a special variant form of the [fl] code for entering the fraction line for a fraction that includes two levels of other fractions (i.e. a hypercomplex fraction).
[fl]
[fs0] is a special variant form of the [fs] code for starting the fractional portion of a mixed number.
[fs1] is a special variant form of the [fs] code for starting a fraction that includes another fraction (one level only) (i.e. a complex fraction).
[fs2] is a special variant form of the [fs] code for starting a fraction that includes two levels of other fractions (i.e. a hypercomplex fraction).
[fs]
[fte~b]
[fte~i]
[fte~u]
[fts~b]
[fts~i]
[fts~u]
[g1]
[g2]
[i]
[ii]
[in] is equivalent to [g1]
[ixrtd]
[ixrte1] is a special variant form of [ixrte], for ending an indexed radical that is enclosed within a single outer radical.
[ixrte2] is a special variant form of [ixrte], for ending an indexed radical that is enclosed within two outer radicals.
[ixrte]
[ixrts1] is a special variant form of [ixrts], for starting an indexed radical that is enclosed within a single outer radical.
[ixrts2] is a special variant form of [ixrts], for starting an indexed radical that is enclosed within two outer radicals.
[ixrts]
[lnb]
[lnb~...] (for switching to another base [primary] language table)
[lng]
[lng~...] (see "Secondary Languages Supported," above)
[oe]
[one]
[ons]
[os]
[pe]
[ps]
[rmn]
[sqrte1] is a special variant form of [sqrte], for ending a square root that is enclosed within an outer radical.
[sqrte2] is a special variant form of [sqrte], for ending a square root that is enclosed within two outer radicals.
[sqrte]
[sqrts1] is a special variant form of [sqrts], for starting a square root that is enclosed within an outer radical.
[sqrts2] is a special variant form of [sqrts], for starting a square root that is enclosed within two outer radicals.
[sqrts]
[tce] cancels the effect of [tcs], restoring literary treatment (which is the default).
[tcs] is required in this table to enable math (technical) context, i.e. for general treatment as Nemeth Code. See the Topical How-To Guide, under Help, for general instructions.
[te] cancels the effect of [ts], restoring normal text mode (even though "technical context," i.e. Nemeth Code, may remain in effect).
[ts] initiates "technical notation," i.e. "math mode" within Nemeth Code.
[tx]
[txi]
[txn]
[ue]
[us]
[vrn] cancels the effect of [vrn~inf]
[vrn~inf] establishes "informal mode," wherein certain ASCII characters that are not defined in Khmer nor English literary braille, and which according to the strict interpretation of the BANA literary code must therefore be represented as one or more words in braille (e.g. "greater-than" for ">"), are instead given informal but generally familiar representations (e.g. dots 3-4-5 in that case). Note that the definition of this code may be changed or discontinued in future versions.
The table is designed to work with the following groups of characters:
Khmer script characters (from the Unicode U+17xx / DUSCI D+bbxx range)
The "zero width space" (Unicode U+200b, DUSCI D+ec3b), which is important for signalling Khmer word breaks within unspaced letter sequences as noted above
All ASCII printable characters
Accented characters and punctuation marks typical of French, German, Italian, Spanish, and Portuguese
British pound, Japanese yen, Euro, and other miscellaneous signs (DUSCI pages D+ec..., D+ed..., D+ee..., D+f5...)
Mathematical signs, shapes, etc. (in "technical context," i.e. Nemeth Code, only) (DUSCI pages D+df..., D+e2..., D+e5..., D+ef..., D+f0..., D+f1...)
The above is a general guide only (see the "General Notes" section at the beginning of this document).
The Khmer literary code aspects of these tables are based upon information first provided to Duxbury Systems by Wiraman Niyomphol of ON-NET in Thailand, as supplemented by a Khmer braille translator program that he had already developed, and further information provided by Kong Bunthy of Krousar Thmey in Cambodia.
The English literary code aspects are based primarily upon "English Braille American Edition," a publication of the Braille Authority of North America (BANA). "The Nemeth Braille Code for Mathematics and Science Notation, 1972 Revision" and "Code for Computer Braille Notation" (1987) define the mathematics and computer notation codes followed; both are also BANA publications.
The Khmer tables were adapted from the then-current American literary tables starting in August 2006 by Duxbury Systems, Inc., working with the earlier Khmer translator and information noted above and in active partnership with the individuals who provided it, and who also provided help with interpretation and feedback as the work progressed. Duxbury Systems is grateful for their assistance and guidance, and also for that of Larry Campbell of Overbrook School, Philadelphia, who greatly facilitated the coordination with these organizations.
(Documentation reviewed: July 2010.)