Problems in ttf to otf convertions

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       = "u00A5u00E6";
....
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.

_______________________________________________
Padma mailing list
Padmamozdev.org
http://mozde
v.org/mailman/listinfo/padma

Hi,

I presume this is primarily meant for Sunil, but I will
address a
couple of questions.

On 5/24/07, kinshulstudents.iiit.ac.in <kinshulstudents.iiit.ac.in> wrote:
> 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.

You are right that the mapping can be done directly but the
main
reason for going through an intermediate stage is to enable
some cool
applications. For example, you can now have Dainik Bhaskar
rendered in
Malayalam if I can understand Hindi, but can't read the
Devanagari
script. It also provides a simple mechanism to do the much
maligned
reverse mapping (from Unicode back to any proprietary
font).


> 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; +++++++
>

See Devanagari.initialize().

Thanks,
Nagarjuna
_______________________________________________
Padma mailing list
Padmamozdev.org
http://mozde
v.org/mailman/listinfo/padma

గురు, 2007-05-24 at 19:07 +0530 నాడు,
kinshulstudents.iiit.ac.in
వ్రాశారు:
[...]
> 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....

There is no way to properly generate the reverse mappings
from the
mapping that are available in Padma.

The method I have described earlier involves treating Padma
as a black
box converter and using brute force (helped by sample pages)
to identify
what input sequence will generate a required output
sequence. As we
talked earlier, we shall discuss again in detail in the next
meeting
tomorrow.

Thanks,

-- 
Sunil

_______________________________________________
Padma mailing list
Padmamozdev.org
http://mozde
v.org/mailman/listinfo/padma