freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Antoine Leca
Subject: [Fwd: Re: [Devel] Fw: Freetype, fontconfig,Xft, Mozilla and Non-BMP char. support]
Date: Mon, 02 Dec 2002 23:15:30 +0100
User-agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530

Since Jungshik Shin is not on the devel list, I forward his message,
to allow redistribution, and perhaps discussions. If you want to
answer, don't forget to cc:-ing him.

I will answer later, I am finishing some tests... which are showing
that I was quite wrong. :-(. How embarrassing.

Antoine

-------- Missatge original --------
Assumpte: Re: [Devel] Fw: Freetype, fontconfig,Xft, Mozilla and Non-BMP char. support
Data: Mon, 2 Dec 2002 15:13:05 -0500 (EST)
De: Jungshik Shin <address@hidden>
A: Antoine Leca <address@hidden>
CC: address@hidden

On Mon, 2 Dec 2002, Antoine Leca wrote:

Hi,

Thank you for the detailed response.

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

> 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.
.... case 2 snipped..

  Yes, I thought about something related(I was concerned
about Apple's UCS4 cmap as well as about the possibility that pid=3/eid=10
coming before pid=3/uid=1) and that led me to take the approach I
took. BTW, are Cmaps always accessed/stored sorted in the ascending
order of pid and eid? Perhaps, they're and this is a stupid question..

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

  If I were you, I'd take a safer path which also happens to take
a bit less time in some very rare cases because it can stop when it
finds what it believes to be the most comprehensive Cmap -UCS4 cmap
before it reaches the end.

   Cheers,

   Jungshik

P.S. I'm not on FT devel. list so that I'm not sure whether this will
make it there. I guess you can just quote whatever portion you think of
as relevant in your reply to the list(so that others can see my ans.) if
this message is rejected from the list.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]