Commit e49ab25c authored by David Turner's avatar David Turner
Browse files

formatting - removed trailing spaces

parent 968f0c37
......@@ -17,19 +17,19 @@ I. QUICK COMMAND-LINE GUIDE:
Install GNU Make, then try the following on Unix or any system with gcc:
make // this will setup the build
make // this will build the library
On Win32+Visual C++:
make setup visualc // setup the build for VisualC++ on Win32
make // build the library
Then, go to the "demos" directory and type
To compile the demo programs..
If this doesn't work, read the following..
......@@ -45,58 +45,58 @@ II. COMMAND-LINE COMPILATION:
FreeType 2 includes a powerful and flexible build system that allows you
to easily compile it on a great variety of platforms from the command
line. To do so, just follow these simple instructions:
a/ Install GNU Make:
Because GNU Make is the only Make tool supported to compile FreeType 2,
you should install it on your machine.
Because the FT2 build system relies on many important features of GNU
Make, trying to build the library with any other Make tool will *fail*.
b/ Invoke "make":
Go to the root FT2 directory, then simply invoke GNU Make from the
command line, this will launch the FreeType 2 Host Platform detection
routines. A summary will be displayed, for example, on Win32:
FreeType build system -- automatic system detection
The following settings are used:
platform win32
compiler gcc
configuration directory ./config/win32
configuration rules ./config/win32/
configuration rules ./config/win32/
If this does not correspond to your system or settings please remove
the file '' from this directory then read the INSTALL file
for help.
Otherwise, simply type 'make' again to build the library.
If the detected settings correspond to your platform and compiler,
skip to step e/. Note that if your platform is completely alien to
the build system, the detected platform will be "ansi".
c/ Configure the build system for a different compiler:
If the build system correctly detected your platform, but you want to
use a different compiler than the one specified in the summary (for
most platforms, gcc is the defaut compiler), simply invoke GNU Make
like :
make setup <compiler>
For example:
to use Visual C++ on Win32, type: "make setup visualc"
to use LCC-Win32 on Win32, type: "make setup lcc"
The <compiler> name to use is platform-dependent. The list of available
compilers for your system is available in the file
"config/<system>/" (note that we hope to make the list
......@@ -106,50 +106,50 @@ II. COMMAND-LINE COMPILATION:
d/ Configure the build system for an unknown platform/compiler:
What the auto-detection/setup phase of the build system does is simply
copy a file to the current directory under the name "".
For example, on OS/2+gcc, it would simply copy "config/os2/"
to "./"
If for some reason your platform isn't correctly detected, simply copy
manually the configuration sub-makefile to "./" and go to
step e/.
Note that this file is a sub-Makefile used to specify Make variables
used to invoke the compiler and linker during the build, you can easily
create your own version from one of the existing configuration files,
then copy it to the current directory under the name "./".
e/ Build the library:
The auto-detection/setup phase should have copied a file in the current
directory, called "./". This file contains definitions of various
Make variables used to invoke the compiler and linker during the build.
To launch the build, simply invoke GNU Make again: the top Makefile will
detect the configuration file and run the build with it..
f/ Build the demonstration programs:
Once the library is compiled, go to "demos", then invoke GNU Make.
Note that the demonstration programs include a tiny graphics sub-system
that includes "drivers" to display Windows on Win32, X11 and OS/2. The
build system should automatically detect which driver to use based on
the current platform.
When building the demos, the build system tries to detect your X11 path
by looking for the patterns "X11R5/bin", "X11R6/bin" or "X11/bin" in
your current path. If no X11 path is found, the demo programs will not
be able to display graphics and will fail. Change your current path
if you encounter this problem.
Note that the release version will use Autoconf to detect everything
on Unix, so this will not be necessary !!
......@@ -165,7 +165,7 @@ II. DETAILED COMPILATION PROCEDURE:
Each component must be compiled as a stand-alone object file, even when it
is really made of several C source files. For example, the "base layer"
component is made of the following C files:
ftcalc.c - computations
......@@ -174,10 +174,10 @@ II. DETAILED COMPILATION PROCEDURE:
ftlist.c - simple list management
ftoutln.c - simple outline processing
ftextend.c - extensions support
However, you can create a single object file by compiling the file
"src/base/ftbase.c", whose content is:
#include <ftcalc.c>
#include <ftobjs.c>
#include <ftstream.c>
......@@ -187,7 +187,7 @@ II. DETAILED COMPILATION PROCEDURE:
Similarly, each component has a single "englobing" C file to compile it
as a stand-alone object, i.e. :
src/base/ftbase.c - the base layer, high-level interface
src/sfnt/sfnt.c - the "sfnt" module
src/psnames/psnames.c - the Postscript Names module
......@@ -196,9 +196,9 @@ II. DETAILED COMPILATION PROCEDURE:
To compile one component, do the following:
- add the top-level "include" directory to your compilation include path
- add the component's path to your compilation include path too. Being
in the component's directory isn't enough !!
......@@ -206,18 +206,18 @@ II. DETAILED COMPILATION PROCEDURE:
For example, the following line can be used to compile the truetype driver
on Unix:
cd freetype2/
cc -c -Iinclude -Isrc/truetype src/truetype/truetype.c
cd freetype2/src/truetype
cc -c -I../../include -I. src/truetype/truetype.c
The complete list of files to compile for a feature-complete build of
FreeType 2 is:
src/base/ftsystem.c - system-specific memory and i/o support
src/base/ftinit.c - initialisation layer
src/base/ftdebug.c - debugging component (empty in release build)
- tagged "BETA-6" in the CVS tree. This one is a serious release candidate
even though it doesn't incorporate the auto-hinter yet..
......@@ -9,7 +9,7 @@ LATEST CHANGES -
+ re-enable support for 5-gray levels anti-aliasing (suck, suck..)
- created new header files, and modified sources accordingly:
<freetype/fttypes.h> - simple FreeType types, without the API
<freetype/internal/ftmemory.h> - definition of memory-management macros
......@@ -26,15 +26,15 @@ LATEST CHANGES -
| It seems the C pre-processor that comes with LCC is broken, it
| doesn't recognize the ANSI standard directives # and ## correctly
| when one of the argument is a macro. Also, something like:
| #define F(x) print##x
| F(("hello"))
| will get incorrectly translated to:
| print "hello")
| by its pre-processor. For this reason, you simply cannot build
| FreeType 2 in debug mode with this compiler..
......@@ -42,12 +42,12 @@ LATEST CHANGES -
- yet another massive grunt work. I've changed the definition of the
an argument, which is the function's return value type.
This is necessary to compile FreeType as a DLL on Windows and OS/2.
Depending on the compiler used, a compiler-specific keyword like __export
or __system must be placed before (VisualC++) or after (BorlandC++)
the type..
Of course, this needed a lot of changes throughout the source code
to make it compile again... All cleaned up now, apparently..
......@@ -80,7 +80,7 @@ LATEST CHANGES -
within it for more information.
- major directory hierarchy re-organisation. This was done for two things:
* first, to ease the "manual" compilation of the library by requiring
at lot less include paths :-)
......@@ -90,19 +90,19 @@ LATEST CHANGES -
Basically, you should now use the 'freetype/' prefix for header inclusion,
as in:
#include <freetype/freetype.h>
#include <freetype/ftglyph.h>
Some new include sub-directories are available:
a. the "freetype/config" directory, contains two files used to
configure the build of the library. Client applications should
not need to look at these normally, but they can if they want.
#include <freetype/config/ftoption.h>
#include <freetype/config/ftconfig.h>
b. the "freetype/internal" directory, contains header files that
describes library internals. These are the header files that were
previously found in the "src/base" and "src/shared" directories.
......@@ -110,9 +110,9 @@ LATEST CHANGES -
As usual, the build system and the demos have been updated to reflect
the change..
Here's a layout of the new directory hierarchy:
......@@ -122,17 +122,17 @@ LATEST CHANGES -
......@@ -142,7 +142,7 @@ LATEST CHANGES -
Compiling a module is now much easier, for example, the following should
work when in the TOP directory on an ANSI build:
gcc -c -I./include -I./src/base src/base/ftbase.c
gcc -c -I./include -I./src/sfnt src/sfnt/sfnt.c
......@@ -178,9 +178,9 @@ OLD CHANGES - 14-apr-2000
- fixed a bug in the TrueType glyph loader that prevented the correct
loading of some CJK glyphs in mingli.ttf
- improved the standard Type 1 hinter in "src/type1"
- fixed two bugs in the experimental Type 1 driver in "src/type1z"
to handle the new XFree86 4.0 fonts (and a few other ones..)
......@@ -189,7 +189,7 @@ OLD CHANGES - 14-apr-2000
in "demos/src/ftgrays.c" and should move to the library itself
in the next beta.. NOTE: The smooth renderer doesn't compile in
stand-alone mode anymore, but this should be fixed RSN..
- introduced convenience functions to more easily deal with glyph
images, see "include/ftglyph.h" for more details, as well as the
new demo program named "demos/src/ftstring.c" that demonstrates
......@@ -214,11 +214,11 @@ OLD CHANGES - 12-mar-2000
- changed the layout of configuration files : now, all ANSI configuration
files are located in "freetype2/config". System-specific over-rides
can be placed in "freetype2/config/<system>".
- moved all configuration macros to "config/ftoption.h"
- improvements in the Type 1 driver with AFM support
- changed the fields in the FT_Outline structure : the old "flags"
array is re-named "tags", while all ancient flags are encoded into
a single unsigned int named "flags".
......@@ -230,10 +230,10 @@ OLD CHANGES - 12-mar-2000
- added a smooth anti-alias renderer to the demonstration programs
- added Mac graphics driver (thanks Just)
- FT_Open_Face changed in order to received a pointer to a FT_Open_Args
- various cleanups, a few more API functions implemented (see FT_Attach_File)
- updated some docs
......@@ -314,11 +314,11 @@ OLDER CHANGES - 27-jan-2000
- updated the "sfnt" module interface to allow several SFNT-based
drivers to co-exist peacefully
- updated the "T1_Face" type to better separate Postscript font content
from the rest of the FT_Face structure. Might be used later by the
CFF/Type2 driver..
- added an experimental replacement Type 1 driver featuring advanced
(and speedy) pattern matching to retrieve the data from postscript
......@@ -351,27 +351,27 @@ High-Level Interface :
- resource objects have disappeared. this means that face objects can
now be created with a single function call (see FT_New_Face and
- when calling either FT_New_Face & FT_Open_Face, a size object and a
glyph slot object are automatically created for the face, and can be
accessed through "face->glyph" and "face->size" if one really needs to.
In most cases, there's no need to call FT_New_Size or FT_New_Glyph.
- similarly, FT_Load_Glyph now only takes a "face" argument (instead of
a glyph slot and a size). Also, it's "result" parameter is gone, as
the glyph image type is returned in the field "face->glyph.format"
- the list of available charmaps is directly accessible through
"face->charmaps", counting "face->num_charmaps" elements. Each
charmap has an 'encoding' field which specifies which known encoding
it deals with. Valid values are, for example :
ft_encoding_unicode (for ASCII, Latin-1 and Unicode)
other values may be added in the future. Each charmap still holds its
"platform_id" and "encoding_id" values in case the encoding is too
exotic for the current library
......@@ -510,7 +510,7 @@ Portability :
Font Drivers :
The Font Driver interface has been modified in order to support
extensions & versioning.
......@@ -561,10 +561,10 @@ Extensions support :
driver = FT_Get_Driver( library, "truetype" );
if (!driver) return FT_Err_Unimplemented_Feature;
return FT_Register_Extension( driver, &extension_class );
return FT_Register_Extension( driver, &extension_class );
// Implementing the extensions
FT_Error FT_Proceed_Extension_XXX( FT_Face face )
......@@ -33,7 +33,7 @@
/* initialisation */
extern int grInit( void );
/* finalisation */
extern void grDone( void );
......@@ -52,13 +52,13 @@
gr_pixel_mode_rgb32, /* 32-bits mode - 16 million colors */
gr_pixel_mode_max /* don't remove */
} grPixelMode;
/* forward declaration of the surface class */
typedef struct grSurface_ grSurface;
......@@ -106,7 +106,7 @@
grPos x;
grPos y;
} grVector;
......@@ -114,7 +114,7 @@
long value;
unsigned char chroma[4];
} grColor;
......@@ -125,7 +125,7 @@
* grNewBitmap
* <Description>
* creates a new bitmap
* creates a new bitmap
* <Input>
* pixel_mode :: the target surface's pixel_mode
......@@ -163,7 +163,7 @@
* writes a given glyph bitmap to a target surface.
* <Input>
* target :: handle to target bitmap
* target :: handle to target bitmap
* glyph :: handle to source glyph bitmap
* x :: position of left-most pixel of glyph image in target surface
* y :: position of top-most pixel of glyph image in target surface
......@@ -185,7 +185,7 @@
* This function performs clipping
extern int grBlitGlyphToBitmap( grBitmap* target,
grBitmap* glyph,
grPos x,
......@@ -199,7 +199,7 @@
* grFillRectangle
* <Description>
* this function is used to fill a given rectangle on a surface
* this function is used to fill a given rectangle on a surface
* <Input>
* surface :: handle to target surface
......@@ -210,7 +210,7 @@
* color :: fill color
extern void grFillRectangle( grBitmap* surface,
grPos x,
grPos y,
......@@ -240,7 +240,7 @@
* color :: color to be used to draw the character
void grWriteCellChar( grBitmap* target,
int x,
......@@ -262,14 +262,14 @@
* This function writes a string with the internal font
* <Input>
* target :: handle to target bitmap
* target :: handle to target bitmap
* x :: x pixel position of string's top left corner
* y :: y pixel position of string's top left corner
* string :: Latin-1 text string
* color :: color to be used to draw the character
void grWriteCellString( grBitmap* target,
int x,
......@@ -283,7 +283,7 @@
* grDoneBitmap
* <Description>
* destroys a bitmap
* destroys a bitmap
* <Input>
* bitmap :: handle to bitmap descriptor
......@@ -336,7 +336,7 @@
* client applications..
typedef struct grDeviceChain_ grDeviceChain;
struct grDeviceChain_
......@@ -372,7 +372,7 @@
* If no driver could be initialised, this function returns NULL.
grDeviceChain* grInitDevices( void );
......@@ -411,12 +411,12 @@
* 2 and 256.
* the pixel modes do not provide the number of grays in the case
* of "gray" devices. You should try to create a surface with the
* of "gray" devices. You should try to create a surface with the
* maximal number (256, that is) and see the value returned in
* the bitmap descriptor.
extern void grGetDeviceModes( const char* device_name,
int *num_modes,
grPixelMode* *pixel_modes );
......@@ -469,7 +469,7 @@
* you can thus discard the 'bitmap' parameter after the call.
extern grSurface* grNewSurface( const char* device,
grBitmap* bitmap );
......@@ -493,7 +493,7 @@
* height :: rectangle height in pixels
extern void grRefreshRectangle( grSurface* surface,
grPos x,
grPos y,
......@@ -508,7 +508,7 @@
* <Description>
* a variation of grRefreshRectangle which repaints the whole surface
* to the screen.
* to the screen.
* <Input>
* surface :: handle to target surface
......@@ -542,7 +542,7 @@
* color :: color to be used to draw the character
void grWriteSurfaceChar( grSurface* target,
int x,
......@@ -567,14 +567,14 @@
* This function writes a string with the internal font
* <Input>
* target :: handle to target bitmap
* target :: handle to target bitmap
* x :: x pixel position of string's top left corner
* y :: y pixel position of string's top left corner
* string :: Latin-1 text string
* color :: color to be used to draw the character
void grWriteSurfaceString( grSurface* target,
int x,
......@@ -622,7 +622,7 @@
* XXX : For now, only keypresses are supported.
int grListenSurface( grSurface* surface,
int event_mask,