Re: [Render] Re: OpenType support in Pango

[Owen Taylor <otaylor redhat com>]

Antoine Leca <Antoine Leca renault fr> writes:

> Owen Taylor wrote:
> > 
> > > > It's probably a day or so additional work to get positioning of
> > > > accents working. A really sophisticated use of OpenType like the
> > > > OpenType Indic spec would require considerably more work.
> > 
> > Pango actually has Indic rendering code for a large range of languages
> > usingn BDF fonts (thanks to Robert Brady), and this is again based
> > on the descriptions in the Unicode specfication, so that's probably
> > a good start.
> 
> Probably, but I do not believe it complies nicely with OT indic...
> OTOH, the goal is to have Indic rendered, so it may be another valuable
> path! 

> And Indic OT fonts are not very frequent these days, contrary to
> what MS may have envisionned...

I'm not very suprised by that - the spec has only been public for 6
months or so, and I don't think tools have caught up yet.

But, yes, it is not easy an easy spec for font vendors to handle.  (My
thought when reading over the spec this week was "hmmm, this wouldn't
be that hard to implement in Pango, but I wouldn't want to be creating
a font".)

I think what would kick-start vendor adoption would be an open-source
font which vendors could tear apart, replace the glyphs with their own
versions, and tweak a bit. After all, with that approach it isn't
harder to deal with than a fixed glyph encoding.

(For Arabic fonts, I've seen evidence that other vendors have pretty
much copied the OpenType tables from Microsoft's fonts with different
glyphs.)

> > I don't think that the amount of new code that needs to be written to
> > get the OT Indic spec working is actually that big, the reason why I
> > think it is a significant amount of work (a week or two, anyways) is
> > that there are a lot of things that can go wrong:
> > 
> >  - It has a large number of lookups that interact in complex ways,
> 
> Right. And last time I looked at this, the scheme used in FT1 was not
> very easy to use, because the lockups (from 4 to 14, usually) are to be
> applied to limited runs of glyphs rather than complete strings, which
> means a lot of managing for small pieces, which seems to me the reverse
> of FT1 OT aims (but I confess I never gave it a try to see what is
> the real performance hit: implement even a part of the specs appears
> to me too much a job to allow toying :-( ).

Its true that the implementation in FT1 where the string is copied
over for every lookup applied is not very suited to applying large
sets of lookups, however I think the model:

 - Set per-glyph properties determining which lookups should be applied.
 - Apply a series of lookups to the entire string.

Is fine, and a lot simpler than alternatives. I haven't disassembled
a OT Indic font, but from my reading of the spec it seems that
most of the lookups could actually be applied to all characters,
and the coverage information for the lookups would determine which
characters to which they apply.

> >  - These lookups use quite a bit of the OpenType layout spec.
> > 
> >  - The set of languages that is covered is big so testing is hard.
> 
> What do you mean here ?

What I mean is that unlike, say, Arabic, where you have basically 
one script with a few languages using variations of it, the set
of "Indic" languages is large with substantial variation between
scripts. Excluding Thai and Lao, Unicode 3.0 has about 12 scripts
in this group. Of course, you wouldn't have to implement all
or most of those languages initially, but making sure you got
everything right for even a subset would require both specialized
knowledge and a lot of work.

> >  - There are certainly missing details from the spec that will
> >    take some experimentation to figure out.
> 
> I believe that the support for scripts other than Nagari and Tamil
> is still unfinished at Microsoft (particularly for the most complex
> ones like Malayalam) ;-)

Well, hopefully this is an area that open source can come out ahead -
put out a framework and let those who need it fill in the details.

Regards,
                                        Owen