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 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.



On Wed, Jun 22, 2011 at 12:06 PM, Simon Pepping <>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

Reply via email to