I tested the latest code in the branch ComplexScripts with a font called Lohit-Devanagari, version 2.4.5, copyright Red Hat, license GPLv2, file lohit_hi.ttf, Debian package ttf-devanagari-fonts. Fontforge shows that the font has 2 GPOS tables and a large number of GSUB tables.
I was not successful. The result showed for the first word first the vocal R, before the left margin, then within the margin Pa, then Virama, then Tha, Va, II. I tried to get more info. These are some observations: MultiByteFont.performPositioning returns null, because GlyphPositioningTable.position returns false, because GlyphPositioningTable has no matching lookups; <deva, NEP, abvm> and <deva, NEP, blwm> are defined, <dev2, dflt, *> is requested. MultiByteFont.performSubstitution returns the unmodified CharSequence because GlyphSubstitutionTable has no matching lookups; <deva, dflt, ''> and <deva, dflt, XXX> are defined, where XXX takes on many values, e.g. abvs, akhn, blwf, blws, half, etc.; <dev2, dflt, *> is requested. GlyphDefinitionTable.reorderCombiningMarks reorders the glyphlist from [90, 115, 85, 125, 101, 112] to [115, 90, 125, 85, 101, 112] (glyphs 2 and 4 are typed as combining marks). In MultiByteFont.reorderCombiningMarks this leads to a reordered CharSequence, from [92A, 943, 925, 94D, 935, 940] to [943, 92A, 94D, 925, 935, 940]. The result in the pdf file as described above reflects this reordering. Eclipse renders the original CharSequence as पृथ्वी, which is the expected outcome, and the reordered one as ृप्थवी, which is not expected. So the reordering seems counterproductive. I hope this is useful. Simon
