[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] internal differences between 2.1.10 and current CVS

From: Chia-I Wu
Subject: Re: [ft-devel] internal differences between 2.1.10 and current CVS
Date: Thu, 16 Feb 2006 04:09:37 +0800
User-agent: Mutt/1.5.11

On Wed, Feb 15, 2006 at 02:31:16PM +0100, david turner wrote:
> internal/ftdriver.h:
>  FT_Size_ResetPointsFunc and FT_Size_ResetPixelsFunc are replaced
>  by FT_Size_RequestFunc and FT_Size_SelectFunc, which have different
>  signatures and usage. This impacts some fields in FT_Driver_ClassRec,
>  namely:
>    'set_char_sizes'  => 'request_size'
>    'set_pixel_sizes' => 'select_size'
>  the layout of other fields is untouched
The chance that rogue clients use them is low.  I suggest not fixing
> internal/ftobjs.h:
>  two new fields at the start of FT_Face_InternalRec, named
>  'max_points' and 'max_contours'
They are removed by me yesterday.  I've added them back and renamed them
to `reserved1' and `reserved2'.
>  FT_New_Memory was FT_EXPORT and is now FT_BASE, i.e. no longer
>  exported
>  same for FT_Done_Memory !
> internal/ftstream.h:
>  FT_Stream_Open was FT_EXPORT and is now FT_BASE
They were labeled wrongly.  No special care needed.
> internal/psaux.h:
>  PSAux_ServiceRec has a new field added in its middle, named
>  'afm_parser_funcs'.
>  obvious solution: move it to the end of the structure
> internal/sfnt.h:
>  **VERY BAD**
>  changes here have been extremely drastic, more details will follow
>  but we need to be very careful. The types defined here are *very*
>  likely to be used by rogue clients
After re-ordering the members of SFNT_Interface, the problems are
restricted to:

1) load_sfnt_header => tt_face_load_font_dir
   load_directory   => tt_face_load_hmtx
   load_metrics     => tt_face_load_hhea 
Functional-wise, the first two functions on the left are equal to the
first function on the right.  The third function on the left is equal to
the last two functions on the right.

I've cooked a patch for a possible solution.  With it, freetype should
never crash.  Depending on how rogue clients call the functions, they
are mostly like to get zero width and zero advance later in
`get_metrics' when FT_OPTIMIZE_MEMORY is defined, or get error in
`tt_face_load_hmtx' when not.

(if we let `tt_face_load_hhea' call `tt_face_load_hmtx', everything
 will work as well as before, but I don't like it :-)

2) set_sbit_strike changed.
the second parameter was x_ppem and is a size request (a pointer).
If there is a reliable way to distinguish a interger and a pointer, say,
rogue clients never call `set_sbit_strike' with x_ppem >= 0x1000 and a
pointer always points to somewhere >= 0x1000, we can tell who is calling
this function and return error when the rogue clients call it.

> internal/tttypes.h:
>  a new field named 'max_components' was added in the middle of
>  TT_FaceRec => move it to the end of the structure
It was removed by me yesterday.  I've added it back and renamed it to
>  when FT_OPTIMIZE_MEMORY is defined, this adds new fields within
>  the structure => move them to the end as well
>  same for TT_CONFIG_OPTION_BDF and 'bdf' field


reply via email to

[Prev in Thread] Current Thread [Next in Thread]