Re: Accented Greek

Alexandros Diamantidis <adia hellug gr> writes:

> * Owen Taylor <otaylor redhat com> [2002-05-22 14:44]:
> > 
> > Adding the Greek compose sequences to the default input method can
> > certainly be done. They are in there currently because they weren't in
> > XFree86 when I created the current table.
> I'm not sure when exactly they were added, but they are there
> now, in xc/nls/Compose/iso8859-7.
> > A more complex question (if not so immediately useful) is whether
> > compose sequences for the "Greek Extended" characters in the 1F00
> > block of Unicode should be added, or whether, instead, we should
> > produce text with combining sequences.
> A fellow Greek Linux user, Vasilis Vasaitis, has written a Perl script
> that produces a compose table for polytonic Greek and has submitted it
> to XFree86. It uses the precomposed forms, and works well. The only
> problem is that the resulting table is quite long, about 1500 entries,
> because it has to contain all dead key permutations. Does it matter? The
> basic Greek compose sequences are 100 or so.

The overhead of each entry in the input method table is 12 bytes ...
an extra 18k of shared overhead isn't a huge concern to me, though
what we could do is create a "Greek" input method that derived
from the default input method and added these compose sequences.

> > (One reason this is not so immediately useful is that rendering of
> > polytonic Greek using the current Pango shapers is very good. 
I meant to say "not very good"

> Do you mean that Pango can render polytonic Greek using combining
> characters? I tried to test it with pango-viewer and gtk-demo, and
> couldn't make it work. In both cases I got the base characters without
> any diacritics. The underlying text was correct, since I could copy it
> in an xterm and get the correct rendering there. Does/will Pango support
> stacking arbitrary combining diacritics on Latin and Greek characters?

I'm rather surprised that you got the base characters with the diacritics.
I would have expected you to get the base characters with poorly positioned

There are several directions to go to improve the situation here:

 - For the basic-xft shaper, we should support the 'mark' and 'mmark'
   OpenType features so that we can take advantage of the full accent
   positioning capabilitiesof OpenType fonts.

 - The basic shapers should probably try composing the input   
   and looking for precomposed glyphs.

 - We could add a special Greek shaper that did Greek-specific 
   accent positioning; we do for Hebrew right now.
> The procomposed "Greek Extended" characters indeed work very well.
> > The other reason is that modern Greek is clearly more useful.)
> Of course! I don't know anyone typing polytonic Greek directly in Unix -
> those who need them use TeX - but since now it works, I'm sure people
> will start using it more.
> Anyway, aside of whether compose sequences for Greek should be added to
> the Default input method, I think that making the X Input Method the
> default for Greek locales is a good idea, since it allows both basic and
> extended Greek to work without changing input methods, and it is a very
> simple change.

Hmm, I'd rather not use XIM here:

 - XIM is missing a few features as compared to the "Default" input
   method. (Control-shift-digits unicode entry, incremental display of 
   compose eequences.)
 - XIM has a large (several hundred k) overhead when initialized.
 - It would be nice if we didn't require XIM to handle Greek, since
   not XIM input methods are cross-platforms.

I think it's probably better to add support to the basic shaper or
to a special Greek shaper.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]