freetype-devel
[Top][All Lists]
Advanced

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

Re: [ft-devel] Migrating layout table validation code to a new CVSmodule


From: mpsuzuki
Subject: Re: [ft-devel] Migrating layout table validation code to a new CVSmodule
Date: Tue, 22 Nov 2005 13:19:20 +0900

On Mon, 21 Nov 2005 10:39:32 +0100
"Turner, David" <address@hidden> wrote:
>> About plugin, it is good idea (although I'm afraid
>> that FreeType is very very widely used on platforms
>> without dlopen etc), but it will be long way work.
>> It should be FreeType3, even if the binary compatibility
>> is kept.
>> 
>There is no need for dlopen() or equivalent. We have FT_Add_Module
>which can be called just after FT_Init_FreeType to add modules to
>the font engine.
>
>That's what I use on my company's embedded software, to register
>custom font drivers for some proprietary bitmap formats we need
>to support. All is done statically.

Excuse me, I'm unfamiliar with FT_Add_Module().
I think, FT_Add_Modules() is capable to use functions
that are available in linking time. I'm not sure if
it can add modules derived from dlopen()-ed objects,
but, at least, on no-dlopen() systems, we have to link
both of libfreetype.a and libftvalid.a, to retain the
possibility to use otvalid/gxvalid module. Therefore,
I think, the situation is same with the case that otvalid
/gxvalid are included but disabled-by-default in
libfreetype.a itself. I'm afraid the difference is
just in the viewpoint of FreeType maintainer: the separate
update of libftvalid.a is enabled. My understanding
is right?

>>If I rewrite gxvalid to smaller and limited validation
>>(e.g. memory alignment, number of members etc) by
>>default, it's acceptable to include?
>
>I think that wouldn't solve the issue:
>
>- it's not really part of the font engine's work, since
>  we don't provide APIs to process the tables.

Indeed, but still I want the validation functions are
included to check the available feature before real
font file loading procedure. Werner, how do you think
of this issue?

>- it ties the releases of the validation and FT2 code,
>  when these could be independent.

I think, the feature of otvalid is almost fixed and won't
cause "urgent update to fix severe bug in otvalid". And,
my propose is the simplification gxvalid for such level.

Regards,
mpsuzuki




reply via email to

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