Re: [ft] Help finding glyphs in TTF files

[Michael Franklin]

>On my Windows 8 computer, name table entry #47 looks like this:
>01 00 00 00 00 00 08 00 03 00 E5 01 01 00 00 00 00 00 00 00
>
>On my ARM device, name table entry #47 looks like this:
>01 00 00 00 08 00 03 00 E5 01 00 00 01 00 00 00 00 00 00 00

I should add that name table entries 54 through 48 identical, but after 48, 
it's all over.


Mike



----- Original Message -----
From: Michael Franklin <address@hidden>
To: Werner LEMBERG <address@hidden>
Cc: "address@hidden" <address@hidden>
Sent: Tuesday, April 2, 2013 1:11 PM
Subject: Re: [ft] Help finding glyphs in TTF files

OK, I think I'm on the verge of figuring this out, but I'll need help from 
someone who's familiar with this library and gcc.  Please don't leave me 
hanging.

I've narrowed down the problem to the name table.  I've put the following trace 
in function tt_face_load_name in ttload.c to print out the name table entries:

for ( ; count > 0; count-- )
{
  printf("%d::\r\n", count);
  if ( FT_STREAM_READ_FIELDS( name_record_fields, entry ) )
    continue;


  for(i = 0; i < sizeof(TT_NameEntryRec); i++)
  {
      printf("%02X ", ((char*)entry)[i]);
  }
  printf("\r\n");

On my Windows 8 computer, name table entry #47 looks like this:
01 00 00 00 00 00 08 00 03 00 E5 01 01 00 00 00 00 00 00 00

On my ARM device, name table entry #47 looks like this:
01 00 00 00 08 00 03 00 E5 01 00 00 01 00 00 00 00 00 00 00

So, you can see somewhere between the first byte 0 (0x01) and byte 6 (0x08)  
two 0x00's were lost.  After that all data is out of sync.

Is there some alignment or packing attributes I need to add to FreeType to make 
this code portable to my ARM Cortex-M4?

Thanks for any help,
Mike





----- Original Message -----
From: Werner LEMBERG <address@hidden>
To: address@hidden
Cc: address@hidden
Sent: Monday, April 1, 2013 9:58 PM
Subject: Re: [ft] Help finding glyphs in TTF files


> To make a long story short face->cmap_table is pointing to the wrong
> stuff.

Weird.

> Should base->stream advance by the same number of bytes on both
> platforms?

Yes, I think so.  I'm not aware of a single part in FreeType where we
have a different behaviour depending on the platform (except specific
code like the stuff in ftdebug, of course).

> It appears base->stream is set in FT_QMALLOC.  I'm wondering if
> something's wrong with my ARM platform's malloc.  I'm using the
> newlib C library.

Interesting.  On the other hand, it looks implausible that noone has
experienced similar problems with newlib's malloc function...  Maybe
there is a bad cast somewhere in the FreeType code.

Any chance to try a different malloc implementation?  You might also
activate FreeType's memory debugger (see `docs/DEBUG') for additional
diagnostics.


    Werner


_______________________________________________
Freetype mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/freetype