[Top][All Lists]
[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
- RE: [ft-devel] Migrating layout table validation code to a new CVSmodule, Turner, David, 2005/11/21
- RE: [ft-devel] Migrating layout table validation code to a new CVSmodule, Turner, David, 2005/11/21
- Re: [ft-devel] Migrating layout table validation code to a new CVSmodule,
mpsuzuki <=
- RE: [ft-devel] Migrating layout table validation code to a new CVSmodule, Turner, David, 2005/11/22
- RE: [ft-devel] Migrating layout table validation code to a new CVSmodule, Turner, David, 2005/11/22