Re: [Devel] Apple's 'gvar' table and friends

[David Turner]

Hi George,

George Williams wrote:

> On Sat, 2004-04-03 at 05:07, Werner LEMBERG wrote:
>
> > I agree that it doesn't look optimal.  What about FT_STREAM_POS,
> > FT_STREAM_SEEK, and FT_STREAM_SKIP?  Have a look into ftstream.[ch].
>
> Um, these don't work within a frame. I'm probably doing the wrong thing:
> I open the 'gvar' table (or whichever) as a frame, and try to seek
> around in it.
>
> FT_STREAM_POS tells me I'm always positioned at the end of the table.

That's perfectly normal. When you "enter" a frame, you actually "load"
the corresponding bytes into memoryé (of course, nothing really happens
if the stream is already memory-based), so the stream pointer is already
advanced.

You can however retrieve the frame pointer as stream->cursor, the
field stream->limit will give you the frame's limit in memory (i.e.
the first byte after the frame in memory). stream->cursor is updated
automatically by the FT_GET_... macros.

Notice that the intent of frames is to allow fast parsing without
sacrificing robustness. It's clearly a lot better to write:

  if ( FT_FRAME_ENTER( byte_size ) )
    goto ....;

  val1 = FT_GET_SHORT();
  val2 = FT_GET_SHORT();
  val3 = FT_GET_ULONG();

  FT_FRAME_EXIT()

instead of:

   if ( FT_READ_SHORT(val1) ||
        FT_READ_SHORT(val2) ||
        FT_READ_ULONG(val3) )
     goto ...

because you save a large number of error checks.

If you intend to parse the frame directly, just be sure to not go beyond
its limits accidently (it's something you might not notice on Linux, since
streams are mmaped by default on this platform, so over-reading a frame
really peeks the input file without generating an error when running
under a memory checker like valgrind !)

"exiting" the frame will usually free the corresponding memory block,
when one was allocating when "entering" it.

Hope this helps,

- David Turner
- The FreeType Project  (www.freetype.org)