Tamil Discussion archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [WMASTERS] Re: Character to Glyph and Software Gimicks
Kalyan wrote...
>I do not want to prolong discussions more than necessary.
>I am trying hard to understand how, without software gimmicks
>and without using emerging technologies, how someone
>who uses the proposed 8-bit font to type on a primitive computer
>can do what you propose - choose one form or other.
I have not played with the Mac as much as I have with Unix/Dos/
Windows/Java (wished I really had - my biggest regret in my
technical life :-( ). To at least get aquainted with the platform,
I do hang out at the apple site quite often. As such, please take
the information I provide with a pinch of salt - and please
investigate the web site URL's I've included.
My understanding is that MacOS supports glyph-substitution *today*.
I do not know which version of the OS but I'm pretty sure it does,
even before we talk about OpenType.
Check out the following URL :
http://font.apple.com - the 'thalaip pakkam' of all font
related issues on the Mac.
I have this link in my bookmark :
http://fonts.apple.com/TTRefMan/RM06/Chap6mort.html
and you may want to investigate the following sections on this
page :
Indic Rearrangement Subtable
Contextual Glyph Substitution Subtable
There is also a section on the tools (on the Mac) that'll help
you do this.
Also, The Indian language supplement (not sure if I got the name
right) on the Mac implements Devanagari (and Arabic too) fonts
using this glyph substitution feature.
If I'm right Kalyan, we may be able to implement what I have
been speaking about on the *Mac* platform *first* :-) before
anything else !
I really wish we do not get sidetracked into *font* issues.
If you can have a look at the Devanagari fonts that Apple makes
and see how this works, we *know* it works. We should just
move on to finish the encoding :-)
Hope I've helped and really wish you *can* view ORNL in your
old-macs :-)
anbudan,
~ MUTHU
P.S. IMHO, if we can't push it hard enough to realise ORNL in
MacOS 6.X, my feel is we can't help it. Just as we can't
limit something just because we can't realise it on
Windows 3.0 or DOS ;-) ORNL is *nice-to-have*. Without
--------------------------------
it, 6.x users can still read the same text in new style
-------------------------------------------------------
anyway :-)
----------
---- Begin included message ----
Dear Muthu:
> I choose *not* to argue with you on the 'half-baked-potatoe' issue.
> I think it's highly irrelavant - I see your frustrations coming into
> play and me being where I am has nothing to with it either :-).
No, Muthu, I am NOT frustrated.
If majority opinion is not have old style characters be it.
I will go along with it. But I would like to understand what you
are proposing.
I do not want to prolong discussions more than necessary.
I am trying hard to understand how, without software gimmicks
and without using emerging technologies, how someone
who uses the proposed 8-bit font to type on a primitive computer
can do what you propose - choose one form or other.
I can only talk about my decade experience as a user of Mac.
Open type fonts are not yet a standard on mac. At home, when
my wife or daughter use the Power Mac, I go back to my good
old MacPlus to do my typing of electronic texts of tamil. I am
quite happy using MacPlus typing tamil texts either in current
style or those that contain old-style characters using the tamil
font you know. Open Type usage on Mac requires usage of
System 7.x . There is no way I can install System 7.0 on my
MacPlus - because the built-in RAM slot is very very limited
in these old machines. With its design structure, MacPlus has
to die with System 6.x. Macs running on System 6.x cannot
have Open type. So you see the problem.
386 PCs I referred to in my post are in the same boat as MacPlus.
Now I just cannot see how I can do what you are proposing
of glyph substitution on these machines. If you or someone
else care to explain to me how the scheme will work on simple
machines like the one cited above, I am all in favour of it.
Having them in the scheme with their own unique codes
will allow typing to continue in either form even on these
primitive ones. Also, I haven't yet heard convincing
arguments on how having these extra characters
will lead to non-surmountable problems.
> What is your advice to software & CGI developers on *how* one could
> recognise if an old style lai/nai etc is used or a new style lai/nai
> is used ?
I think I already answered to similar question of Nagu yesterday.
I am repeating it here in case you missed. Can you please tell me
if I am totally wrong in my understanding?
Regarding the old style characters, the way I see things is as follows:
(in a scenario where unique code assignment is there for old style
kokki)
old style lai is a distinct beast (graphical representation) by itself.
If the kokki has a separate code of its own, lai comsisting of la
following this kokki is a different object from the current lai with
la following the aikara modifier (irandu chuzhi).
If an old text had this lai occurring in the old form
it will be keyed in and stored in that form with two glyphs.
Even in the same file if it appears in the new form it will be
typed and stored in that form.
For the human brain with built in intelligence, both old style lai
and current style lai are one and the same. But for a computer, the
encoded glyph sequence are different and so they are different
things. So where does the confusion in sorting or search arise?
If you search for the group [ (old style kokki)(la)] you will find
only these but not those with current versions.
Of course, we can always bring in software intervention if necessary
to identify the old style characters and replace them by the new format.
Probably this is where we differ in our conceptual role of how the
old style characters are handled in the character encoding scheme.
I enjoy healthy discussions. It is a learning process for all.
So I repeat, I do not get upset or frustrated.
Kalyan
---- End included message ----
Home |
Main Index |
Thread Index