Re: [Freetype] freetype 2.1.2 cmap detection issue

[Phil Morris]

On Fri, Jan 03, 2003 at 12:23:15PM +0800, Anthony Fok wrote:
> Hello Phil,
> 
> Upgrading to freetype-2.1.3 is a solution, but it may be better to wait
> until the Red Hat official packages for freetype-2.1.3 are released.
> Red Hat's freetype-2.1.2 (and Xft, etc.) carries a few patches that need to
> be ported to 2.1.3 first, so you may run into problems compiling other
> libraries if you just upgrade to the stock upstream freetype-2.1.3.
> 
> Meanwhile, please try the attached patch and see if it fixes the problem.
> This patch is already in FreeType 2.1.3.
> Patch credit: Werner L., George W., David T., and I.  :-)
> 
> Cheers,
> 
> Anthony
> 

Anthony, 

Thanks for the reply and agreed on RH compatibility issues when
straying from offical rpms. 
I grabbed the stock RH8.0 freetype-2.1.2-7.src.rpm, applied your
patch and rebuilt.
All of my cvs apps having ttf font issues with the RH stock 
2.1.2-7 packages are now working great with the patch. 

I wonder if Redhat decides to hold phoebe aka 8.1 beta to 
freetype 2.1.2-12 whether we should try and get them to add this
patch? 

Phil, 

> On Wed, Jan 01, 2003 at 02:59:50PM -0700, Phil Morris wrote:
> > Hello, This is my first post to freetype and sorry for the long 
> > note.
> >  
> > I'm looking for assistance with an issue I'm having in RH8
> > and the Redhat supplied freetype rpms. 
> > versions I've tried are the stock 2.1.2-7 and the 2.1.2-12
> > rpms from the current phoebe beta. 
> > 
> > I am running the enlightenment window manager and have been testing
> > several of the e cvs packages for the upcoming e17 release. Some of 
> > the supplied ttf files in e cvs refuse to render properly using the 
> > Redhat freetype rpms. If I remove my 2.1.2 rpms and install 2.0.9 from
> > tar.gz then everything works fine. 
> > Fonts that don't want to work right include andover.ttf, morpheus.ttf,
> > borzoib.ttf and others
> > 
> > I have tracked the issue down to a problem with cmap detection.
> > The issues I am seeing with these fonts are exactly the same as
> > discussed in the following email at the end of this note. 
> > 
> > Can anyone confirm if this is still a known issue with 2.1.2* freetype
> > or if there is a patch out there that I would need to apply to 
> > the RH src.rpm and rebuild it. 
> > 
> > Thanks Phil
> > 
> > <snip>----
> > 
> >     * To: address@hidden
> >     * Subject: Re: FreeType 2.1.2's cmap detection broken?
> >     * From: Anthony Fok <address@hidden>
> >     * Date: Fri, 9 Aug 2002 18:38:49 +0800
> >     * Cc: address@hidden
> >     * In-reply-to: <address@hidden>
> >     * References: <address@hidden> <address@hidden>
> >     * User-agent: Mutt/1.4i
> > 
> > Hello David and all,
> > 
> > About a month ago, a user/developer reported here that opens___.ttf
> > could no longer be displayed in OpenOffice.org.  Since then, there have
> > been similar reports by different Debian users reporting problems since
> > the upgrade from libfreetype6-2.0.9 to 2.1.x.  And then yesterday
> > Guillermo Perez noticed that ftdump1 shows more cmaps than ftdump2
> > does.
> > 
> > With that, it appears that a real bug may have crept in between 2.0.9
> > and 2.1.0+.  With opens___.ttf font, ftdump from FreeType pre-1.4 reports:
> > 
> >   encoding  0: Apple Unicode 
> >   encoding  1: Apple Roman
> >   encoding  2: Windows Unicode
> > 
> > ftdump from FreeType 2.0.9 reports:
> > 
> >   charmaps
> >      0: platform: 0, encoding: 0
> >      1: platform: 1, encoding: 0
> >      2: platform: 3, encoding: 1
> > 
> > fonttools reports:
> > 
> >     <cmap_format_4 platformID="0" platEncID="0" version="0">
> >     <cmap_format_6 platformID="1" platEncID="0" version="0">
> >     <cmap_format_4 platformID="3" platEncID="1" version="0">
> > 
> > ftdump from FreeType 2.1.2 (with CVS as of 2002-08-06) reports:
> > 
> >   charmaps
> >      0: platform: 1, encoding: 0   <--- Only one left!?!
> > 
> > Apparently, this is the cause of a recent font display problem for
> > e.g. some OpenOffice.org and pango users.
> > http://www.usta.de/RefAk/Aussen/almonte.ttf is another font that triggers
> > the symptom.
> > 
> > For more information, please check:
> > 
> >     freetype regression: some ttf fonts don't display anymore
> >         http://bugs.debian.org/150678
> > 
> >     some fonts are not rendered because their enconding are not well 
> > detected
> >   http://bugs.debian.org/155864
> > 
> > Many thanks,
> > 
> > Anthony
> 
> -- 
> Anthony Fok Tung-Ling
> ThizLinux Laboratory   <address@hidden> http://www.thizlinux.com/
> Debian Chinese Project <address@hidden>       http://www.debian.org/intl/zh/
> Come visit Our Lady of Victory Camp!           http://www.olvc.ab.ca/

> ===================================================================
> RCS file: /home/freetype/cvs/cvs/freetype/freetype2/src/sfnt/ttcmap0.c,v
> retrieving revision 1.21
> retrieving revision 1.22
> diff -u -r1.21 -r1.22
> --- freetype2/src/sfnt/ttcmap0.c      2002/08/27 20:20:27     1.21
> +++ freetype2/src/sfnt/ttcmap0.c      2002/09/24 23:39:58     1.22
> @@ -579,6 +579,12 @@
>    /* Otherwise, a glyph index is taken from the glyph ids sub-array for    */
>    /* the segment, and the value of `idDelta' is added to it.               */
>    /*                                                                       */
> +  /*                                                                       */
> +  /* Finally, note that certain fonts contain invalid charmaps that        */
> +  /* contain end=0xFFFF, start=0xFFFF, delta=0x0001, offset=0xFFFF at the  */
> +  /* of their charmaps (e.g. opens___.ttf which comes with OpenOffice.org) */
> +  /* we need special code to deal with them correctly...                   */
> +  /*                                                                       */
>  
>  #ifdef TT_CONFIG_CMAP_FORMAT_4
>  
> @@ -680,7 +686,7 @@
>              FT_INVALID_DATA;
>          }
>  
> -        if ( offset )
> +        if ( offset && offset != 0xFFFFU )
>          {
>            p += offset;  /* start of glyph id array */
>  
> @@ -692,10 +698,10 @@
>            /* check glyph indices within the segment range */
>            if ( valid->level >= FT_VALIDATE_TIGHT )
>            {
> -            FT_UInt  idx;
> +            FT_UInt  i, idx;
>  
>  
> -            for ( ; start < end; )
> +            for ( i = start; i < end; i++ )
>              {
>                idx = FT_NEXT_USHORT( p );
>                if ( idx != 0 )
> @@ -708,6 +714,16 @@
>              }
>            }
>          }
> +        else if ( offset == 0xFFFFU )
> +        {
> +          /* Some fonts (erroneously?) use a range offset of 0xFFFF */
> +          /* to mean missing glyph in cmap table                    */
> +          /*                                                        */
> +          if ( valid->level >= FT_VALIDATE_PARANOID                     ||
> +               n != num_segs - 1                                        ||
> +               !( start == 0xFFFFU && end == 0xFFFFU && delta == 0x1U ) )
> +            FT_INVALID_DATA;
> +        }
>  
>          last = end;
>        }
> @@ -769,6 +785,9 @@
>              p += num_segs2;
>              offset = TT_PEEK_USHORT( p );
>  
> +            if ( offset == 0xFFFFU )
> +              goto Exit;
> +
>              if ( offset != 0 )
>              {
>                p  += offset + 2 * ( idx - start );
> @@ -813,6 +832,9 @@
>              p += num_segs2;
>              offset = TT_PEEK_USHORT( p );
>  
> +            if ( offset == 0xFFFFU )
> +              goto Exit;
> +
>              if ( offset != 0 )
>              {
>                p  += offset + 2 * ( idx - start );
> @@ -879,7 +901,7 @@
>            p += num_segs2;
>            offset = TT_PEEK_USHORT( p );
>  
> -          if ( offset != 0 )
> +          if ( offset != 0 && offset != 0xFFFFU )
>            {
>              /* parse the glyph ids array for non-0 index */
>              p += offset + ( code - start ) * 2;
> @@ -894,6 +916,12 @@
>                }
>                code++;
>              }
> +          }
> +          else if ( offset == 0xFFFFU )
> +          {
> +            /* an offset of 0xFFFF means an empty glyph in certain fonts !! 
> */
> +            code = end;
> +            break;
>            }
>            else
>              gindex = (FT_UInt)( code + delta ) & 0xFFFFU;