Re: [Devel] bugfix and improvement for Macintosh sfnt load!

[Leonard Rosenthol]

At 10:41 AM 3/21/2002 +0100, Martin Muskens wrote:
> in ftmac the routine FT_New_Face_From_SFNT contains a bug.

        I would say that it's not necessarily a bug, but you do have an 
interesting suggestion...


> The line
>                 sfnt = GetResource( 'sfnt', sfnt_id );
> loads the sftt in memory, but because it is a handle (Mac handle) this 
> memory can be "unloaded" by the OS.

        True, but unlikely.  We should probably do an HNoPurge() on it to 
be safe.


> What's also a problem with large files, is that sfnt and sfnt_data after 
> the line
>                 ALLOC( sfnt_data, (FT_Long)sfnt_size )
> both are (large) blocks of memory that both contain ( after the memcpy) 
> the same data.

        True.


> Here is my proposal for the new routine:

        And my comments on same...


>     SetResLoad (false); // tell the resource manager not to load the data 
> in memory ( *sfnt stays 0x00000000 )
>     sfnt = GetResource( 'sfnt', sfnt_id );
>     SetResLoad (true);// tell the resource manager to load resources 
> normal again.

        You actually should be doing a GetResLoad() to get the current 
value and then restoring it.



>         sfnt_size = GetResourceSizeOnDisk( sfnt ); // get the resource 
> size from disk ( = also more accurate than GetHandleSize )

        This API call, however, is relatively new (8.x or 9.x, I believe) 
and so we would now be limiting the OS level support for our library.  That 
may be a reasonable decision, but one that I am NOT willing to make lightly...

        I would be willing to conditionalize it for Carbon vs. non-Carbon 
builds, however.  Would that suffice for your needs??


>     ReadPartialResource(sfnt, 0, sfnt_data, sfnt_size );

        This call has a similar problem, although introduced in the System 
7.x timeframe it was COMPLETELY broken and wasn't fully fixed till at least 
8.x.


Leonard

---------------------------------------------------------------------------
Leonard Rosenthol                            <mailto:address@hidden>
Lazerware                                     <http://www.lazerware.com>