Re: [ft-devel] ftvalid

[mpsuzuki]

On Thu, 22 Jun 2006 13:45:45 +0900 (JST)
Masatake YAMATO <address@hidden> 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