>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 <[email protected]> To: Werner LEMBERG <[email protected]> Cc: "[email protected]" <[email protected]> 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 <[email protected]> To: [email protected] Cc: [email protected] 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 [email protected] https://lists.nongnu.org/mailman/listinfo/freetype _______________________________________________ Freetype mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype
