diff options
Diffstat (limited to 'Master/texmf-dist/doc/fonts/itrans/tech.tex')
-rw-r--r-- | Master/texmf-dist/doc/fonts/itrans/tech.tex | 539 |
1 files changed, 539 insertions, 0 deletions
diff --git a/Master/texmf-dist/doc/fonts/itrans/tech.tex b/Master/texmf-dist/doc/fonts/itrans/tech.tex new file mode 100644 index 00000000000..3633921314b --- /dev/null +++ b/Master/texmf-dist/doc/fonts/itrans/tech.tex @@ -0,0 +1,539 @@ +% $Header: /home/cvsroot/itrans/nextrel/doc/tech.tex,v 1.1.1.1 1996/11/29 01:45:31 avinash Exp $ +\renewcommand{\arraystretch}{1.25} +\newcommand{\rarrow}{\mbox{---\hspace{-8pt}$>$}} +\newcommand{\SM}{\verb+\char92marathi+} +\newcommand{\EM}{\verb+\char92endmarathi+} +\documentstyle[11pt]{article} +\setlength{\textwidth}{5.75in} +\newfont{\devnf}{dnh at 15pt} + +\begin{document} + +\centerline{\LARGE\bf The {\em itrans} Preprocessor} +\medskip +\centerline{\bf TECHNICAL INFORMATION} +\medskip +\centerline{\bf \copyright 1991 Avinash Chopde} +\medskip +\hrule +\bigskip + +\section{Reference} + +{\tt +WARNING: The information in this document relates to ITRANS 2.11 and +earlier only. +THIS INFORMATION MAY BE INCORRECT/INCOMPLETE AS OF ITRANS 3.00 versions +onwards. +} + +This is a project that aims to develop a single tool for handling the +printing of various indian language documents, assuming that the input is +in some transliterated form. +The transliteration mechanism for all indian languages will be through +the english language. + +See the document {\em Printing Transliterated Indian Language Documents}, +in the file {\em idoc.itx} for more details---that document is the +user manual for the {\em itrans} package. +This document discusses the technical aspects of the program. + +\section{Input Parsing} + +I have made the following assumptions regarding how the words in a +indian language (well, not all, but most of them) are assembled. +(In the following discussion, {\em alphabet} refers to the list of basic +characters in the language script, a +{\em letter} refers to an element from the complete list of characters---basic +plus all the composite forms.) + +The alphabet is divided into two groups: vowels and consonants. + +Each indian language letter may be a vowel, or a consonant-vowel pair, or a +ligature-vowel pair. + +Ligatures are sequences of consonants. + +If a consonant {\em xxx} is followed by another consonant {\em yyy}, then it is +assumed to imply a half-consonant, i.e., the half-form of {\em xxx} must be +displayed at that point. +Of course, if the ligature for the pair xxx-yyy exists, the ligature +is used instead. +Note that not all indian languages make use of ligatures. + +Apart from the vowels and consonants, some special forms are also +provided, such as the chandra-bindu, the anuswara, virama, etc. +These special forms always form the suffix on the letter they affect, +i.e., you specify the letter first, then the special form. +A bunch of letters separated by white space or punctuation forms a word. + +Based on these assumptions, a simple parser has been built, to recognize +the basic unit---the letter. + +\section{Letter Construction} + +The fonts that are used here provide only the basic characters---vowels, +consonants (both full and half forms), special forms, and, some ligatures. +Every letter is built by printing its constituent characters. +This mapping of the consonant-vowel pairs, of the ligatures, etc, to +actual characters to be used from the specific font is specified through +the IFM file (indian language font metric file). +The IFM file is a text file, and follows somewhat the syntax of Adobe AFM +files. +In it is described how to construct every consonant-vowel form using the +given font, how to construct a ligature of consonant-consonant pairs, +the character codes of the special forms, etc. +The description is provided as a list of character codes, and their +offsets. +For example a description for some letter looks like: + +PCC 97 0 0 ; PCC 129 -70 0 ; + +This is a two character chain, first character has code 97, second +character has a code of 129. +The first character is printed with an offset (x,y) of (0,0). +Then the second character is printed with an offset of (-70,0), i.e., a +kern of -70 units. +One unit is equivalent of $1/1000$ of the current font size. +The entire IFM file structure is described in a later section. + +As shown in the example above, the chain of characters is printed out by +performing two operations on every character code in the chain: + +\begin{verbatim} +for every component of the form: PCC <code> <dx> <dy> ; + +move <dx>, <dy>; + +display character <code>; + +/*POSTSCRIPT FONT ONLY*/ + if (<dy> is non-zero) move 0, -<dy>; + if (width of char <code> is defined as zero) move -<dx>, 0; +/*POSTSCRIPT FONT ONLY*/ + +\end{verbatim} + +This relies on the fact that both \TeX\ and PostScript have a notion of a +current point. +Two values allow kerning to be specified in both X and Y directions. +If a movement in Y direction is des +Note that if the font being used is a PostScript font, then two other +actions may be performed. +If \verb+ <dy>+ is non-zero, itrans reapplies a negative offset to +restore the baseline y coordinate (otherwise the line will keep getting +skewed! Note that this step is not necessary for \TeX---it takes care +of keeping the baseline horizontal). +Secondly, if the width of the character has been defined to be zero, a +negative x kern is applied. +This is done just for convenience---zero width characters are always +used as accent marks, and they should not contribute to the actual +character width, so the current position in X is restored to the original +value after a accent mark (zero width character) is printed. + +Only PostScript fonts may have zero-width characters, the above does not +apply to \TeX\ Matafont fonts. +I.e, for \TeX, the last {\em move -<dx>, 0;} is never executed, even if +the charwidth for the given character is zero. +(This is partly due to my laziness, I did not want to write code that +reads in a TFM file to get the char widths!) + +The above given description is used to specify both consonant-vowel +forms, and consonant-consonant (ligature) forms. +Currently, only ligatures composed of two consonants can be defined. + +If a consonant-vowel form appears in the input text, but has not been +defined in the IFM file, an error message is printed on the screen, and +the character is omitted. + +If a consonant-consonant-vowel (ligature) form appears in the input text, +but has not been +defined in the IFM file, it is not considered an error, instead, the +first consonant is printed in the half-form, and the second consonant +is printed out as its appropriate vowel form. +Long consonant chains, such as consonant-consonant-$\cdots$-consonant-vowel +are also handled in a similar manner---first a check if made if a ligature +exists for any two consecutive consonants, if yes, it is used, else, the +half forms of the consonants are used. +Beginning with the first consonant in the list, +itrans checks if a double-consonant ligature has +been defined for that consonant and the next one in the list. +If such a character exists, then it is used and both consonants are consumed, +and itrans repeats the procedure for the next consonant. + +There is an exception to the above rule: if at all possible, the last two +consonants are handled together, that is if a ligature of the last two +consonants +exists, that is used over the pairing that would result from the above method. +(See the user manual idoc.itx for example in the section Usage Hints.) + +\section{IFM File Code Names} + +The IFM file uses code names to refer to vowels and consonants. +For example, the ``I'' char in the input text for devanagari refers +to the ``ii'' code name in the IFM file (in this case, so does the input +char pair ``ii''). +Figure 1 shows the relationship between the input vowel text forms +accepted by the +lexer, and the code name for the vowels in the IFM file. +(Note that no indian language script makes use of the complete set +of code names available in the IFM file.) + +(Figures 1 \& 2 may be out-of-date, see the files imap.h and ilex.l +for correct info.) + +Similarly, the consonant names are as given in figure 2. +Again, only a subset of these may be used by a particular indian +language script. + +\bigskip +\begin{figure} +\begin{center} +\begin{tabular}{|c|c|c|} +\hline +{\em Input Text} & {\em IFM Code Name} & {\em Used For} \\ +\hline\hline +a & a & devanagari, tamil \\ \hline +aa & aa & devanagari, tamil \\ \hline +i & i & devanagari, tamil \\ \hline +ii or I & ii & devanagari, tamil \\ \hline +u & u & devanagari, tamil \\ \hline +uu or U & uu & devanagari, tamil \\ \hline +Ri & ri & devanagari \\ \hline +RI & rii & devanagari \\ \hline +Li & li & devanagari \\ \hline +LI & lii & devanagari \\ \hline +e & ay & devanagari, tamil \\ \hline +E & aay & tamil \\ \hline +ai & ai & devanagari, tamil \\ \hline +o & o & devanagari, tamil \\ \hline +O & oo & tamil \\ \hline +au & au & devanagari, tamil \\ \hline +aM & am & devanagari\\ \hline +H & aha & devanagari\\ \hline +\end{tabular} +\end{center} +\caption {Vowel Input Forms and Code Names} +\end{figure} + +\begin{figure} +\begin{center} +\begin{tabular}{|c|c|} +\hline +{\em Input Text} & {\em IFM Code Name}\\ \hline \hline +k & ka \\ \hline +q & kadot \\ \hline +kh & kha \\ \hline +K & khadot \\ \hline +g & ga \\ \hline +G & gadot \\ \hline +gh & gha \\ \hline +ng & nga \\ \hline +c & cha \\ \hline +ch & chha \\ \hline +j & ja \\ \hline +z & jadot \\ \hline +jh & jha \\ \hline +jn & jnh \\ \hline +T & tta \\ \hline +Th & ttha \\ \hline +D & dda \\ \hline +.D & ddadot \\ \hline +Dh & ddha \\ \hline +.Dh & ddhadot \\ \hline +N & nna \\ \hline +t & ta \\ \hline +th & tha \\ \hline +d & da \\ \hline +dh & dha \\ \hline +n & na \\ \hline +p & pa \\ \hline +\end{tabular} +\hfill +\begin{tabular}{|c|c|} +\hline +{\em Input Text} & {\em IFM Code Name}\\ \hline \hline +ph & pha \\ \hline +f & phadot \\ \hline +b & ba \\ \hline +bh & bha \\ \hline +m & ma \\ \hline +y & ya \\ \hline +r & ra \\ \hline +l & la \\ \hline +v & va \\ \hline +sh & sha \\ \hline +shh & shha \\ \hline +s & sa \\ \hline +h & ha \\ \hline +ld & lda \\ \hline +x & ksha \\ \hline +gy & gya \\ \hline +ny & nya \\ \hline +n\^ & nnx \\ \hline +R & rra \\ \hline +.r & rahalf \\ \hline +.n & anusvara \\ \hline +.c & chandra \\ \hline +.C & chandrabindu \\ \hline +.h & viraam \\ \hline +SRI & sri \\ \hline +AUM & aum \\ \hline +\end{tabular} +\\ +\end{center} +\caption {Consonant Input Forms and Code Names} +\end{figure} + +\section{IFM File Data} + +Currently, the IFM data resides in a file of its own, file name ends in +{\em .ifm}, example {\em dvnc.ifm}. +I still hope +that I may some day be able to include the IFM data into the Adobe AFM file. +Hence, all the lines in the IFM file start off with the word {\em +Comment\/}, so that regular Adobe programs that scan the AFM file may +skip over this data. +The marker {\em -I-} follows the comment word, and this marks the line as +containing legal metric data for the indian language. + +Every line in the AFM file consists of semicolon separated fields. +Each line describes a composite alphabet form, such as a consonant-vowel +description or a consonant-consonant form, or a vowel form, or a half +form of a consonant, etc. +The english words used to specify the characters of the indian language +alphabet are meant to sound right, in some vague manner, and are usually +self-descriptive. +These english words (such as ii, aa, aha, etc) have no relation to what +the user types to get the required character, that mapping is defined by +the lexer input file, {\em ilex.l}. + +Every field in a line in the IFM file starts off with an opcode, +describing what to expect next. + +The following lines are representative of the data in the AFM file: + +\begin{verbatim} +Comment -I- StartINDIAN +Comment -I- FONT marathi dmta.afm +Comment -I- CC a 2 ; PCC 97 0 0 ; PCC 129 -70 0 ; +Comment -I- CC a 2 ; PCC 97 0 0 ; PCC 129 -70 0 ; +Comment -I- CC gha-ii 3 ; PCC implicit 0 0 ; PCC 129 -70 0 ; PCC 132 0 0 ; +Comment -I- CCS gha ga ; +Comment -I- CCADD tmplA ; +Comment -I- EndINDIAN +\end{verbatim} + + +The opcodes StartINDIAN and EndIndian are used to bracket the indian +language character description data. + +The FONT opcode gives the name of the language, and the name of the file +which contains the AFM data for this font. +If the font is a Metafont description, then the TFM file name is +specified here. +The TFM file name is just used as an indication that the font used is a +\TeX\ font, the file is not actually opened or read. +Thus, if the font used is a Metafont description, you could as well say +``junk.tfm'' in the FONT opcode---only the extension ``.tfm'' is +important. +The first word in the FONT line is the language, and it must be one of the +languages ITRANS recognizes (see the function get\_lang\_tok() in marker.c). +This word determines how the input is scanned for tokens. +For example, the input letters ``Ri''refer to a vowel in +sanskrit/marathi/hindi, but in tamil, that vowel is not present. +But tamil uses the ``R'' symbol for a consonant, so the input ``Ri'' +is scanned as the consonant ``R'' followed by the vowel ``i'', while in +sanksrit it is scanned as the vowel ``Ri''. +Thus, it is important to define the correct language in the FONT statement +in the IFM file. + +The CC words stands for composite character, and it defines how to +construct the given character using the font. +In the example above, it shows that the {\em a} character is made up of +two units: char code 97, and char code 129. +See the previous section regarding the PCC opcode. +The second CC line above describes how to create the {\em ii} vowel form +of the consonant {\em gha}. +The first PCC character code in the line is not a number, but states {\em +implicit}. +This requires that a special character, called {\em gha-implicit} be +defined earlier. +Semantically, gha-implicit means the implicit form of the consonant gha. +Thus, whenever the code implicit appears in the description of some +consonant xxx, at that point, the program inserts the definition of the +xxx-implicit letter. +(Naturally, the description of xxx-implicit cannot have the code implicit +in its description.) + +Most consonants are similar in the manner in which the vowel forms are +constructed, using the implicit form of the consonant, and a few other +character forms. +For example, kha-aa, gha-aa, da-aa, dda-aa, are all constructed by using +this description: +PCC implicit 0 0 ; PCC 130 -70 0 ; +So, instead of restating this description for all these consonants, the +CCS keyword can be used instead. +The CCS keyword assigns equivalences, + +CCS xxx yyy ; + +states that a given consonant +xxx is similar to a already defined consonant yyy, and if some vowel +form (x) is missing, i.e. xxx-x description is missing, then it looks up +the description for yyy-x, and uses that. +This chaining can be made as deep as necessary: + +CCS bbb aaa ; + +CCS ccc bbb ; + +CCC ddd ccc ; + +etc + +CCS also works similarly for ligature forms: + +CCS ga-ra tmplC ; + +which states that the ga-ra ligature should use the form of the tmplC +dummy consonant (dummy consonants are explained further in this section). +Note that it is usually dangerous to specify ligature equivalence to one +of the constituent consonants, since most of the consonants do not use the +codename "implicit" in all their form definitions. +Thus, be careful of such definitions: + +CCS ga-ra ga ; + +or + +CCS ga-ra ra ; + +This will create problems if the half form of the ga-ra ligature is +required since both ga and ra (and every other consonant too) +have a half-form definition that does not include the code "implicit", +hence instead of the ga-ra-half form, what will print out will +be just the ga-half form or the ra-half form, depending on which +CCS line (from the above two lines) is present in the IFM file. +One way around this problem is to specifically define the half-form of +the ga-ra ligature, so as to stop the program from looking for it +through the CCS chain. +It is usually only the half form that causes problems (as of october 1991), +since all the other forms do contain the "implicit" code in their +definitions. + +A special consonant form, ``*'' is available for use with the CCS +keyword for ligatures: +It acts as a meta-character implying all the consonants. + +CCS *-ra tmplC ; + +CCS ga-* tmplC ; + +Instead of providing consonant equivalences between consonants, +additional dummy consonants may be created, these exist only in the IFM +file, and used only for equivalencing a real consonant. +The CCADD line defines the creation of a placeholder consonant. + +CCADD tmplA ; + +This states that the IFM will make use of a dummy consonant called tmplA, +and then all its vowel forms (including the half form) can be defined. +See the file dvnc.ifm for complete example. +All that tmplA is used for is to define equivalences, again from the +dvnc.ifm file, you will see lines like: + +CCS chha tmplA ; + +CCS tta tmplA ; + +which state that if some required vowel form of chha or tta is missing, +then try to use the definition of the same vowel form in tmplA. + +Each IFM file can make up to 10 such dummy consonants. + +\section{Example Usage or When to Make New IFM Files} + +So, to what end can this knowledge of the IFM file format be applied ? + +\begin{enumerate} +\item Assume that you need to disable all ligature printing, you +are printing at a very small font size, and ligatures do not print out +legibly. +To do this, you should copy the dvnc.ifm file to sdvnc.ifm, and remove all +ligature definitions from sdvnc.ifm. +Ligature definitions are those which contain two consonants separated by +a dash: examples: +{\obeylines +CCS tta-tta tmplA ; +CC tta-tta-implicit 1 ; PCC 147 0 0 ; +} +All such ligature definitions can be deleted from sdvnc.ifm. +And then, in your input file that contains the transliterated text, add +the command: + +$\backslash$indianifm=sdvnc.ifm + +(See the user manual on itrans for more information on the indianifm +keyword.) + +Now, no ligatures are available, and nothing needs to be done to the +input text at all to suppress the ligatures. +Instead of the ligatures, the half-forms of the consonants will be used +wherever required. + +\item Another use would be if you do not like the spacing of certain +characters when they are composed to form consonant forms. +Well, as seen in the previous example, it is quite simple to copy the IFM +file into a new one, change the deltas (the numbers) as required, and use +the new IFM in the input text. + +\item By changing the character definitions in the IFM file, one can +produce different printed forms for the character. +For example, to print the normal form of {\em ii} in devanagari prints out +as: {\devnf \char105\kern-0.04em\char128}. +% itrans: CC ii 2 ; PCC 105 0 0 ; PCC 128 -40 0 ; +Now, what if you need to make it print out as: {\devnf \char97\char132} ? +This is easily done, just comment out the old definition of the {\em ii} +character (it is called {\em ii} in the ifm file), and make it read: + +{\obeylines +Comment -I- CC ii 2 ; PCC 97 0 0 ; PCC 132 0 0 ; +} + +Now, all instances of {\em ii} in the input text will print out as: +{\devnf \char97\char132 }. + +\renewcommand{\arraystretch}{1.25} +\renewcommand{\arraystretch}{1.25} +\renewcommand{\arraystretch}{1.25} +\renewcommand{\arraystretch}{1.25} +This method can be used to change any character form you need, as long as +the constituent parts of the new character are available in the font. + +\item You have received a new font, either you developed it yourself, or +\renewcommand{\arraystretch}{1.25} +got it elsewhere, and you would like to use it through the itrans +mechanism. +This involves two steps. +First, you need to map the vowels and consonants available through itrans +(see figures 1 and 2) to the font characters. +Second, you create a IFM file for the font. +The first step is the biggest hurdle, especially if you feel that you +need to add new consonant names to ilex.l. +(Of course, that implies lots of source code changes: now iyacc.y will +have to be modified to accept the new token, imap.h will have to edited +to add the codename for the font, and font.c will have to be edited to +add the new codename into a static data structure!) +If that happens, send me e-mail, maybe I will permanently add the name to +ilex.l, but I hope that current set of names accepted by ilex.l will +suffice. +If they do, then no source code changes are necessary, just need to +create the IFM file and you are in business. + +If you wish, you could send me the IFM file you create, and the font +(if it is in public domain, otherwise the IFM file only will suffice), + +\end{enumerate} + +\end{document} |