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

[david turner]

Hello again,

following my recent message regarding internals and the safe installation
of the next FreeType release, I've performed the "big diff" to see what 
should
be taken care of.

See the details at the end of this message. It seems that this is going 
to be
rather easy, except for the changes in SFNT_ServiceRec which were quite 
drastic,
and which are very likely to be used by rogue clients.

Another point that is not listed, is that all functions that are listed as
FT_BASE are no longer exported by our build system.

I'll try to start fixing things tonight in the CVS. In the meantime, I'd be
happy to read your concerns and ideas.

Regards,

- David

--------------------------------------------------------------------------------
differences from the headers of FreeType 2.1.10 to current CVS.
All paths are relative to include/freetype:

cache/ftccache.h:
 'ftc_node_destroy' was renamed to 'FTC_Node_Destroy'

cache/ftheader.h:
  FT_GX_VALIDATE_H was added
 
config/ftoption.h:
  TT_CONFIG_OPTION_BDF added
  AF_CONFIG_OPTION_CJK added
  FT_OPTIMIZE_MEMORY added
  FT_STRICT_ALIASING added

config/ftstdlib.h:
 ft_memchr added

freetype.h:
 FT_FACE_FLAG_HINTER added
 FT_Size_Request_Type, FT_Size_Request, FT_Request_Size, FT_Select_Size 
added
 FT_Get_Track_Kerning added

internal/ftcalc.h:
 FT_Sqrt32 removed

internal/ftdebug.h:
 FT_Trace_Get_Count, FT_Trace_Get_Name, FT_Message and FT_Panic were
 FT_EXPORT() and are now FT_BASE() and thus no longer exported

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

internal/ftgloader.h:
 new macros were introduced, no impact on rogue clients

internal/ftmemory.h:
 the signature of FT_Alloc, FT_QAlloc, FT_Realloc, FT_QRealloc
 and FT_Free is changed when FT_STRICT_ALIASING is defined in
 config/ftoption.h !

 best solution: rename the functions (e.g. ft_mem_alloc, ft_mem_qalloc, 
etc..)
 and provide stubs with the old names (e.g. "FT_Alloc", "FT_QAlloc") that
 implement the old signature

internal/ftobjs.h:
 two new fields at the start of FT_Face_InternalRec, named
 'max_points' and 'max_contours'

 obvious solution: move them to the end of the structure

 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

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/services/svpscmap.h:
 IMPORTANT NOTE: The probability that a rogue client uses this header
                 file is _extremely_ low !!

 the 'unicode' field of PS_UniMap changed from FT_UInt to FT_UInt32
 (shouldn't be a problem on Unix)

 PS_UnicodesRec has a new starting field => since this is a
 FT_CMapRec, is it possible to move it to the end of the structure
 safely ??

 PS_Unicodes_InitFunc changed its signature -> impact on the
 'unicodes_init' field of PsCMaps service 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

 **MORE DETAILS LATER**
                      
                      
internal/t1types.h:
 the 'unicode_map' field of T1_FaceRec was a pointer, and is now
 a structure, moving all fields below it.

 => revert the field to a pointer, even if it is to a structure
    located to the end of T1_FaceRec instead

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

 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

     
 



***********************************************************************************
Information contained in this email message is confidential and may be 
privileged, and is intended only for use of the individual or entity named 
above. If the reader of this message is not the intended recipient, or the 
employee or agent responsible to deliver it to the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please immediately notify the address@hidden and destroy the original 
message.
***********************************************************************************