[ft-devel] ftvalid
I tried ftvalid for the first time today. At first it just told me that every font I fed it was invalid. I discovered this was because the default freetype does not include the validation modules. After changing modules.cfg everything passed. I wonder... would it be possible to have FT_OpenType_Validate return something other than FT_Err_Invalid_Argument if the validation service is not present, and have ftvalid check for the error and generate an error saying that the service isn't present rather than that the font is invalid? I found it a little confusing to have the default build tell me everything was invalid. It would be nicer to know that the font might be ok, but I need to rebuild the library... ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ftvalid
Hi, Sorry for spending your time by non-intuitive behaviour of validation modules and ftvalid. On 14 Jun 2006 20:47:48 -0700 George Williams <[EMAIL PROTECTED]> wrote: >I tried ftvalid for the first time today. > >At first it just told me that every font I fed it was invalid. I >discovered this was because the default freetype does not include the >validation modules. After changing modules.cfg everything passed. Oops. Possibly the exist of ftvalid itself made you confused. At present, ft2demos builds ftvalid whenever the public APIs of validation modules (FT_OpenType_Validate()) are available, even if it's just pseudo function and the internal validation functions are disabled by modules.cfg. If it's bad idea, I will fix ft2demos/Makefile to build ftvalid only when the internal validation functions are enabled. Please let me know your thought. >I wonder... would it be possible to have FT_OpenType_Validate return >something other than FT_Err_Invalid_Argument if the validation service >is not present, and have ftvalid check for the error >and generate an error saying that the service isn't present rather than >that the font is invalid? Sorry, when the internal validators are disabled, FT_XXX_Validate() should return FT_Err_Unimplemented, instead of FT_Err_Invalid_Argument. It was my mistake. I remember we had ever discussed this issue and agreed to implement so, when validation functions are decided to be disabled by default (around 2005-11?), but I slipped to fix that. Within 6 hours, I will fix it in CVS. Thanks and Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ftvalid
Toshiya-san, could you add following code to ftvalid.c?
status = validator_function();
if ( status = FT_Err_Unimplemented_Feature ) {
fprintf("xx_validator module is not compiled in your libfreetype2");
...
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ftvalid
On Thu, 15 Jun 2006 18:22:14 +0900 (JST)
Masatake YAMATO <[EMAIL PROTECTED]> wrote:
>Toshiya-san, could you add following code to ftvalid.c?
>
> status = validator_function();
>
> if ( status = FT_Err_Unimplemented_Feature ) {
> fprintf("xx_validator module is not compiled in your libfreetype2");
> ...
OK, following messages are enough?
Index: src/ftvalid.c
===
RCS file: /cvsroot/freetype/ft2demos/src/ftvalid.c,v
retrieving revision 1.7
diff -u -r1.7 ftvalid.c
--- src/ftvalid.c 25 Feb 2006 22:32:36 - 1.7
+++ src/ftvalid.c 15 Jun 2006 10:36:51 -
@@ -439,7 +439,10 @@
face,
validation_flags,
&data[0], &data[1], &data[2], &data[3], &data[4] );
-
+
+if ( error == FT_Err_Unimplemented_Feature )
+ printf( "FT_OpenType_Validate is disabled, replace FreeType2 with
otvalid-enabled version\n" );
+
report_result( data, validation_flags, ot_table_spec, N_OT_TABLE_SPEC );
for ( i = 0; i < N_OT_TABLE_SPEC; i++ )
@@ -489,7 +492,10 @@
validation_flags,
data,
N_GX_TABLE_SPEC );
-
+
+if ( error == FT_Err_Unimplemented_Feature )
+ printf( "FT_TrueTypeGX_Validate is disabled, replace FreeType2 with
gxvalid-enabled version\n" );
+
report_result( data, validation_flags, gx_table_spec, N_GX_TABLE_SPEC );
for ( i = 0; i < N_GX_TABLE_SPEC; i++ )
@@ -552,6 +558,8 @@
validation_flags,
&data );
+if ( error == FT_Err_Unimplemented_Feature )
+ printf( "FT_ClassicKern_Validate is disabled, replace FreeType2 with
gtvalid-enabled version\n" );
if ( data )
printf( "pass\n" );
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ftvalid
> >Toshiya-san, could you add following code to ftvalid.c?
> >
> > status = validator_function();
> >
> > if ( status = FT_Err_Unimplemented_Feature ) {
> > fprintf("xx_validator module is not compiled in your libfreetype2");
> > ...
>
> OK, following messages are enough?
> --- src/ftvalid.c 25 Feb 2006 22:32:36 - 1.7
> +++ src/ftvalid.c 15 Jun 2006 10:36:51 -
> @@ -439,7 +439,10 @@
>face,
>validation_flags,
>&data[0], &data[1], &data[2], &data[3], &data[4] );
> -
> +
> +if ( error == FT_Err_Unimplemented_Feature )
> + printf( "FT_OpenType_Validate is disabled, replace FreeType2 with
> otvalid-enabled version\n" );
> +
> report_result( data, validation_flags, ot_table_spec, N_OT_TABLE_SPEC );
>
> for ( i = 0; i < N_OT_TABLE_SPEC; i++ )
> @@ -489,7 +492,10 @@
>validation_flags,
>data,
>N_GX_TABLE_SPEC );
> -
I didn't test following code but I think following code may be better:
if ( error == FT_Err_Unimplemented_Feature )
{
fprintf(stderr,
"FT_OpenType_Validate is disabled, replace FreeType2 with
otvalid-enabled version\n" );
}
else
{
report_result( data, validation_flags, ot_table_spec, N_OT_TABLE_SPEC
);
}
Here stderr should be used instead of stdout.
I think it may be better to be put report_result in else {}.
Regards,
Masatake YAMATO
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ftvalid
At George's suggestons, I've rewritten some part of ftvalid.
In my new code ftvalid tries to detect gxvalid is available
or not with following code:
/* Checking availability of FT_TrueTypeGX_Validate
before running validator */
error = FT_TrueTypeGX_Validate( NULL, 0, NULL, 0 );
if ( error == FT_Err_Unimplemented_Feature )
panic (error, "FT_TrueTypeGX_Validate is not available );
However, this code doesn't work. NULL and zero args are checked
before checking the module availability in FT_TrueTypeGX_Validate.
FT_EXPORT_DEF( FT_Error )
FT_TrueTypeGX_Validate( FT_Face face,
FT_UInt validation_flags,
FT_Bytes tables[FT_VALIDATE_GX_LENGTH],
FT_UInt table_length )
{
FT_Service_GXvalidate service;
FT_Error error;
if ( !face )
{
error = FT_Err_Invalid_Face_Handle; <
goto Exit;
}
if ( tables == NULL )
{
error = FT_Err_Invalid_Argument; <<
goto Exit;
}
FT_FACE_FIND_GLOBAL_SERVICE( face, service, GX_VALIDATE );
if ( service )
error = service->validate( face,
validation_flags,
tables,
table_length );
else
error = FT_Err_Unimplemented_Feature; < FINALY...
Exit:
return error;
}
I think FT_Err_Unimplemented_Feature should be returned immediately
if gxvalid module is not available. However, current implementation
requires non-NULL face and non-NULL tables in any case.
libfreetype2.so itself knows gxvalid module is available or not.
Toshiya-san, do you remember who wrote this code? Did I?
Masatake YAMATO
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ftvalid
I think the original design (check face, then check tables, and
finally check service-availability) was by Werner, on 2004.
At that time, the modularization of validators was not expected.
Please check:
http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/base/ftotval.c?rev=1.1&view=markup
Regards,
mpsuzuki
On Fri, 16 Jun 2006 06:17:44 +0900 (JST)
Masatake YAMATO <[EMAIL PROTECTED]> wrote:
>At George's suggestons, I've rewritten some part of ftvalid.
>In my new code ftvalid tries to detect gxvalid is available
>or not with following code:
>
> /* Checking availability of FT_TrueTypeGX_Validate
> before running validator */
> error = FT_TrueTypeGX_Validate( NULL, 0, NULL, 0 );
> if ( error == FT_Err_Unimplemented_Feature )
> panic (error, "FT_TrueTypeGX_Validate is not available );
>
>However, this code doesn't work. NULL and zero args are checked
>before checking the module availability in FT_TrueTypeGX_Validate.
>
> FT_EXPORT_DEF( FT_Error )
> FT_TrueTypeGX_Validate( FT_Face face,
> FT_UInt validation_flags,
> FT_Bytes tables[FT_VALIDATE_GX_LENGTH],
> FT_UInt table_length )
> {
>FT_Service_GXvalidate service;
>FT_Error error;
>
>
>if ( !face )
>{
> error = FT_Err_Invalid_Face_Handle; <
> goto Exit;
>}
>
>if ( tables == NULL )
>{
> error = FT_Err_Invalid_Argument; <<
> goto Exit;
>}
>
>FT_FACE_FIND_GLOBAL_SERVICE( face, service, GX_VALIDATE );
>
>if ( service )
> error = service->validate( face,
> validation_flags,
> tables,
> table_length );
>else
> error = FT_Err_Unimplemented_Feature; < FINALY...
>
> Exit:
>return error;
> }
>
>
>I think FT_Err_Unimplemented_Feature should be returned immediately
>if gxvalid module is not available. However, current implementation
>requires non-NULL face and non-NULL tables in any case.
>libfreetype2.so itself knows gxvalid module is available or not.
>
>Toshiya-san, do you remember who wrote this code? Did I?
>
>Masatake YAMATO
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ftvalid
> I think FT_Err_Unimplemented_Feature should be returned immediately > if gxvalid module is not available. However, current implementation > requires non-NULL face and non-NULL tables in any case. > libfreetype2.so itself knows gxvalid module is available or not. Please, ignore my last message. I found I should use FT_Get_Module to know whether gxvalid is available or not in ftvalid. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ftvalid
> I tried ftvalid for the first time today. > > At first it just told me that every font I fed it was invalid. I > discovered this was because the default freetype does not include the > validation modules. After changing modules.cfg everything passed. > > I wonder... would it be possible to have FT_OpenType_Validate return > something other than FT_Err_Invalid_Argument if the validation service > is not present, and have ftvalid check for the error > and generate an error saying that the service isn't present rather than > that the font is invalid? > > I found it a little confusing to have the default build tell me > everything was invalid. It would be nicer to know that the font might be > ok, but I need to rebuild the library... Thank you for you suggestion. I revised ftvalid.c to show messages and exit if validate modules is not present. I also improved help message. Now it shows each validate module is implemented or not. [EMAIL PROTECTED]/var/typehack/ft2demos/bin% ./ftvalid -t ot /tmp/foo.c ./ftvalid -t ot /tmp/foo.c FT_OpenType_Validateis disabled. replace FreeType2 with otvalid-enabled version error = 0x0007 [EMAIL PROTECTED]/var/typehack/ft2demos/bin% ./ftvalid -h ./ftvalid -h lt-ftvalid: invalid option -- h ftvalid: layout table validator -- part of the FreeType project --- Usage: lt-ftvalid [options] fontfile -t validator select validator. Available validators: "ot"(NOT IMPLEMENTED) "gx" "ckern" ... Masatake YAMATO ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ftvalid
On Fri, 2006-06-16 at 13:32, Masatake YAMATO wrote: > Thank you for you suggestion. > I revised ftvalid.c to show messages and exit if validate modules is not > present. I also improved help message. Now it shows each validate module > is implemented or not. Excellent! Thank you very much. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ftvalid
> Sorry, when the internal validators are disabled, FT_XXX_Validate() > should return FT_Err_Unimplemented, instead of FT_Err_Invalid_Argument. > It was my mistake. I remember we had ever discussed this issue and > agreed to implement so, when validation functions are decided to > be disabled by default (around 2005-11?), but I slipped to fix that. > Within 6 hours, I will fix it in CVS. After rethinking, I found a case that FT_Err_Unimplemented is not enough. With current code, FT_Err_Unimplemented is returned even if a bdf face is passed to FT_TrueTypeGX_Validate. From the return value the user cannot distinguish (1) a validator is just disabled when building libfreetype2 nor (2) a validator service doesn't support the face passed as an argument. With following patch FT_TrueTypeGX_Validate returns FT_Err_Unimplemented_Feature for the case (1); and FT_Err_Invalid_Argument for the case (2). Toshiya-san and Werner, do you think this is over kill? If I get approval from you, I'll install patches for GX and OT. Masatake YAMATO --- ftgxval.c 16 6月 2006 04:42:51 +0900 1.4 +++ ftgxval.c 22 6月 2006 13:23:26 +0900 @@ -61,8 +61,10 @@ validation_flags, tables, table_length ); -else +else if ( FT_Get_Module( FT_FACE_LIBRARY( face ), "gxvalid" ) == NULL ) error = FT_Err_Unimplemented_Feature; +else + error = FT_Err_Invalid_Argument; Exit: return error; ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ftvalid
On Thu, 22 Jun 2006 13:45:45 +0900 (JST)
Masatake YAMATO <[EMAIL PROTECTED]> wrote:
>After rethinking, I found a case that FT_Err_Unimplemented is not
>enough. With current code, FT_Err_Unimplemented is returned even if a
>bdf face is passed to FT_TrueTypeGX_Validate. From the return value
>the user cannot distinguish (1) a validator is just disabled when building
>libfreetype2 nor (2) a validator service doesn't support the face
>passed as an argument.
>
>With following patch FT_TrueTypeGX_Validate returns
>FT_Err_Unimplemented_Feature
>for the case (1); and FT_Err_Invalid_Argument for the case (2).
>
>Toshiya-san and Werner, do you think this is over kill?
Looking other modules, it seems that yet we have not
decided the policy to follow.
For example, src/base/ftwinfnt.c for WinFNT driver
has function like this:
FT_EXPORT_DEF( FT_Error )
FT_Get_WinFNT_Header( FT_Face face,
FT_WinFNT_HeaderRec *header )
{
FT_Service_WinFnt service;
FT_Error error;
error = FT_Err_Invalid_Argument;
if ( face != NULL )
{
FT_FACE_LOOKUP_SERVICE( face, service, WINFNT );
if ( service != NULL )
{
error = service->get_header( face, header );
}
}
return error;
}
Here, we cannot discriminate between the error is because
"WinFNT support is not builtin" or because "invalid face
(e.g. BDF) is passed to WinFNT driver".
David, Werner and Yamato-san, I think it's time to decide
a policy. I have 2 ideas in following, which is better?
Policy A:
Direct call of FT_XXX() does not return reliable
information about the availability of functionality,
although the interface of excluded module must return
SOME error. The availability should be checked by FT_Get_Module().
Policy B:
Direct call of FT_XXX() returns the information
about the availability of functionality. To discriminate
between "no driver" and "driver exists but unimplemented
feature is requested", FT_Err_Unimplemented_Feature should
not be used to return an error caused by builtin modules.
For example, following usage should be fixed - because
FNT_Size_Request() is built, and the error is caused by
invalid flag.
static FT_Error
FNT_Size_Request( FT_Size size,
FT_Size_Request req )
{
FNT_Face face= (FNT_Face)size->face;
FT_WinFNT_Header header = &face->font->header;
FT_Bitmap_Size* bsize = size->face->available_sizes;
FT_Error error = FNT_Err_Invalid_Pixel_Size;
FT_Long height;
height = FT_REQUEST_HEIGHT( req );
height = ( height + 32 ) >> 6;
switch ( req->type )
{
case FT_SIZE_REQUEST_TYPE_NOMINAL:
if ( height == ( bsize->y_ppem + 32 ) >> 6 )
error = FNT_Err_Ok;
break;
case FT_SIZE_REQUEST_TYPE_REAL_DIM:
if ( height == header->pixel_height )
error = FNT_Err_Ok;
break;
default:
error = FNT_Err_Unimplemented_Feature;
break;
}
if ( error )
return error;
else
return FNT_Size_Select( size );
}
-
I think, although policy A is theoretically right, I prefer
policy B. Because, it is easy for LD_PRELOAD trick to rewrite
disabled FT_Get_WinFNT_Header() to working one, but it is
difficult to rewrite FT_Get_Module() with disabled WinFNT.
Yet I've not made such demos, it's just conceive.
Regards,
mpsuzuki
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ftvalid
> I think, although policy A is theoretically right, I prefer > policy B. Me too. Please go ahead and apply fixes! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ftvalid
This small issue is not so small as I expected. > I think, although policy A is theoretically right, I prefer > policy B. Because, it is easy for LD_PRELOAD trick to rewrite > disabled FT_Get_WinFNT_Header() to working one, but it is > difficult to rewrite FT_Get_Module() with disabled WinFNT. > Yet I've not made such demos, it's just conceive. I prefer the policy B, too. However, here is some discussion. I guess your LD_PRELOAD will not be effective on applications. Maybe the application will call FT_Get_Module by itself before calling FT_TrueTypeGX_Validate as ftvalid does; and if FT_Get_Module returns NULL, the applicaiton does exit(2) or runs but never calls FT_TrueTypeGX_Validate. About validator I guess the application may want to check a module existence before calling the module function. Assume an application wants to call FT_Get_Module to check a module existence. The applicatoin must know the name of module: In my last patch, "gxvalid" is the name an application must know. --- ftgxval.c 16 6月 2006 04:42:51 +0900 1.4 +++ ftgxval.c 22 6月 2006 13:23:26 +0900 @@ -61,8 +61,10 @@ validation_flags, tables, table_length ); -else +else if ( FT_Get_Module( FT_FACE_LIBRARY( face ), "gxvalid" ) == NULL ) error = FT_Err_Unimplemented_Feature; +else + error = FT_Err_Invalid_Argument; Exit: return error; I think it is better to use FT_VALIDATE_TRUETYPEGX_MODULE_NAME instead of "gxvalid" in the application and define FT_VALIDATE_TRUETYPEGX_MODULE_NAME in freetype2's header. Currently, the module name is defined in build-system related file, not in *.[ch]. Masatake ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ftvalid
> I think it is better to use FT_VALIDATE_TRUETYPEGX_MODULE_NAME > instead of "gxvalid" in the application and define > FT_VALIDATE_TRUETYPEGX_MODULE_NAME in freetype2's header. Currently, > the module name is defined in build-system related file, not in > *.[ch]. This is fine with me. If necessary you might even define a new error code to handle a missing module or service. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ftvalid
> > I think it is better to use FT_VALIDATE_TRUETYPEGX_MODULE_NAME > > instead of "gxvalid" in the application and define > > FT_VALIDATE_TRUETYPEGX_MODULE_NAME in freetype2's header. Currently, > > the module name is defined in build-system related file, not in > > *.[ch]. > > This is fine with me. If necessary you might even define a new error > code to handle a missing module or service. Sorry to be late. I'll work on this issue today. Masatake YAMATO ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
