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

[Werner LEMBERG]

> I don't know if some of you won't hate me for this, but I've
> commited this morning a new module in the CVS named "ftvalid"

Expect a bomb within a few days...

> Actually, the sources of these modules have been imported into
> "ftvalid" with nearly no changes, and some hideous pre-processor
> glue is used to compile the sources as if they were part of the
> original FT2 source directory.

OK.

> IMPORTANT: Note that, at the moment, you'll need "Jam" to
> compile the library and test program. I had no time to write 
> portable Makefiles for this project.

I ask you not to remove the source files from the original location
until the new module works with GNU make.

BTW, I'm not really happy that you want to move it into another CVS
module.  Those files are really part of FreeType and quite tightly
integrated.  Instead I suggest that we extend FreeType's source tree
structure, adding a new top-level directory `addons' which is filled
with extra stuff.

Do you have any experience in library dependencies?  If I understand
you correctly, otvalid and gxvalid should be a separate library
`libftvalid' which depends on `libfreetype', right?

>   - finally, I wonder if the code is that useful. For example, it
>     doesn't check that all alignment constraints are respected by
>     offsets. What this means is that even a table that was
>     succesfully "validated" might crash a library like ICU Layout on
>     Sparc processors.

I don't really understand.  Please explain with an example.  If such
tests are still missing we can add them.

> I guess that we will not remove the public APIs defined so far from
> FreeType 2, but their implementation will simply return
> FT_Err_Unimplemented instead.

Ideally, FreeType should have support for external plugins.  This is,
if FreeType finds libftvalid, it uses it, otherwise you get
FT_Err_Unimplemented.  It seems that we have to start with libtool's
`dlopen' function...

Sigh.  All these things mean a lot of additional work.  Isn't it
easier to simply disable those two modules?  I'm already thinking how
to have a central configuration file which controls the used modules
-- without removing or renaming the rules.mk files...


    Werner