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

[mpsuzuki]

Dear Werner,

Thank you for quick comment. I agree with your comment
that more real-life example and expected behaviours
should be discussed if I change the behaviour of FT2.

Just I tested small changes are sufficient to pass GID
to FT_GlyphLoader_CheckPoints(), this is the direction A).
I will make similar experiments for other outline font
formats, and I will propose the patch officially.

--

(1) Add new member `glyph_index' to FT_GlyphLoaderRec,
    the internal data structure type. The reason why
    I extend FT_GlyphLoaderRec is because this is a
    structure which is (already) passed to FT_Glyph_CheckPoints().

diff --git a/include/freetype/internal/ftgloadr.h 
b/include/freetype/internal/ftgloadr.h
index ce4dc6c..76f9cf5 100644
--- a/include/freetype/internal/ftgloadr.h
+++ b/include/freetype/internal/ftgloadr.h
@@ -87,6 +87,7 @@ FT_BEGIN_HEADER
     FT_GlyphLoadRec  base;
     FT_GlyphLoadRec  current;
 
+    FT_ULong         glyph_index;      /* just for warning */
     void*            other;            /* for possible future extension? */
 
   } FT_GlyphLoaderRec;

(2) When FT_Load_Glyph() eats CFF font file, cff_slot_load()
    is called. FT_Glyph_CheckPoints() receives FT_GlyphLoader
    allocated in cff_slot_load(). If we write a glyph_index
    in cff_slot_load(), FT_Glyph_CheckPoints() will receive it.

diff --git a/src/cff/cffgload.c b/src/cff/cffgload.c
index 7074160..fb49635 100644
--- a/src/cff/cffgload.c
+++ b/src/cff/cffgload.c
@@ -2616,6 +2616,7 @@
 
       cff_decoder_init( &decoder, face, size, glyph, hinting,
                         FT_LOAD_TARGET_MODE( load_flags ) );
+      decoder.builder.loader->glyph_index = glyph_index;
 
       if ( load_flags & FT_LOAD_ADVANCE_ONLY )
         decoder.width_only = TRUE;


Regards,
mpsuzuki

On Wed, 08 Jul 2009 12:34:13 +0200 (CEST)
Werner LEMBERG <address@hidden> wrote:

>> 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?
>
>In case A) doesn't break the ABI this is good solution.  Regarding C)
>I'm not sure whether it makes sense to do that at all.  In case a
>glyph cannot be rendered correctly it really doesn't matter at all
>IMHO whether the returned metrics information is correct or not.  In
>other words, the client application can simply insert the default
>.notdef glyph and metrics.  D) sounds interesting, too.  Again the
>question whether we need this -- maybe someone can provide a (near)
>real-life example where such a behaviour is desired...
>
>
>    Werner