Jonathan Shieh | 1 Nov 2002 02:28
Picon
Favicon

FT_New_Face load time?

Hi all,
  I'm having some trouble with the amount of time
FT_New_Face takes to load a face.

Loading 3 different truetype fonts, one for English,
one for Chinese, and one for Korean, I get the
following results.

The font fonts/tahoma.ttf has:
        2022 glyphs
        loaded in 0.095378 seconds
The font fonts/mingliu.ttc has:
        22753 glyphs
        loaded in 0.166180 seconds
The font fonts/gulim.ttc has:
        40194 glyphs
        loaded in 27.917919 seconds

The displayed time is the approximate time it took to
call FT_New_Face like so:

error = FT_New_Face( library,
	realFilename,
	0,
	&face );

Note the long load time of gulim.ttc.  Why does it
take so long to just load the font?  And more
importantly, is there a way to shorten the load time?

(Continue reading)

Pedriana, Paul | 1 Nov 2002 02:29
Picon

Freetype is very slow at opening large Postscript Asian fonts...

Freetype is very slow at opening large PostScript Asian fonts. I have a font with 8000 characters in it and Freetype takes upwards of 20 seconds just to return from FT_New_Face() on a PIII 1GHz PC. The time is compounded by the fact that I have to do this multiple times for different fonts and variations. I traced the slowness and it comes down to the PS_Table_Add function. In particular, these lines of code:
   while ( new_size < table->cursor + length )
     new_size += 1024;
   error = reallocate_t1_table( table, new_size );
 
The problem is that with large fonts, this reallocation can happen thousands of times. I tried changing the code to use new_size *= 2 instead of new_size += 1024 and the FT_NewFace() function now goes about 10 times as fast. It would be even faster if the reallocation code didn't do all those tests and instead the caller of PS_Table_Add allocated the required amount up front. I'm not sure what the best solution is, but I tend to think that new_size += 1024 is not it. Doing *= 2 and then scaling the allocation back to minimum when done is one way to get the speed but not use any extra memory.
 
Until I hear back from somebody, I'll just change my version of the code to new_size *= 2 so I can stop getting bug reports that my app has hung. :)
 
The code below is from Freetype 2.12 (the most recent as of this writing).
  /*************************************************************************/
  /*                                                                       */
  /* <Function>                                                            */
  /*    PS_Table_Add                                                       */
  /*                                                                       */
  /* <Description>                                                         */
  /*    Adds an object to a PS_Table, possibly growing its memory block.   */
  /*                                                                       */
  /* <InOut>                                                               */
  /*    table  :: The target table.                                        */
  /*                                                                       */
  /* <Input>                                                               */
  /*    idx  :: The index of the object in the table.                      */
  /*                                                                       */
  /*    object :: The address of the object to copy in memory.             */
  /*                                                                       */
  /*    length :: The length in bytes of the source object.                */
  /*                                                                       */
  /* <Return>                                                              */
  /*    FreeType error code.  0 means success.  An error is returned if a  */
  /*    reallocation fails.                                                */
  /*                                                                       */
  FT_LOCAL_DEF( FT_Error )
  PS_Table_Add( PS_Table  table,
                FT_Int    idx,
                void*     object,
                FT_Int    length )
  {
    if ( idx < 0 || idx > table->max_elems )
    {
      FT_ERROR(( "PS_Table_Add: invalid index\n" ));
      return PSaux_Err_Invalid_Argument;
    }    /* grow the base block if needed */
    if ( table->cursor + length > table->capacity )
    {
      FT_Error   error;
      FT_Offset  new_size  = table->capacity;
      FT_Long    in_offset;
      in_offset = (FT_Long)((FT_Byte*)object - table->block);
      if ( (FT_ULong)in_offset >= table->capacity )
        in_offset = -1;      while ( new_size < table->cursor + length )
        new_size += 1024;      error = reallocate_t1_table( table, new_size );
      if ( error )
        return error;      if ( in_offset >= 0 )
        object = table->block + in_offset;
    }    /* add the object to the base block and adjust offset */
    table->elements[idx] = table->block + table->cursor;
    table->lengths [idx] = length;
    FT_MEM_COPY( table->block + table->cursor, object, length );    table->cursor += length;
    return PSaux_Err_Ok;
  }
   
Pedriana, Paul | 1 Nov 2002 02:33
Picon

RE: FT_New_Face load time?

Christ, what are the chances that two people came across 
the same issue in Freetype within minutes of each other?!

Coincidentally, Gulim is also one of the fonts that I am 
getting slammed by. On the other hand, my problem is with
PostScript fonts and not TrueType fonts; but for all I know,
the problem I reported is caused by the same thing under 
TrueType.

Paul

-----Original Message-----
From: Jonathan Shieh [mailto:jonshieh <at> yahoo.com] 
Sent: Thursday, October 31, 2002 5:29 PM
To: freetype <at> freetype.org
Subject: [Freetype] FT_New_Face load time?

Hi all,
  I'm having some trouble with the amount of time
FT_New_Face takes to load a face.

Loading 3 different truetype fonts, one for English,
one for Chinese, and one for Korean, I get the
following results.

The font fonts/tahoma.ttf has:
        2022 glyphs
        loaded in 0.095378 seconds
The font fonts/mingliu.ttc has:
        22753 glyphs
        loaded in 0.166180 seconds
The font fonts/gulim.ttc has:
        40194 glyphs
        loaded in 27.917919 seconds

The displayed time is the approximate time it took to
call FT_New_Face like so:

error = FT_New_Face( library,
	realFilename,
	0,
	&face );

Note the long load time of gulim.ttc.  Why does it
take so long to just load the font?  And more
importantly, is there a way to shorten the load time?

Thanks,

Jonathan
Pedriana, Paul | 1 Nov 2002 06:20
Picon

More FreeType PostScript problems...

I have a PostScript font generated by FontLab which looks fine drawn by
Windows, but yields screwy values with FreeType 2.0. I call the code below
and get (overly small) results like this:
    yMax      =  7
    yMin      = -3
    height    = 13
    ascender  =  7
    descender = -3
 
And then the font bitmaps end up being much larger than the above and
the text overwrites itself vertically when drawn in a multi-line text display.
This same font generated as TrueType has no problems. Am I missing
something or is Freetype 2.0 confused about how to calculate PostScript
bbox data?
 
Here is the code I execute:  
   FT_Set_Pixel_Sizes(pFreeTypeData->face, 34, 34);
 
   const int yMaxEM               = pFreeTypeData->face->bbox.yMax;
  const int yMaxFixedPoint26_6   = FT_MulFix(yMaxEM, pFreeTypeData->face->size->metrics.y_scale);
    const int yMax                 = yMaxFixedPoint26_6 / 64;
 
   const int yMinEM               = pFreeTypeData->face->bbox.yMin;
   const int yMinFixedPoint26_6   = FT_MulFix(yMinEM, pFreeTypeData->face->size->metrics.y_scale);
   const int yMin                 = yMinFixedPoint26_6 / 64;
 
   const int heightEM             = pFreeTypeData->face->height;
   const int heightFixedPoint26_6 = FT_MulFix(heightEM, pFreeTypeData->face->size->metrics.y_scale);
   const int height               = heightFixedPoint26_6/64;
 
   const int ascenderEM           = pFreeTypeData->face->ascender;
   const int ascender26_6         = FT_MulFix(ascenderEM, pFreeTypeData->face->size->metrics.y_scale);
   const int ascender             = ascender26_6/64;
 
   const int descenderEM          = pFreeTypeData->face->descender;
   const int descender26_6        = FT_MulFix(descenderEM, pFreeTypeData->face->size->metrics.y_scale);
   const int descender            = descender26_6/64;
Paul
 
 
 
 
 
 
 
 
 
Aaron Isaksen | 1 Nov 2002 16:02

RE: More FreeType PostScript problems...

I've found that using the "Recalculate" buttons in the font properties metrics section fixes this sort of problem for me.
 
-Aaron
-----Original Message-----
From: Pedriana, Paul [mailto:PPedriana <at> maxis.com]
Sent: Friday, November 01, 2002 12:21 AM
To: freetype <at> freetype.org
Subject: [Freetype] More FreeType PostScript problems...

I have a PostScript font generated by FontLab which looks fine drawn by
Windows, but yields screwy values with FreeType 2.0. I call the code below
and get (overly small) results like this:
    yMax      =  7
    yMin      = -3
    height    = 13
    ascender  =  7
    descender = -3
 
And then the font bitmaps end up being much larger than the above and
the text overwrites itself vertically when drawn in a multi-line text display.
This same font generated as TrueType has no problems. Am I missing
something or is Freetype 2.0 confused about how to calculate PostScript
bbox data?
 
Here is the code I execute:  
   FT_Set_Pixel_Sizes(pFreeTypeData->face, 34, 34);
 
   const int yMaxEM               = pFreeTypeData->face->bbox.yMax;
  const int yMaxFixedPoint26_6   = FT_MulFix(yMaxEM, pFreeTypeData->face->size->metrics.y_scale);
    const int yMax                 = yMaxFixedPoint26_6 / 64;
 
   const int yMinEM               = pFreeTypeData->face->bbox.yMin;
   const int yMinFixedPoint26_6   = FT_MulFix(yMinEM, pFreeTypeData->face->size->metrics.y_scale);
   const int yMin                 = yMinFixedPoint26_6 / 64;
 
   const int heightEM             = pFreeTypeData->face->height;
   const int heightFixedPoint26_6 = FT_MulFix(heightEM, pFreeTypeData->face->size->metrics.y_scale);
   const int height               = heightFixedPoint26_6/64;
 
   const int ascenderEM           = pFreeTypeData->face->ascender;
   const int ascender26_6         = FT_MulFix(ascenderEM, pFreeTypeData->face->size->metrics.y_scale);
   const int ascender             = ascender26_6/64;
 
   const int descenderEM          = pFreeTypeData->face->descender;
   const int descender26_6        = FT_MulFix(descenderEM, pFreeTypeData->face->size->metrics.y_scale);
   const int descender            = descender26_6/64;
Paul
 
 
 
 
 
 
 
 
 
Ryan Martindale | 1 Nov 2002 16:31

Re: Freetype is very slow at opening large Postscript Asian fonts...

"Pedriana, Paul" wrote:

> Until I hear back from somebody, I'll just change my version of the
> code to new_size *= 2 so I can stop getting bug reports that my app
> has hung. :)

The *2 for an embedded system with limited memory probably isn't the
best solution, unless you add some kind of scaleback factor for cases
where you can't get that much memory (and possibly introduce a maximum
increase size).

Just my 2 cents.

Ryan
Antoine Leca | 1 Nov 2002 22:50

Re: Licence issues

Thibault Jamme wrote:
> 
> I want to release my project http://www.aptilis.com/ under the GPL 
> licence, but I saw that Freetype 1 (the one I'm using) is covered by the 
> BSD licencing scheme which appears incompatible.
> 
> Does anyone know what the implications are? How to address them?

Use the "unstable" (alias the one from the CVS, or the one from the
devel tree), which is a pre-release of 1.5 (not yet issued, but you
should not have any problem. If you experiment some of them, please
report ASAP). This version is (will be) issued with the same dual-
license model as is Freetype 2.

Also note that to be anything useful, you should be in one of the
following 3 cases:

  a) you operate only at _very_ large ppem, and do not worry about hints;

  b) you, and all your clients (beware with a GNU license), do not have
   any problem related with the Apple patents;

  c) you, and all your clients (beware with a GNU license), have an Apple
   license.

If any don't, then you are potentially affected by the patents problem.
I can only ask you to set _very_proeminent_disclaimers_ about this
problem. I believe you can freely link (in the main directory of your
project) the patents page, www.freetype.org/patents.html, I do not
believe it will go away any time soon ;-). BTW, the French version,
www.freetype.org/patents-fr.html, is slightly out of sync.

Regards,

Antoine
Juliusz Chroboczek | 4 Nov 2002 11:43
Picon

Re: Freetype is very slow at opening large Postscript Asian fonts...

PP> Until I hear back from somebody, I'll just change my version of the code
PP> to new_size *= 2 so I can stop getting bug reports that my app has hung.

I would like to suggest new_size becomes new_size * 5/4 rounded up to
the next multiple of 1024.  This will have good behaviour for small
fonts (by going up by 1KB for small tables that are beneath 4KB) while
at the same time providing the exponential behaviour that you're after.

                                        Juliusz
Eric Nickell | 4 Nov 2002 22:05
Favicon

Compact format fonts

I've just started poking around a little at Freetype, mostly as a way to
decode cff fonts embedded in pdf documents. When I run the following
code, the type 1 font tests out fine (as far as opening it), but the cff
font does not.  Any suggestions on what I'm doing wrong?

Attached is the cff file I'm trying to read, and below are excerts of
our test code trying to open it.

Eric

#include <stdio.h>
#include <freetype.h>

void TestNewFace();

char *testFiles[] = {
	"garamond-lightitalic.psf",
	"ANBAIB+Times-Italic.cff",
};

#define N_TESTFILES	2

main()
{
  TestNewFace();
}

void
DieFtError(char *s, FT_Error error)
{
  printf("%s %d\n", s, error);
  exit(error);
}

void
AssertNoFTError(FT_Error error, char *s)
{
  if (error != 0)
    DieFtError(s, error);
}

FT_Library
GetLibrary()
{
  FT_Library library;
  FT_Error error;

  AssertNoFTError(FT_Init_FreeType(&library), "FT_Init_FreeType");
  return library;
}

void
TestNewFace()
{
  FT_Library library;
  FT_Face face;
  int i;

  library = GetLibrary();
  for (i = 0; i <  N_TESTFILES; i++) {
    AssertNoFTError(FT_New_Face(library, testFiles[i], 0, &face),
testFiles[i]);
  }
}

Attachment (ANBAIB+Times-Italic.cff): application/octet-stream, 3317 bytes
Pedriana, Paul | 5 Nov 2002 05:44
Picon

RE: Freetype is very slow at opening large Postscript Asian fonts...

So the new loop withing PS_Table_Add (from psobjs.c) could look like
this:

   FT_Error  PS_Table_Add( PS_Table*  table,
                           FT_Int     index,
                           void*      object,
                           FT_Int     length )
   {
      .
      .
      .
      while ( new_size < table->cursor + length )
      {
         /* Increase size by 25% and then round up to */
         /* nearest multiple of 1024.                 */
         new_size = new_size * 5 / 4;
         new_size = (new_size + 1023) & -1024;
      }
      .
      .
      .
   }

Paul

-----Original Message-----
From: Juliusz Chroboczek [mailto:jch <at> pps.jussieu.fr] 
Sent: Monday, November 04, 2002 2:44 AM
To: freetype <at> freetype.org
Subject: Re: [Freetype] Freetype is very slow at opening large
Postscript Asian fonts...

PP> Until I hear back from somebody, I'll just change my version of the 
PP> code to new_size *= 2 so I can stop getting bug reports that my app 
PP> has hung.

I would like to suggest new_size becomes new_size * 5/4 rounded up to
the next multiple of 1024.  This will have good behaviour for small
fonts (by going up by 1KB for small tables that are beneath 4KB) while
at the same time providing the exponential behaviour that you're after.

                                        Juliusz

_______________________________________________
Freetype mailing list
Freetype <at> freetype.org http://www.freetype.org/mailman/listinfo/freetype

Gmane