From: Vinod Kumar (rigvinod@gmail.com)
Date: Wed Mar 22 2006 - 23:23:29 CST
On 3/23/06, Richard Wordingham <richard.wordingham@ntlworld.com> wrote:
> Philippe Verdy wrote:
>
> > and reordering issues (at code point level) can also be achieved using
> > glyph IDs within substitution tables
>
> Not on Windows. For rendering only it can be imitated, but the imitation
> does not work for editing the text. If you appear to have swapped two
> glyphs (e.g. via contextual substitutions), apparently deleting one
> character will actually delete the other!
>
What Philippe Verdy said is correct. Normal editing works on the
backing store of characters and should not know how those characters
appear on the screen. The editor does not "swap characters". The
backing store will contain the characters in Logical order. Devanagari
Ki will be represented by Ka IMatra <915 93f>. The editor will present
the sequence <915 93f> to the lower level. Depending on the pipeline
below, the sequence may be reordered to <93f 915> (visual order of
characters for Microsoft and IndiX typography). Or it may be directly
passed to the font layer as in Apple Advanced Typography (AAT). If the
font gets the characters in logical order, then it has to reorder the
glyphs. With OpenType, reordering glyphs is a huge pain (which is why
the characters are reordered before the OpenType font). AAT does the
reordering within the font.
> For example, to 'swap' characters K and E with glyphs gK and gE you could
> try a sequence of rules such as:
>
> gK > E_for_K / _ gE
> gE > gK / E_for_K _
> E_for_K > gE
>
> which converts 'gK gE' to 'gE gK'. However, a process that would normally
> delete gK would delete E from the backing store, with the result that
> apparently deleting gK would convert the display 'gE gK' to 'gK'!
>
> Richard.
>
The mapping between what is highlighted on the screen and its
originating character is much more complex than the one to one
relationship between a Latin glyph and its character code. For Indic
scripts, most normal editors would not allow you to select gK alone.
The combination <gE gK> (Tamil, Malayalam?) would be selected
together. The sprite cannot be placed beween the gE and the gK.If the
sprite is placed after <gE gK> and an edit to delete the previous
character is attempted, the gE will disappear from the screen and not
gK. This is achieved most easily by the editor redrawing the screen by
clearing the line and sending the backing store line of characters
with E removed. Of course, you can complicate things for apparent
optimization by clearing only the region after <gE gK> to the end of
line and not the whole line. So the scenario described by Richard is
incorrect even if the reordering is done on glyphs within the OpenType
font.
Reordering of glyphs within the font becomes necessary when the font
does not have some glyphs. For example, consider Devanagari RDMa. If a
glyph gDMa is available then this can be displayed as <gDMA gReph>. If
gdMa is absent, but gHalfDa is present then it can be shown as
<gHalfDa gMa gReph>. If gHalfDa is absent (the normal case) then the
correct display is <gDa gHalant gReph gMA>. In this third case we will
need a glyph reordering within the font.
This reordering is best done at the font level as it is a result of a
decision at the font level. Some apparently clever people try to do
this at the higher level. They will send <Da Halant Ma> to the lower
level font, check whether it produces <gDa gHalant gMa> and if so send
<Ra Halant Da Halant> (or a reordered equivalent> followed by <Ma>.
Vinod Kumar
Project IndiX
-- पृथिवी सस्यशालिनी Prithivi Sasyashalini
This archive was generated by hypermail 2.1.5 : Wed Mar 22 2006 - 23:29:09 CST