Re: [Devel] Fw: Freetype, fontconfig,Xft, Mozilla and Non-BMP char. support

[Antoine Leca]

Hi again,

I wrote:
>  >   Below are links to FT2 patch (against 2.1.3)
>  >
>  >  http://bugzilla.mozilla.org/attachment.cgi?id=107852 : FT2 patch
>
> Thanks. However, I have written something slightly different,
> which mimics the behaviour of open_face.

The more I think about it, the more I believe the way it has to be done
is in fact a can of worms.
Presently, open_face() scans through all charmaps, retaining all that
are Unicode encodings. And of course, the last one wins. Usually, this
is not a problem, since:
 - either the font knows only about UCS-2 characters (vast majority),
   so anything is equals, and the last one, probably the 3,1, is in fact
   what we are seeking for;
 - either the font has UCS-4 characters, and the guy (the foundry) knows
   about MS specs, and there is a 3,10 table, which will be (with the
   current specs) the last in order, so this is OK too.

However, there is two potentials pitfalls.
 - one is that a foundry may have encoded according to Apple specs (so
   has a 0,4 table which has the UCS-4 decoding); but if at the same time
   they provide the minimum Windows compatibility, i.e. a 3,1 table
   (without the UCS-4 characters), then it would be this later table which
   would be kept;
   I agree this is a contrived case, very improbable in fact.
 - another is a potential revision of the specs, which will create another
   pairs, says 4,5, which will also be another Unicode (but UCS-2) encoding.
   Then the logic will be brocken (but since this needs an update to
   the Freetype sources, in this case in src/sfnt/sfobjs.c, so we have a
   chance to save ourselves ;-)).

So bottom line, it works, but we are not playing on the safe side, IMHO.
Please comment whether you prefer more safe coding (based on Jungshik Shin
patch).

Antoine