[ft-devel] How FT_Load_Glyph() should work for the glyph description that cannot be rendered correctly?

[mpsuzuki]

Hi all,

Just I've committed my patch to GIT main trunk.

Current (CFF renderer in) FT2 does not return
the error code of check_points(), aslike:

   859    FT_LOCAL_DEF( FT_Error )
   860    cff_decoder_parse_charstrings( CFF_Decoder*  decoder,
   861                                   FT_Byte*      charstring_base,
   862                                   FT_ULong      charstring_len )
   863    {

   902      error = CFF_Err_Ok;

  1362          case cff_op_rlineto:
  1363            FT_TRACE4(( " rlineto\n" ));
  1364  
  1365            if ( cff_builder_start_point ( builder, x, y ) ||
  1366                 check_points( builder, num_args / 2 )     )
  1367              goto Fail;

  2368    Fail:
  2369      return error;

Thus, even if our parsing of Type2 Charstring is failed,
cff_decoder_parse_charstrings() returns successfully,
but with empty outline. Although the outline is empty,
the metric informations would be (usually) used, because
FT2 client would recognize the glyph has no outline but
finite size.

If cff_decoder_parse_charstrings() returns an error,
the metric informations would be (usually) ignored,
because FT2 client would recognize the glyph itself is
broken.

I guess, the users may want to be noticed that some glyphs
(with GID) are not rendered correctly, and the metrics
of ignored glyphs should be considered in text rendering.

Unfortunately, cff_decoder_parse_charstrings() doesn't
know the GID for the passed glyph description. The function
knowing GID is in higher layer, FT_Load_Glyph() etc.

   551    FT_EXPORT_DEF( FT_Error )
   552    FT_Load_Glyph( FT_Face   face,
   553                   FT_UInt   glyph_index,
   554                   FT_Int32  load_flags )
   555    {

   633      if ( autohint )
   634      {

   654        {

   666          error   = hinting->load_glyph( (FT_AutoHinter)hinter,
   667                                         slot, face->size,
   668                                         glyph_index, load_flags );
   669  
   670          internal->transform_flags = transform_flags;
   671        }
   672      }
   673      else
   674      {
   675        error = driver->clazz->load_glyph( slot,
   676                                           face->size,
   677                                           glyph_index,
   678                                           load_flags );
   679        if ( error )
   680          goto Exit;

So, if we insert a code to warn "Cannot render GID=xxx correctly!",
it should be around here. Thus, the error FT_Err_Array_To_Large
should be delivered to here.

But, in here, it is difficult to decide "the glyph description
is not rendered correctly, and the metric should not be used" or
"the glyph description is not rendered correctly, but the metric
can be used". Because, FT_Err_Array_To_Large is not restricted
to the case we cared. So, an insertion of such code is not good
idea:

                switch( error )
                {
                case FT_Err_Array_To_Large:
                case ...:
                        FT_ERROR(( ... ));
                        error = FT_Err_Ok;
                        break;

                default:
                        FT_ERROR(( ... ));
                }

There are a few directions:

A) Extend FT_GlyphLoader etc to pass GID to
   FT_GlyphLoader_CheckPoints. Issues the warnings with GID,
   but the error behaviour is same with current FT2.

B) Give up to issue a message with both of GID and array
   overflow. The glyph description parser issues an error or
   warning, but continues the process as current FT2 does.

C) Introduce new error number to pass "the glyph description
   cannot be rendered correctly by FT2, but other properties
   like the metrics are correctly obtained" to FT_Load_Glyph().

D) Make FT_Load_Glyph() ignore load_glyph() error when
   FT_LOAD_RENDER is not.

Anything else?

Regards,
mpsuzuki

On Tue, 7 Jul 2009 18:02:29 +0200
Boris Letocha <address@hidden> wrote:

>Hi,
>
>It is more or less exactly same as my temporary fix (including Array_Too_Large 
>error). So good for me.
>
>BTW: When stored inside PDF as Type2, Adobe Reader skip such character, 
>GhostScript crashes.
>
>Thanks,
>
>Boris Letocha
>
>-----Original Message-----
>From: address@hidden [mailto:address@hidden 
>To: Boris Letocha
>Cc: address@hidden; Werner LEMBERG
>Subject: Re: [ft-devel] Outline n_points are int16 so overflow is possible 
>because missing check
>