[Padma] Problems in ttf to otf convertions

[kinshul at students.iiit.ac.in]

Hi
As you had suggested, we are approaching our problem of ttf to otf
conversion in two steps. First is to generate the reverse mappings
corresponding to the given ttf file, and the next is to modify an existing
otf file(of the same script type, for instance, Devanagari) using the
reverse mappings generated,in order to obtained the required otf file.

We have somewhat figured out how to do the second part using fontforge.
The main problem  is reverse mapping generation. Suppose we start working
on a ttf file amarujala.ttf,(which is a devanagari font). Our task is to
generate reverse mappings for this file. One approach will be to open
Devanagari.js(which is found in the appropriate folder in padma). In this
file we have a function "Devanagari.codepoints()=new Object()", which has
mappings of the sort :

Devanagari.codepoints.candrabindu = "\u0901"
..
..
..

Devanagari.codepoints.letter_SHT_A = "\u0904";
Devanagari.codePoints.letter_A     = "\u0905";
Devanagari.codePoints.letter_AA    = "\u0906";
..
..
..


and so on
These, I understand, are sort of variable declarations(codepoints) and
they are initialised to their unicode values. These variables correspond
to all the glyphs in the in unicode charts, for example
'codePoints.letter_A' corresponds to the devanagari character chota A. In
this way all the unicode characters of Devanagari are mapped to codepoints
in Devanagari.js file. We find mappings for independent vowels,
consonants,dependent vowel signs, digits and some special symbols. We dont
find any mappings for half forms, because they are not found in unicode
charts.

Further, in this file we have a "Devanagari.fromPadma = new Object();"
function. This function has statements of the type

Devanagari.fromPadma[Padma.anusvara]    = Devanagari.codePoints.anusvara;

Devanagari.fromPadma[Padma.chillu]      =
Devanagari.codePoints.misc_VIRAMA + Unicode_Shared.ZWJ;

Devanagari.fromPadma[Padma.syllbreak]   =
Devanagari.codePoints.misc_VIRAMA + Unicode_Shared.ZWNJ;
Devanagari.fromPadma[Padma.udAtta]      = Unicode_Shared.UDATTA;

Devanagari.fromPadma[Padma.vowel_A]     = Devanagari.codePoints.letter_A;
..
..
and so on

These, I understand, are mappings of Devanagari codepoints to variables in
padma class. I didnt much understand the its need (the mappings could have
been directly btw devanagari codepoints and variables representing the
glyphs in the proprietary ttf file for which the conversion is being
done), but i was told in the last meeting that it is required for proper
functioning of padma.

Now , we take a look at the .js file for the ttf file which we want to
convert to otf. Let us take the example of  amarujala.ttf. The .js file
corresponding to it is BEJA.js. So, we open it.
Here we find statements of the type:
BEJA.avagraha       = "\u00F9";
BEJA.anusvara_1     = "\u00A2";
BEJA.anusvara_2     = "\u00B4";
....
...
BEJA.vowel_A        = "\u00A5";
BEJA.vowel_AA       = "\u00A5\u00E6";
....
BEJA.consnt_KA      = "\u00B7";
....
BEJA.halffm_KA      = "\u20AC";
...
BEJA.conjct_KK      = "\u0050";
...
BEJA.vattu_YA       = "\u004B";
...
and so on
These are some sort of variable declarations for glyphs in amarujala.ttf
and they have been assigned their hexadecimal values. They include,
independent vowels, consonants, conjuncts, dependent vowel signs, digits,
special symbols, etc.

Then we have a function "BEJA.toPadma = new Object();", which maps these
padma variables to the corresponding padma variables. It has statements of
the type:
BEJA.toPadma[BEJA.vowel_A]    = Padma.vowel_A;
''
BEJA.toPadma[BEJA.consnt_KA]    = Padma.consnt_KA;
..
BEJA.toPadma[BEJA.halffm_KA]   = Padma.halffm_KA;   **********
..
BEJA.toPadma[BEJA.halffm_CC]   = Padma.halffm_CA + Padma.halffm_CA;
..
BEJA.toPadma[BEJA.conjct_KK]     = Padma.consnt_KA + Padma.vattu_KA; +++++++


Our plan was to write a parser which would use the statements mentioned
just above, to generate reverse mappings. We planned to use the
information Devanagari.js to replace padma variables with their
corresponding  unicode values (using the codepoint-padma mappings in
Devanagari.js) and to use the information in BEJA.js file to replace BEJA
variables with their hexadecimal values. This way we would have the
reverse mappings. But there are many problems. The most prominent one is
with half forms. Since there are no half forms in unicode charts, there
are no codepoints corresponding to them in Devanagari.js and also there is
no mention of padma.halffm_X in the Devanagari.js. It just appears in the
BEJA.js file (see the line above, marked with ******). So, we are in a fix
about half forms. There are a few other doubts(for example the line marked
with +++++ is not clear), but this is the chief one. I guess we are
conceptually wrong, somewhere, or maybe we need to know more.
We thought about the method you suggested, in which could compare web
pages (one in unicode and the other in ttf hexadecimal values), but we are
not clear abt its implimentaion. We need help....
Thanks

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.