Re: [ft-devel] controlling FreeType modules

[Akira TAGOH]

On Fri, Sep 7, 2012 at 11:53 PM, suzuki toshiya
<address@hidden> wrote:
> 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.

That's true and what I'm mainly concerned. I'm not that familiar with
FreeType API though, I guess it's not feasible to apply the modified
fonts metrics etc so far, right? this is why I'm requesting some
changes according to FreeType3 discussion too.
And the point that I think it would be better support CFR in FreeType
is, CFR itself could be a font file. even though it's a virtual font
that doesn't contain any outline nor bitmap data for glyphs.
So it shouldn't break the usage of the existing APIs.

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

Sure. if FreeType has any solution for that, that would be nice and
hope it may helps in case we may see in pure Xft-based applications
too. but I'm not expecting on this discussion to change the behavior
on the existing APIs too. rather I don't think it's needed.

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

Aha. interesting. well, I'm not at the position to recommend using CFR
strongly. so if CFR support can be implemented outside FreeType
without missing compatibility to FreeType APIs, I don't have any
objections. but just trying to find out if there are any easier way to
do it from the POV of application developers.

-- 
Akira TAGOH