[squeak-dev] Re: Sq font rendering [was: The future of Squeak &
Pharo ... etc]
Yoshiki Ohshima
yoshiki at vpri.org
Tue Jun 30 23:06:04 UTC 2009
At Tue, 30 Jun 2009 13:16:54 +0530,
K. K. Subramaniam wrote:
>
> On Tuesday 30 Jun 2009 3:09:15 am Yoshiki Ohshima wrote:
> > At Mon, 29 Jun 2009 22:30:31 +0300,
> >
> > Igor Stasenko wrote:
> > > So, do i understood you right: this information (leadingChar) could be
> > > useful sometimes.
> > > But real world examples showing that its completely useless , at least
> > > by now. And often only adds an unnecessary complexity & confusion in
> > > handing a text & communicating with world outside the Squeak.
> >
> > Well, but Squeak in Chinese/Japanese/Korean have been using it and
> > depending on it, so this characterization is not correct.
> The essential problem is the encoding of characters (graphemes) which have
> regional or lingual variations. Devanagari also has such examples. The
> grapheme 'a' is rendered differently in Bombay and in Calcutta. Should the
> variations be encoded in the context or in every grapheme codepoint?
Well, don't you rather say Mumbai and Kolkata?
> leadingChar is just one way to resolve such variations. Personally, I prefer
> handling such variations as part of the context. A grapheme is a notional
> element. We need to encode it so that we can input, calculate, combine,
> compare and sort notional elements. Visual appearance becomes important only
> for manual edit and print operations.
I guess I understand your point, but not sure what you would do to
implement "encode in the context".
-- Yoshiki
More information about the Squeak-dev
mailing list
|