ReceiveTempSMS
/
Al-Qurtas-Islamic-bank-The-Best-Bank-in-Iraq
forked from minhngoc25a/freetype2
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
Al-Qurtas-Islamic-bank-The-.../builds/amiga/include/config/ftmodule.h

161 lines
4.4 KiB
C
Raw Normal View History

* builds/amiga/*: Added copyright notes, reworked some comments.
2005-06-08 13:56:55 +02:00
/***************************************************************************/
/* */
/* ftmodule.h */
/* */
/* Amiga-specific FreeType module selection. */
/* */
Run `src/tools/update-copyright'.
2015-01-17 20:41:43 +01:00
/* Copyright 2005-2015 by */
* builds/amiga/*: Added copyright notes, reworked some comments.
2005-06-08 13:56:55 +02:00
/* Werner Lemberg and Detlef W<>rkner. */
/* */
/* This file is part of the FreeType project, and may only be used, */
/* modified, and distributed under the terms of the FreeType project */
/* license, LICENSE.TXT. By continuing to use, modify, or distribute */
/* this file you indicate that you have read the license and */
/* understand and accept it fully. */
/* */
/***************************************************************************/
Initial revision
2001-09-20 13:58:51 +02:00
* builds/amiga/*: Added copyright notes, reworked some comments.
2005-06-08 13:56:55 +02:00
/*
* To avoid that all your programs include all FreeType modules,
* you copy the following piece of source code into your own
* source file and specify which modules you really need in your
* application by uncommenting the appropriate lines.
*/
Initial revision
2001-09-20 13:58:51 +02:00
/*
Update of the Amiga port. * builds/amiga/makefile, builds/amiga/smakefile: Handle new modules. * builds/amiga/makefile.os4: Makefile for AmigaOS4 SDK. * builds/amiga/README: Updated. * builds/amiga/include/freetype/config/ftconfig.h: Handle gcc for AmigaOS4. * builds/amiga/include/freetype/config/ftmodule.h: Handle new modules. * builds/amiga/src/base/ftdebug.c: Updated to current version of default ftdebug.c. Add various include files and macros to have proper support for both AmigaOS4 and older AmigaOS versions. Don't declare KVPrintF explicitly. Replace getenv with GetVar. Actually enable debugging code. * builds/amiga/src/base/ftsystem.c: Major rewrite.
2005-03-25 23:18:01 +01:00
//#define FT_USE_AUTOFIT // autofitter
//#define FT_USE_RASTER // monochrome rasterizer
//#define FT_USE_SMOOTH // anti-aliasing rasterizer
//#define FT_USE_TT // truetype font driver
//#define FT_USE_T1 // type1 font driver
//#define FT_USE_T42 // type42 font driver
//#define FT_USE_T1CID // cid-keyed type1 font driver // no cmap support
//#define FT_USE_CFF // opentype font driver
//#define FT_USE_BDF // bdf bitmap font driver
//#define FT_USE_PCF // pcf bitmap font driver
//#define FT_USE_PFR // pfr font driver
//#define FT_USE_WINFNT // windows .fnt|.fon bitmap font driver
//#define FT_USE_OTV // opentype validator
Added support for gxvalid module.
2005-11-17 15:19:30 +01:00
//#define FT_USE_GXV // truetype gx validator
Initial revision
2001-09-20 13:58:51 +02:00
#include "FT:src/base/ftinit.c"
*/
* builds/amiga/*: Added copyright notes, reworked some comments.
2005-06-08 13:56:55 +02:00
/* Make sure that the needed support modules are built in.
* Dependencies can be found by searching for FT_Get_Module.
*/
Initial revision
2001-09-20 13:58:51 +02:00
* builds/amiga/makefile, builds/amiga/smakefile, amiga/include/freetype/config/ftmodule.h: Updated to include support for BDF and Type42 drivers. * docs/modules.txt: Updated. * src/bdf/bdflib.c (_bdf_parse_glyphs): Replace floating point math with calls to `FT_MulDiv'.
2002-05-29 00:38:05 +02:00
#ifdef FT_USE_T42
#define FT_USE_TT
#endif
Initial revision
2001-09-20 13:58:51 +02:00
#ifdef FT_USE_TT
#define FT_USE_SFNT
#endif
#ifdef FT_USE_CFF
#define FT_USE_SFNT
* builds/amiga/*: Adaptations to latest changes. Support added for MorphOS. * src/pshinter/pshrec.c (FT_COMPONENT): Redefine to `trace_pshrec'. (ps_mask_table_merge, ps_hints_open, ps_hints_stem, ps_hints_t1stem3, ps_hints_t2mask, ps_hints_t2counter): Fix FT_ERROR messages. * src/pshinter/pshalgo1.c (FT_COMPONENT): Define as `trace_pshalgo1'. * src/pshinter/pshalgo2.c (FT_COMPONENT): Define as `trace_pshalgo2'. * include/freetype/internal/ftdebug.h (FT_Trace): Updated. * docs/modules.txt: New file.
2001-12-22 15:38:40 +01:00
#define FT_USE_PSHINT
#define FT_USE_PSNAMES
Initial revision
2001-09-20 13:58:51 +02:00
#endif
#ifdef FT_USE_T1
#define FT_USE_PSAUX
* builds/amiga/*: Adaptations to latest changes. Support added for MorphOS. * src/pshinter/pshrec.c (FT_COMPONENT): Redefine to `trace_pshrec'. (ps_mask_table_merge, ps_hints_open, ps_hints_stem, ps_hints_t1stem3, ps_hints_t2mask, ps_hints_t2counter): Fix FT_ERROR messages. * src/pshinter/pshalgo1.c (FT_COMPONENT): Define as `trace_pshalgo1'. * src/pshinter/pshalgo2.c (FT_COMPONENT): Define as `trace_pshalgo2'. * include/freetype/internal/ftdebug.h (FT_Trace): Updated. * docs/modules.txt: New file.
2001-12-22 15:38:40 +01:00
#define FT_USE_PSHINT
#define FT_USE_PSNAMES
Initial revision
2001-09-20 13:58:51 +02:00
#endif
#ifdef FT_USE_T1CID
#define FT_USE_PSAUX
* builds/amiga/*: Adaptations to latest changes. Support added for MorphOS. * src/pshinter/pshrec.c (FT_COMPONENT): Redefine to `trace_pshrec'. (ps_mask_table_merge, ps_hints_open, ps_hints_stem, ps_hints_t1stem3, ps_hints_t2mask, ps_hints_t2counter): Fix FT_ERROR messages. * src/pshinter/pshalgo1.c (FT_COMPONENT): Define as `trace_pshalgo1'. * src/pshinter/pshalgo2.c (FT_COMPONENT): Define as `trace_pshalgo2'. * include/freetype/internal/ftdebug.h (FT_Trace): Updated. * docs/modules.txt: New file.
2001-12-22 15:38:40 +01:00
#define FT_USE_PSHINT
#define FT_USE_PSNAMES
Initial revision
2001-09-20 13:58:51 +02:00
#endif
#ifdef FT_USE_PSAUX
#define FT_USE_PSNAMES
#endif
#ifdef FT_USE_SFNT
#define FT_USE_PSNAMES
#endif
* builds/amiga/*: Added copyright notes, reworked some comments.
2005-06-08 13:56:55 +02:00
/* Now include the modules */
Initial revision
2001-09-20 13:58:51 +02:00
Update of the Amiga port. * builds/amiga/makefile, builds/amiga/smakefile: Handle new modules. * builds/amiga/makefile.os4: Makefile for AmigaOS4 SDK. * builds/amiga/README: Updated. * builds/amiga/include/freetype/config/ftconfig.h: Handle gcc for AmigaOS4. * builds/amiga/include/freetype/config/ftmodule.h: Handle new modules. * builds/amiga/src/base/ftdebug.c: Updated to current version of default ftdebug.c. Add various include files and macros to have proper support for both AmigaOS4 and older AmigaOS versions. Don't declare KVPrintF explicitly. Replace getenv with GetVar. Actually enable debugging code. * builds/amiga/src/base/ftsystem.c: Major rewrite.
2005-03-25 23:18:01 +01:00
#ifdef FT_USE_AUTOFIT
FT_USE_MODULE declares things as: extern const FT_Module_Class (or similar for C++). However, the actual types of the variables being declared are often different, e.g., FT_Driver_ClassRec or FT_Renderer_Class. (Some are, indeed, FT_Module_Class.) This works with most C compilers (since those structs begin with an FT_Module_Class struct), but technically it's undefined behavior. To quote the ISO/IEC 9899:TC2 final committee draft, section 6.2.7 paragraph 2: All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined. (And they are not compatible types.) Most C compilers don't reject (or even detect!) code which has this issue, but the GCC LTO development branch compiler does. (It outputs the types of the objects while generating .o files, along with a bunch of other information, then compares them when doing the final link-time code generation pass.) Patch from Savannah bug #25133. * src/base/ftinit.c (FT_USE_MODULE): Include variable type. * builds/amiga/include/freetype/config/ftmodule.h, include/freetype/config/ftmodule.h, */module.mk: Updated to declare pass correct types to FT_USE_MODULE.
2008-12-21 11:29:30 +01:00
FT_USE_MODULE( FT_Module_Class, autofit_module_class )
Initial revision
2001-09-20 13:58:51 +02:00
#endif
Update of the Amiga port. * builds/amiga/makefile, builds/amiga/smakefile: Handle new modules. * builds/amiga/makefile.os4: Makefile for AmigaOS4 SDK. * builds/amiga/README: Updated. * builds/amiga/include/freetype/config/ftconfig.h: Handle gcc for AmigaOS4. * builds/amiga/include/freetype/config/ftmodule.h: Handle new modules. * builds/amiga/src/base/ftdebug.c: Updated to current version of default ftdebug.c. Add various include files and macros to have proper support for both AmigaOS4 and older AmigaOS versions. Don't declare KVPrintF explicitly. Replace getenv with GetVar. Actually enable debugging code. * builds/amiga/src/base/ftsystem.c: Major rewrite.
2005-03-25 23:18:01 +01:00
#ifdef FT_USE_TT
FT_USE_MODULE declares things as: extern const FT_Module_Class (or similar for C++). However, the actual types of the variables being declared are often different, e.g., FT_Driver_ClassRec or FT_Renderer_Class. (Some are, indeed, FT_Module_Class.) This works with most C compilers (since those structs begin with an FT_Module_Class struct), but technically it's undefined behavior. To quote the ISO/IEC 9899:TC2 final committee draft, section 6.2.7 paragraph 2: All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined. (And they are not compatible types.) Most C compilers don't reject (or even detect!) code which has this issue, but the GCC LTO development branch compiler does. (It outputs the types of the objects while generating .o files, along with a bunch of other information, then compares them when doing the final link-time code generation pass.) Patch from Savannah bug #25133. * src/base/ftinit.c (FT_USE_MODULE): Include variable type. * builds/amiga/include/freetype/config/ftmodule.h, include/freetype/config/ftmodule.h, */module.mk: Updated to declare pass correct types to FT_USE_MODULE.
2008-12-21 11:29:30 +01:00
FT_USE_MODULE( FT_Driver_ClassRec, tt_driver_class )
Update of the Amiga port. * builds/amiga/makefile, builds/amiga/smakefile: Handle new modules. * builds/amiga/makefile.os4: Makefile for AmigaOS4 SDK. * builds/amiga/README: Updated. * builds/amiga/include/freetype/config/ftconfig.h: Handle gcc for AmigaOS4. * builds/amiga/include/freetype/config/ftmodule.h: Handle new modules. * builds/amiga/src/base/ftdebug.c: Updated to current version of default ftdebug.c. Add various include files and macros to have proper support for both AmigaOS4 and older AmigaOS versions. Don't declare KVPrintF explicitly. Replace getenv with GetVar. Actually enable debugging code. * builds/amiga/src/base/ftsystem.c: Major rewrite.
2005-03-25 23:18:01 +01:00
#endif
#ifdef FT_USE_T1
FT_USE_MODULE declares things as: extern const FT_Module_Class (or similar for C++). However, the actual types of the variables being declared are often different, e.g., FT_Driver_ClassRec or FT_Renderer_Class. (Some are, indeed, FT_Module_Class.) This works with most C compilers (since those structs begin with an FT_Module_Class struct), but technically it's undefined behavior. To quote the ISO/IEC 9899:TC2 final committee draft, section 6.2.7 paragraph 2: All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined. (And they are not compatible types.) Most C compilers don't reject (or even detect!) code which has this issue, but the GCC LTO development branch compiler does. (It outputs the types of the objects while generating .o files, along with a bunch of other information, then compares them when doing the final link-time code generation pass.) Patch from Savannah bug #25133. * src/base/ftinit.c (FT_USE_MODULE): Include variable type. * builds/amiga/include/freetype/config/ftmodule.h, include/freetype/config/ftmodule.h, */module.mk: Updated to declare pass correct types to FT_USE_MODULE.
2008-12-21 11:29:30 +01:00
FT_USE_MODULE( FT_Driver_ClassRec, t1_driver_class )
* builds/amiga/*: Adaptations to latest changes. Support added for MorphOS. * src/pshinter/pshrec.c (FT_COMPONENT): Redefine to `trace_pshrec'. (ps_mask_table_merge, ps_hints_open, ps_hints_stem, ps_hints_t1stem3, ps_hints_t2mask, ps_hints_t2counter): Fix FT_ERROR messages. * src/pshinter/pshalgo1.c (FT_COMPONENT): Define as `trace_pshalgo1'. * src/pshinter/pshalgo2.c (FT_COMPONENT): Define as `trace_pshalgo2'. * include/freetype/internal/ftdebug.h (FT_Trace): Updated. * docs/modules.txt: New file.
2001-12-22 15:38:40 +01:00
#endif
Initial revision
2001-09-20 13:58:51 +02:00
#ifdef FT_USE_CFF
FT_USE_MODULE declares things as: extern const FT_Module_Class (or similar for C++). However, the actual types of the variables being declared are often different, e.g., FT_Driver_ClassRec or FT_Renderer_Class. (Some are, indeed, FT_Module_Class.) This works with most C compilers (since those structs begin with an FT_Module_Class struct), but technically it's undefined behavior. To quote the ISO/IEC 9899:TC2 final committee draft, section 6.2.7 paragraph 2: All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined. (And they are not compatible types.) Most C compilers don't reject (or even detect!) code which has this issue, but the GCC LTO development branch compiler does. (It outputs the types of the objects while generating .o files, along with a bunch of other information, then compares them when doing the final link-time code generation pass.) Patch from Savannah bug #25133. * src/base/ftinit.c (FT_USE_MODULE): Include variable type. * builds/amiga/include/freetype/config/ftmodule.h, include/freetype/config/ftmodule.h, */module.mk: Updated to declare pass correct types to FT_USE_MODULE.
2008-12-21 11:29:30 +01:00
FT_USE_MODULE( FT_Driver_ClassRec, cff_driver_class )
Initial revision
2001-09-20 13:58:51 +02:00
#endif
#ifdef FT_USE_T1CID
FT_USE_MODULE declares things as: extern const FT_Module_Class (or similar for C++). However, the actual types of the variables being declared are often different, e.g., FT_Driver_ClassRec or FT_Renderer_Class. (Some are, indeed, FT_Module_Class.) This works with most C compilers (since those structs begin with an FT_Module_Class struct), but technically it's undefined behavior. To quote the ISO/IEC 9899:TC2 final committee draft, section 6.2.7 paragraph 2: All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined. (And they are not compatible types.) Most C compilers don't reject (or even detect!) code which has this issue, but the GCC LTO development branch compiler does. (It outputs the types of the objects while generating .o files, along with a bunch of other information, then compares them when doing the final link-time code generation pass.) Patch from Savannah bug #25133. * src/base/ftinit.c (FT_USE_MODULE): Include variable type. * builds/amiga/include/freetype/config/ftmodule.h, include/freetype/config/ftmodule.h, */module.mk: Updated to declare pass correct types to FT_USE_MODULE.
2008-12-21 11:29:30 +01:00
FT_USE_MODULE( FT_Driver_ClassRec, t1cid_driver_class )
Initial revision
2001-09-20 13:58:51 +02:00
#endif
Update of the Amiga port. * builds/amiga/makefile, builds/amiga/smakefile: Handle new modules. * builds/amiga/makefile.os4: Makefile for AmigaOS4 SDK. * builds/amiga/README: Updated. * builds/amiga/include/freetype/config/ftconfig.h: Handle gcc for AmigaOS4. * builds/amiga/include/freetype/config/ftmodule.h: Handle new modules. * builds/amiga/src/base/ftdebug.c: Updated to current version of default ftdebug.c. Add various include files and macros to have proper support for both AmigaOS4 and older AmigaOS versions. Don't declare KVPrintF explicitly. Replace getenv with GetVar. Actually enable debugging code. * builds/amiga/src/base/ftsystem.c: Major rewrite.
2005-03-25 23:18:01 +01:00
#ifdef FT_USE_PFR
FT_USE_MODULE declares things as: extern const FT_Module_Class (or similar for C++). However, the actual types of the variables being declared are often different, e.g., FT_Driver_ClassRec or FT_Renderer_Class. (Some are, indeed, FT_Module_Class.) This works with most C compilers (since those structs begin with an FT_Module_Class struct), but technically it's undefined behavior. To quote the ISO/IEC 9899:TC2 final committee draft, section 6.2.7 paragraph 2: All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined. (And they are not compatible types.) Most C compilers don't reject (or even detect!) code which has this issue, but the GCC LTO development branch compiler does. (It outputs the types of the objects while generating .o files, along with a bunch of other information, then compares them when doing the final link-time code generation pass.) Patch from Savannah bug #25133. * src/base/ftinit.c (FT_USE_MODULE): Include variable type. * builds/amiga/include/freetype/config/ftmodule.h, include/freetype/config/ftmodule.h, */module.mk: Updated to declare pass correct types to FT_USE_MODULE.
2008-12-21 11:29:30 +01:00
FT_USE_MODULE( FT_Driver_ClassRec, pfr_driver_class )
* builds/amiga/makefile, builds/amiga/smakefile, amiga/include/freetype/config/ftmodule.h: Updated to include support for BDF and Type42 drivers. * docs/modules.txt: Updated. * src/bdf/bdflib.c (_bdf_parse_glyphs): Replace floating point math with calls to `FT_MulDiv'.
2002-05-29 00:38:05 +02:00
#endif
Update of the Amiga port. * builds/amiga/makefile, builds/amiga/smakefile: Handle new modules. * builds/amiga/makefile.os4: Makefile for AmigaOS4 SDK. * builds/amiga/README: Updated. * builds/amiga/include/freetype/config/ftconfig.h: Handle gcc for AmigaOS4. * builds/amiga/include/freetype/config/ftmodule.h: Handle new modules. * builds/amiga/src/base/ftdebug.c: Updated to current version of default ftdebug.c. Add various include files and macros to have proper support for both AmigaOS4 and older AmigaOS versions. Don't declare KVPrintF explicitly. Replace getenv with GetVar. Actually enable debugging code. * builds/amiga/src/base/ftsystem.c: Major rewrite.
2005-03-25 23:18:01 +01:00
#ifdef FT_USE_T42
FT_USE_MODULE declares things as: extern const FT_Module_Class (or similar for C++). However, the actual types of the variables being declared are often different, e.g., FT_Driver_ClassRec or FT_Renderer_Class. (Some are, indeed, FT_Module_Class.) This works with most C compilers (since those structs begin with an FT_Module_Class struct), but technically it's undefined behavior. To quote the ISO/IEC 9899:TC2 final committee draft, section 6.2.7 paragraph 2: All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined. (And they are not compatible types.) Most C compilers don't reject (or even detect!) code which has this issue, but the GCC LTO development branch compiler does. (It outputs the types of the objects while generating .o files, along with a bunch of other information, then compares them when doing the final link-time code generation pass.) Patch from Savannah bug #25133. * src/base/ftinit.c (FT_USE_MODULE): Include variable type. * builds/amiga/include/freetype/config/ftmodule.h, include/freetype/config/ftmodule.h, */module.mk: Updated to declare pass correct types to FT_USE_MODULE.
2008-12-21 11:29:30 +01:00
FT_USE_MODULE( FT_Driver_ClassRec, t42_driver_class )
Initial revision
2001-09-20 13:58:51 +02:00
#endif
Update of the Amiga port. * builds/amiga/makefile, builds/amiga/smakefile: Handle new modules. * builds/amiga/makefile.os4: Makefile for AmigaOS4 SDK. * builds/amiga/README: Updated. * builds/amiga/include/freetype/config/ftconfig.h: Handle gcc for AmigaOS4. * builds/amiga/include/freetype/config/ftmodule.h: Handle new modules. * builds/amiga/src/base/ftdebug.c: Updated to current version of default ftdebug.c. Add various include files and macros to have proper support for both AmigaOS4 and older AmigaOS versions. Don't declare KVPrintF explicitly. Replace getenv with GetVar. Actually enable debugging code. * builds/amiga/src/base/ftsystem.c: Major rewrite.
2005-03-25 23:18:01 +01:00
#ifdef FT_USE_WINFNT
FT_USE_MODULE declares things as: extern const FT_Module_Class (or similar for C++). However, the actual types of the variables being declared are often different, e.g., FT_Driver_ClassRec or FT_Renderer_Class. (Some are, indeed, FT_Module_Class.) This works with most C compilers (since those structs begin with an FT_Module_Class struct), but technically it's undefined behavior. To quote the ISO/IEC 9899:TC2 final committee draft, section 6.2.7 paragraph 2: All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined. (And they are not compatible types.) Most C compilers don't reject (or even detect!) code which has this issue, but the GCC LTO development branch compiler does. (It outputs the types of the objects while generating .o files, along with a bunch of other information, then compares them when doing the final link-time code generation pass.) Patch from Savannah bug #25133. * src/base/ftinit.c (FT_USE_MODULE): Include variable type. * builds/amiga/include/freetype/config/ftmodule.h, include/freetype/config/ftmodule.h, */module.mk: Updated to declare pass correct types to FT_USE_MODULE.
2008-12-21 11:29:30 +01:00
FT_USE_MODULE( FT_Driver_ClassRec, winfnt_driver_class )
Update of the Amiga port. * builds/amiga/makefile, builds/amiga/smakefile: Handle new modules. * builds/amiga/makefile.os4: Makefile for AmigaOS4 SDK. * builds/amiga/README: Updated. * builds/amiga/include/freetype/config/ftconfig.h: Handle gcc for AmigaOS4. * builds/amiga/include/freetype/config/ftmodule.h: Handle new modules. * builds/amiga/src/base/ftdebug.c: Updated to current version of default ftdebug.c. Add various include files and macros to have proper support for both AmigaOS4 and older AmigaOS versions. Don't declare KVPrintF explicitly. Replace getenv with GetVar. Actually enable debugging code. * builds/amiga/src/base/ftsystem.c: Major rewrite.
2005-03-25 23:18:01 +01:00
#endif
#ifdef FT_USE_PCF
FT_USE_MODULE declares things as: extern const FT_Module_Class (or similar for C++). However, the actual types of the variables being declared are often different, e.g., FT_Driver_ClassRec or FT_Renderer_Class. (Some are, indeed, FT_Module_Class.) This works with most C compilers (since those structs begin with an FT_Module_Class struct), but technically it's undefined behavior. To quote the ISO/IEC 9899:TC2 final committee draft, section 6.2.7 paragraph 2: All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined. (And they are not compatible types.) Most C compilers don't reject (or even detect!) code which has this issue, but the GCC LTO development branch compiler does. (It outputs the types of the objects while generating .o files, along with a bunch of other information, then compares them when doing the final link-time code generation pass.) Patch from Savannah bug #25133. * src/base/ftinit.c (FT_USE_MODULE): Include variable type. * builds/amiga/include/freetype/config/ftmodule.h, include/freetype/config/ftmodule.h, */module.mk: Updated to declare pass correct types to FT_USE_MODULE.
2008-12-21 11:29:30 +01:00
FT_USE_MODULE( FT_Driver_ClassRec, pcf_driver_class )
* builds/amiga/makefile, builds/amiga/smakefile, amiga/include/freetype/config/ftmodule.h: Updated to include support for BDF and Type42 drivers. * docs/modules.txt: Updated. * src/bdf/bdflib.c (_bdf_parse_glyphs): Replace floating point math with calls to `FT_MulDiv'.
2002-05-29 00:38:05 +02:00
#endif
Initial revision
2001-09-20 13:58:51 +02:00
#ifdef FT_USE_PSAUX
FT_USE_MODULE declares things as: extern const FT_Module_Class (or similar for C++). However, the actual types of the variables being declared are often different, e.g., FT_Driver_ClassRec or FT_Renderer_Class. (Some are, indeed, FT_Module_Class.) This works with most C compilers (since those structs begin with an FT_Module_Class struct), but technically it's undefined behavior. To quote the ISO/IEC 9899:TC2 final committee draft, section 6.2.7 paragraph 2: All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined. (And they are not compatible types.) Most C compilers don't reject (or even detect!) code which has this issue, but the GCC LTO development branch compiler does. (It outputs the types of the objects while generating .o files, along with a bunch of other information, then compares them when doing the final link-time code generation pass.) Patch from Savannah bug #25133. * src/base/ftinit.c (FT_USE_MODULE): Include variable type. * builds/amiga/include/freetype/config/ftmodule.h, include/freetype/config/ftmodule.h, */module.mk: Updated to declare pass correct types to FT_USE_MODULE.
2008-12-21 11:29:30 +01:00
FT_USE_MODULE( FT_Module_Class, psaux_module_class )
Initial revision
2001-09-20 13:58:51 +02:00
#endif
#ifdef FT_USE_PSNAMES
FT_USE_MODULE declares things as: extern const FT_Module_Class (or similar for C++). However, the actual types of the variables being declared are often different, e.g., FT_Driver_ClassRec or FT_Renderer_Class. (Some are, indeed, FT_Module_Class.) This works with most C compilers (since those structs begin with an FT_Module_Class struct), but technically it's undefined behavior. To quote the ISO/IEC 9899:TC2 final committee draft, section 6.2.7 paragraph 2: All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined. (And they are not compatible types.) Most C compilers don't reject (or even detect!) code which has this issue, but the GCC LTO development branch compiler does. (It outputs the types of the objects while generating .o files, along with a bunch of other information, then compares them when doing the final link-time code generation pass.) Patch from Savannah bug #25133. * src/base/ftinit.c (FT_USE_MODULE): Include variable type. * builds/amiga/include/freetype/config/ftmodule.h, include/freetype/config/ftmodule.h, */module.mk: Updated to declare pass correct types to FT_USE_MODULE.
2008-12-21 11:29:30 +01:00
FT_USE_MODULE( FT_Module_Class, psnames_module_class )
Initial revision
2001-09-20 13:58:51 +02:00
#endif
Update of the Amiga port. * builds/amiga/makefile, builds/amiga/smakefile: Handle new modules. * builds/amiga/makefile.os4: Makefile for AmigaOS4 SDK. * builds/amiga/README: Updated. * builds/amiga/include/freetype/config/ftconfig.h: Handle gcc for AmigaOS4. * builds/amiga/include/freetype/config/ftmodule.h: Handle new modules. * builds/amiga/src/base/ftdebug.c: Updated to current version of default ftdebug.c. Add various include files and macros to have proper support for both AmigaOS4 and older AmigaOS versions. Don't declare KVPrintF explicitly. Replace getenv with GetVar. Actually enable debugging code. * builds/amiga/src/base/ftsystem.c: Major rewrite.
2005-03-25 23:18:01 +01:00
#ifdef FT_USE_PSHINT
FT_USE_MODULE declares things as: extern const FT_Module_Class (or similar for C++). However, the actual types of the variables being declared are often different, e.g., FT_Driver_ClassRec or FT_Renderer_Class. (Some are, indeed, FT_Module_Class.) This works with most C compilers (since those structs begin with an FT_Module_Class struct), but technically it's undefined behavior. To quote the ISO/IEC 9899:TC2 final committee draft, section 6.2.7 paragraph 2: All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined. (And they are not compatible types.) Most C compilers don't reject (or even detect!) code which has this issue, but the GCC LTO development branch compiler does. (It outputs the types of the objects while generating .o files, along with a bunch of other information, then compares them when doing the final link-time code generation pass.) Patch from Savannah bug #25133. * src/base/ftinit.c (FT_USE_MODULE): Include variable type. * builds/amiga/include/freetype/config/ftmodule.h, include/freetype/config/ftmodule.h, */module.mk: Updated to declare pass correct types to FT_USE_MODULE.
2008-12-21 11:29:30 +01:00
FT_USE_MODULE( FT_Module_Class, pshinter_module_class )
Update of the Amiga port. * builds/amiga/makefile, builds/amiga/smakefile: Handle new modules. * builds/amiga/makefile.os4: Makefile for AmigaOS4 SDK. * builds/amiga/README: Updated. * builds/amiga/include/freetype/config/ftconfig.h: Handle gcc for AmigaOS4. * builds/amiga/include/freetype/config/ftmodule.h: Handle new modules. * builds/amiga/src/base/ftdebug.c: Updated to current version of default ftdebug.c. Add various include files and macros to have proper support for both AmigaOS4 and older AmigaOS versions. Don't declare KVPrintF explicitly. Replace getenv with GetVar. Actually enable debugging code. * builds/amiga/src/base/ftsystem.c: Major rewrite.
2005-03-25 23:18:01 +01:00
#endif
Initial revision
2001-09-20 13:58:51 +02:00
#ifdef FT_USE_RASTER
FT_USE_MODULE declares things as: extern const FT_Module_Class (or similar for C++). However, the actual types of the variables being declared are often different, e.g., FT_Driver_ClassRec or FT_Renderer_Class. (Some are, indeed, FT_Module_Class.) This works with most C compilers (since those structs begin with an FT_Module_Class struct), but technically it's undefined behavior. To quote the ISO/IEC 9899:TC2 final committee draft, section 6.2.7 paragraph 2: All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined. (And they are not compatible types.) Most C compilers don't reject (or even detect!) code which has this issue, but the GCC LTO development branch compiler does. (It outputs the types of the objects while generating .o files, along with a bunch of other information, then compares them when doing the final link-time code generation pass.) Patch from Savannah bug #25133. * src/base/ftinit.c (FT_USE_MODULE): Include variable type. * builds/amiga/include/freetype/config/ftmodule.h, include/freetype/config/ftmodule.h, */module.mk: Updated to declare pass correct types to FT_USE_MODULE.
2008-12-21 11:29:30 +01:00
FT_USE_MODULE( FT_Renderer_Class, ft_raster1_renderer_class )
Initial revision
2001-09-20 13:58:51 +02:00
#endif
#ifdef FT_USE_SFNT
FT_USE_MODULE declares things as: extern const FT_Module_Class (or similar for C++). However, the actual types of the variables being declared are often different, e.g., FT_Driver_ClassRec or FT_Renderer_Class. (Some are, indeed, FT_Module_Class.) This works with most C compilers (since those structs begin with an FT_Module_Class struct), but technically it's undefined behavior. To quote the ISO/IEC 9899:TC2 final committee draft, section 6.2.7 paragraph 2: All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined. (And they are not compatible types.) Most C compilers don't reject (or even detect!) code which has this issue, but the GCC LTO development branch compiler does. (It outputs the types of the objects while generating .o files, along with a bunch of other information, then compares them when doing the final link-time code generation pass.) Patch from Savannah bug #25133. * src/base/ftinit.c (FT_USE_MODULE): Include variable type. * builds/amiga/include/freetype/config/ftmodule.h, include/freetype/config/ftmodule.h, */module.mk: Updated to declare pass correct types to FT_USE_MODULE.
2008-12-21 11:29:30 +01:00
FT_USE_MODULE( FT_Module_Class, sfnt_module_class )
Initial revision
2001-09-20 13:58:51 +02:00
#endif
#ifdef FT_USE_SMOOTH
FT_USE_MODULE declares things as: extern const FT_Module_Class (or similar for C++). However, the actual types of the variables being declared are often different, e.g., FT_Driver_ClassRec or FT_Renderer_Class. (Some are, indeed, FT_Module_Class.) This works with most C compilers (since those structs begin with an FT_Module_Class struct), but technically it's undefined behavior. To quote the ISO/IEC 9899:TC2 final committee draft, section 6.2.7 paragraph 2: All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined. (And they are not compatible types.) Most C compilers don't reject (or even detect!) code which has this issue, but the GCC LTO development branch compiler does. (It outputs the types of the objects while generating .o files, along with a bunch of other information, then compares them when doing the final link-time code generation pass.) Patch from Savannah bug #25133. * src/base/ftinit.c (FT_USE_MODULE): Include variable type. * builds/amiga/include/freetype/config/ftmodule.h, include/freetype/config/ftmodule.h, */module.mk: Updated to declare pass correct types to FT_USE_MODULE.
2008-12-21 11:29:30 +01:00
FT_USE_MODULE( FT_Renderer_Class, ft_smooth_renderer_class )
FT_USE_MODULE( FT_Renderer_Class, ft_smooth_lcd_renderer_class )
FT_USE_MODULE( FT_Renderer_Class, ft_smooth_lcdv_renderer_class )
Initial revision
2001-09-20 13:58:51 +02:00
#endif
Update of the Amiga port. * builds/amiga/makefile, builds/amiga/smakefile: Handle new modules. * builds/amiga/makefile.os4: Makefile for AmigaOS4 SDK. * builds/amiga/README: Updated. * builds/amiga/include/freetype/config/ftconfig.h: Handle gcc for AmigaOS4. * builds/amiga/include/freetype/config/ftmodule.h: Handle new modules. * builds/amiga/src/base/ftdebug.c: Updated to current version of default ftdebug.c. Add various include files and macros to have proper support for both AmigaOS4 and older AmigaOS versions. Don't declare KVPrintF explicitly. Replace getenv with GetVar. Actually enable debugging code. * builds/amiga/src/base/ftsystem.c: Major rewrite.
2005-03-25 23:18:01 +01:00
#ifdef FT_USE_OTV
FT_USE_MODULE declares things as: extern const FT_Module_Class (or similar for C++). However, the actual types of the variables being declared are often different, e.g., FT_Driver_ClassRec or FT_Renderer_Class. (Some are, indeed, FT_Module_Class.) This works with most C compilers (since those structs begin with an FT_Module_Class struct), but technically it's undefined behavior. To quote the ISO/IEC 9899:TC2 final committee draft, section 6.2.7 paragraph 2: All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined. (And they are not compatible types.) Most C compilers don't reject (or even detect!) code which has this issue, but the GCC LTO development branch compiler does. (It outputs the types of the objects while generating .o files, along with a bunch of other information, then compares them when doing the final link-time code generation pass.) Patch from Savannah bug #25133. * src/base/ftinit.c (FT_USE_MODULE): Include variable type. * builds/amiga/include/freetype/config/ftmodule.h, include/freetype/config/ftmodule.h, */module.mk: Updated to declare pass correct types to FT_USE_MODULE.
2008-12-21 11:29:30 +01:00
FT_USE_MODULE( FT_Module_Class, otv_module_class )
Initial revision
2001-09-20 13:58:51 +02:00
#endif
Update of the Amiga port. * builds/amiga/makefile, builds/amiga/smakefile: Handle new modules. * builds/amiga/makefile.os4: Makefile for AmigaOS4 SDK. * builds/amiga/README: Updated. * builds/amiga/include/freetype/config/ftconfig.h: Handle gcc for AmigaOS4. * builds/amiga/include/freetype/config/ftmodule.h: Handle new modules. * builds/amiga/src/base/ftdebug.c: Updated to current version of default ftdebug.c. Add various include files and macros to have proper support for both AmigaOS4 and older AmigaOS versions. Don't declare KVPrintF explicitly. Replace getenv with GetVar. Actually enable debugging code. * builds/amiga/src/base/ftsystem.c: Major rewrite.
2005-03-25 23:18:01 +01:00
#ifdef FT_USE_BDF
FT_USE_MODULE declares things as: extern const FT_Module_Class (or similar for C++). However, the actual types of the variables being declared are often different, e.g., FT_Driver_ClassRec or FT_Renderer_Class. (Some are, indeed, FT_Module_Class.) This works with most C compilers (since those structs begin with an FT_Module_Class struct), but technically it's undefined behavior. To quote the ISO/IEC 9899:TC2 final committee draft, section 6.2.7 paragraph 2: All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined. (And they are not compatible types.) Most C compilers don't reject (or even detect!) code which has this issue, but the GCC LTO development branch compiler does. (It outputs the types of the objects while generating .o files, along with a bunch of other information, then compares them when doing the final link-time code generation pass.) Patch from Savannah bug #25133. * src/base/ftinit.c (FT_USE_MODULE): Include variable type. * builds/amiga/include/freetype/config/ftmodule.h, include/freetype/config/ftmodule.h, */module.mk: Updated to declare pass correct types to FT_USE_MODULE.
2008-12-21 11:29:30 +01:00
FT_USE_MODULE( FT_Driver_ClassRec, bdf_driver_class )
Initial revision
2001-09-20 13:58:51 +02:00
#endif
* builds/amiga/*: Added copyright notes, reworked some comments.
2005-06-08 13:56:55 +02:00
Added support for gxvalid module.
2005-11-17 15:19:30 +01:00
#ifdef FT_USE_GXV
FT_USE_MODULE declares things as: extern const FT_Module_Class (or similar for C++). However, the actual types of the variables being declared are often different, e.g., FT_Driver_ClassRec or FT_Renderer_Class. (Some are, indeed, FT_Module_Class.) This works with most C compilers (since those structs begin with an FT_Module_Class struct), but technically it's undefined behavior. To quote the ISO/IEC 9899:TC2 final committee draft, section 6.2.7 paragraph 2: All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined. (And they are not compatible types.) Most C compilers don't reject (or even detect!) code which has this issue, but the GCC LTO development branch compiler does. (It outputs the types of the objects while generating .o files, along with a bunch of other information, then compares them when doing the final link-time code generation pass.) Patch from Savannah bug #25133. * src/base/ftinit.c (FT_USE_MODULE): Include variable type. * builds/amiga/include/freetype/config/ftmodule.h, include/freetype/config/ftmodule.h, */module.mk: Updated to declare pass correct types to FT_USE_MODULE.
2008-12-21 11:29:30 +01:00
FT_USE_MODULE( FT_Module_Class, gxv_module_class )
Added support for gxvalid module.
2005-11-17 15:19:30 +01:00
#endif
* builds/amiga/*: Added copyright notes, reworked some comments.
2005-06-08 13:56:55 +02:00
/*
Local Variables:
coding: latin-1
End:
*/