[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