freetype-devel
[Top][All Lists]
Advanced

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

Re: [ft-devel] controlling FreeType modules


From: suzuki toshiya
Subject: Re: [ft-devel] controlling FreeType modules
Date: Fri, 07 Sep 2012 23:53:28 +0900
User-agent: Mozilla-Thunderbird 2.0.0.12 (X11/20080406)

Chris Liddell wrote:
> On 07/09/12 03:34, Akira TAGOH wrote:
>> On Thu, Sep 6, 2012 at 11:32 PM, Chris Liddell
>> <address@hidden> wrote:
>>> I just think that Freetype should remain an engine which takes a font 
>>> from
>>> some source, and uses it to to create outline or bitmap glyphs. I 
>>> would not
>>> like to see Freetype getting sucked into loading fonts by name (even 
>>> if that
>>> was done by punting off the fontconfig), or gaining any kind of layout
>>> capabilities.
>>
>> But it's what one has to be done for CFR. otherwise someone needs to
>> write another library to support CFR, which may has a lot of duplicate
>> code to FreeType.
> 
> I don't see that being the case at all. As Werner mentioned, it could 
> better be implemented as a layer over Freetype.

Tagoh-san, could you describe more about the advantage to put full CFR
support into FreeType?

I think, the significant advantage is the minimized cost of the migration
from concrete TrueType/OpenType with 64k glyph limitation to the CFR without
such limitation. If FreeType supports CFR fully, with builtin fontconfig
client etc, just upgrading the older FreeType library to new one would be
sufficient. It's very happy scenario.

In fact, it is not rare to see the posts to freetype (or freetype-devel)
mailing list asking a question like "why Microsoft Windows can show every
Unicode characters by Arial font, but FreeType2 cannot do such?".
Often I reply as "what you specify on Microsoft Windows is not arial.ttf,
it is ...", but I don' think the people asking the question can get any
pragmatic solution from my reply (and I guess they may feel as if they are
forced to give it up what they wanted to do originally). If FreeType supports
CFR directly and fully, I can post the solution for them. It's very happy
scenario.

However, as I've investigated the the number of applications/libraries
assuming as they access concrete font files is not negligible. To support
CFR fully without asking some change in these applications/libraries,
some fake concrete fonts should be synthesized. I'm afraid that debugging
such layer would not be so easy, and it is difficult for FreeType developers
to guarantee the faked fonts are safe/stable for current FT2 clients.
That's why I proposed to support CFR with another layer, at the beginning.

Regards,
mpsuzuki




reply via email to

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