Also use a common pool for all nul-content ones.

Detect TrueType Collections by checking the font data header instead
of checking for "face->num_faces >1".

2009-01-31  Behdad Esfahbod  <behdad@gnome.org>

        * pango/opentype/harfbuzz-gpos.c (Load_Mark2Array),
        (Free_Mark2Array):
        Allocate all array rows in a single ALLOC call.  Saves over 100
        alloc calls when loading DejaVu Sans,

2009-01-29  Behdad Esfahbod  <behdad@gnome.org>

        * pango/opentype/harfbuzz-open.h:
        * pango/opentype/harfbuzz-gdef.c (Make_ClassRange),
        (HB_GDEF_Build_ClassDefinition):
        * pango/opentype/harfbuzz-gpos.c (Load_PosClassRule),
        (Load_ChainPosClassRule):
        * pango/opentype/harfbuzz-gsub.c (Load_SubClassRule),
        (Load_ChainSubClassRule):
        * pango/opentype/harfbuzz-open.c (Load_ClassDef1),
        (Load_ClassDef2), (_HB_OPEN_Load_ClassDefinition),
        (_HB_OPEN_Load_EmptyClassDefinition),
        (_HB_OPEN_Free_ClassDefinition):
        Remove ClassDef->Defined field.  This is the comment accompanying it:

          The `Defined' field is not defined in the OpenType specification
          but apparently needed for processing fonts like trado.ttf: This
          font refers to a class which contains not a single element.  We
          map such classes to class 0.

        The comment is correct that trado.ttf (MS Traditional Arabic) uses
        such classes.  However, in my testing I couldn't identify any
        problems with the font if the special handling is removed.  I also
        processed as many fonts as I could get my hand on and trado.ttf was
        the only not-totally-broken font hitting the special-case code.
        DejaVu fonts hit it too, but I'm sure they do not require the
        special-handling code.  Most probably, that code introduces bugs
        in them.

        The special-casing was consuming lots of memory.  EIGHT MEGABYTES
        for loading DejaVu Sans!  While this could be complete fixed, I
        decided to remove the special-handling code altogether.  I don't
        think it will make any real difference, and if it does, we'll fix
        fonts.  Such hacks will not be in harfbuzz-ng anyway.

        Bug originally reported by nsf.

2009-01-29  Behdad Esfahbod  <behdad@gnome.org>

        * pango/opentype/harfbuzz-impl.c (_hb_alloc): Use calloc(),
        instead of malloc()ing and memset()ing.

2009-01-29  Behdad Esfahbod  <behdad@gnome.org>

        * pango/opentype/harfbuzz-dump-main.c (main): Remove old cruft.

2009-01-29  Behdad Esfahbod  <behdad@gnome.org>

        * pango/opentype/harfbuzz-gpos.c (Load_BaseArray), (Free_BaseArray):
        Allocate all array rows in a single ALLOC call.  Saves over 2000
        alloc calls when loading DejaVu Sans!

2008-12-25  Behdad Esfahbod  <behdad@gnome.org>

        Bug 469049 – Fix all compiler warnings

        * pango-view/viewer-pangocairo.c (render_callback):
        * pango/fonts.c (append_field), (pango_font_description_to_string):
        * pango/opentype/harfbuzz-dump.c:
        * pango/pango-bidi-type.c (pango_log2vis_get_embedding_levels):
        * pango/pango-coverage.c (pango_coverage_set):
        * pango/pango-markup.c (span_parse_func):
        * pango/pango-renderer.c
        (pango_renderer_default_draw_error_underline):
        * pango/pango-utils.c (pango_scan_string):
        * pango/pangocairo-render.c (pango_cairo_renderer_draw_trapezoid),
        (draw_error_underline), (pango_cairo_renderer_class_init):
        Fix all the remaining warnings.