Microsoft changed the Indic script processing logic around 2008, and newer fonts provide both old 'deva' (now deprecated) and new 'dev2' tables. Apparently the older font you accessed does not. I have not tested against older fonts that do not support the new 'dev2' semantics.
I have listed the fonts that I have verified to work at http://skynav.trac.cvsdude.com/fop/wiki/SupportedFonts. At present, the script detection logic is returning 'dev2' when Devanagari is detected. You can override this by using script='deva'; however, I have not explicitly tested the Devanagari code against the older logic yet. Compare [1] (May 2008) versus [2] (March 2002) for further reference. G. [1] http://www.microsoft.com/typography/OpenType%20Dev/devanagari/intro.mspx [2] http://www.microsoft.com/typography/OpenType%20Dev/devanagari/introO.mspx On Wed, Jun 22, 2011 at 12:06 PM, Simon Pepping <spepp...@leverkruid.eu>wrote: > 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 >
