Re: [ft-devel] controlling FreeType modules

[suzuki toshiya]

Loading a font face by its name is too platform dependent problem
(some platform may have multiple font management systems and their
registries are often left with no synchronization), putting everything
for CFR into FreeType2 would be slightly difficult. My concern is
that the system maintainer will have to install multiple FreeType2
libraries configured for different font managements.

# A portable solution would be a standardization of the file format
# packing a CFR and its component font files into single container.
# I've ever posted such to SC29/WG11/font AHG, and one expert had
# commented it's tolerable idea. Unfortunately, other SC29/WG11/font
# AHG people gave no response - I'm looking for appropriate route to
# standardize it via JTC1.

And, some FreeType2 APIs (mainly getting the indepth content of
the font file, like, FT_Load_Sfnt_Table()) cannot be applied to CFR
directly. Also the consideration of FT_Get_Name_Index(), FT_Get_Char_Index()
would be needed.

Considering these issues, I think some thin wrapper library is expected
to support CFR really; it should provide a subset of FreeType2 APIs and
most of them are just passing the arguments to FreeType2 (after the translation
of CFR face object to appropriate font object). The API syntax is expected
to be same with FreeType2, to minimize the cost to rewrite the application
using FT2 directly.

--

BTW, another issue would be the Unicode layout features of CFR.
I guess the design of CFR assumes that the CFR object is dealt over the
layer of the text layout and does not assume that the user of CFR reads
OpenType (or AAT) layout tables from a CFR object. It would be possible
for CFR supporting library to identify which layout table of which
component font should be used, but returning its raw content would be
useless, because its glyph index is not unique number in CFR object.

It would be possible to translate the raw glyph index to the fake glyph
index for CFR, but as far as the OpenType supporting code request the
memory image of OpenType layout tables, the 64k glyph limitation is
still existing. I'm not sure if CFR supporting library should provide
the APIs to access OpenType layout table content.

# IMHO, the stake holders of OpenType layout tables and the breakage of
# 64k glyph limitation would be slightly different.

Regards,
mpsuzuki

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