blob: 7a471a2feba3f7cd2e6210d3335d83e9f07178ee [file] [log] [blame]
David Turnerefce08d2000-05-11 18:23:52 +00001LATEST CHANGES -
2
David Turnerbfe2f982000-05-12 12:17:15 +00003 - yet another massive grunt work. I've changed the definition of the
4 EXPORT_DEF, EXPORT_FUNC, BASE_DEF & BASE_FUNC macros. These now take
5 an argument, which is the function's return value type.
6
7 This is necessary to compile FreeType as a DLL on Windows and OS/2.
8 Depending on the compiler used, a compiler-specific keyword like __export
9 or __system must be placed before (VisualC++) or after (BorlandC++)
10 the type..
11
12 Of course, this needed a lot of changes throughout the source code
13 to make it compile again... All cleaned up now, apparently..
14
15 Note also that there is a new EXPORT_VAR macro defined to allow the
16 _declaration_ of an exportable public (constant) variable. This is the
17 case of the raster interfaces (see ftraster.h and ftgrays.h), as well
18 as each module's interface (see sfdriver.h, psdriver.h, etc..)
19
20 - new feature: it is now possible to pass extra parameters to font
21 drivers when creating a new face object. For now, this
22 capability is unused. It could however prove to be useful
23 in a near future..
24
25 the FT_Open_Args structure was changes, as well as the internal
26 driver interface (the specific "init_face" module function has now
27 a different signature).
28
29 - updated the tutorial (not finished though).
30
31 - added the declaration of FT_New_Memory_Face in <freetype/freetype.h>, as
32 it was missing from the public header (the implementation was already
33 in "ftobjs.c").
34
35 - the file <freetype/fterrors.h> has been seriously updated in order to
36 allow the automatic generation of error message tables. See the comments
37 within it for more information.
38
David Turnera9c251c2000-05-11 18:36:19 +000039 - major directory hierarchy re-organisation. This was done for two things:
40
41 * first, to ease the "manual" compilation of the library by requiring
42 at lot less include paths :-)
David Turnerbfe2f982000-05-12 12:17:15 +000043
David Turnera9c251c2000-05-11 18:36:19 +000044 * second, to allow external programs to effectively access internal
45 data fields. For example, this can be extremely useful if someone
46 wants to write a font producer or a font manager on top of FreeType.
47
48 Basically, you should now use the 'freetype/' prefix for header inclusion,
49 as in:
50
51 #include <freetype/freetype.h>
52 #include <freetype/ftglyph.h>
53
54 Some new include sub-directories are available:
55
56 a. the "freetype/config" directory, contains two files used to
57 configure the build of the library. Client applications should
58 not need to look at these normally, but they can if they want.
59
60 #include <freetype/config/ftoption.h>
61 #include <freetype/config/ftconfig.h>
62
63 b. the "freetype/internal" directory, contains header files that
64 describes library internals. These are the header files that were
65 previously found in the "src/base" and "src/shared" directories.
66
67
68 As usual, the build system and the demos have been updated to reflect
69 the change..
70
71 Here's a layout of the new directory hierarchy:
72
73 TOP
74 include/
75 freetype/
76 freetype.h
77 ...
78 config/
79 ftoption.h
80 ftconfig.h
81 ftmodule.h
82
83 internal/
84 ftobjs.h
85 ftstream.h
86 ftcalc.h
87 ...
88
89 src/
90 base/
91 ...
92
93 sfnt/
94 psnames/
95 truetype/
96 type1/
97 type1z/
98
99
100 Compiling a module is now much easier, for example, the following should
101 work when in the TOP directory on an ANSI system:
102
103 gcc -c -I./include -I./src/base src/base/ftbase.c
104 gcc -c -I./include -I./src/sfnt src/sfnt/sfnt.c
105 etc..
106
107 (of course, using -Iconfig/<system> if you provide system-specific
108 configuration files).
David Turnerefce08d2000-05-11 18:23:52 +0000109
110
111 - updated the structure of FT_Outline_Funcs in order to allow
112 direct coordinate scaling within the outline decomposition routine
113 (this is important for virtual "on" points with TrueType outlines)
114 + updates to the rasters to support this..
115
116 - updated the OS/2 table loading code in "src/sfnt/ttload.c" in order
117 to support version 2 of the table (see OpenType 1.2 spec)
118
119 - created "include/tttables.h" and "include/t1tables.h" to allow
120 client applications to access some of the SFNT and T1 tables of a
121 face with a procedural interface (see FT_Get_Sfnt_Table())
122 + updates to internal source files to reflect the change..
123
124 - some cleanups in the source code to get rid of warnings when compiling
125 with the "-Wall -W -ansi -pedantic" options in gcc.
126
127 - debugged and moved the smooth renderer to "src/base/ftgrays.c" and
128 its header to "include/ftgrays.h"
129
130 - updated TT_MAX_SUBGLYPHS to 96 as some CJK fonts have composites with
131 up to 80 sub-glyphs !! Thanks to Werner
132
133================================================================================
134OLD CHANGES - 14-apr-2000
David Turner77054f22000-04-14 20:49:52 +0000135
136 - fixed a bug in the TrueType glyph loader that prevented the correct
137 loading of some CJK glyphs in mingli.ttf
138
139 - improved the standard Type 1 hinter in "src/type1"
140
141 - fixed two bugs in the experimental Type 1 driver in "src/type1z"
142 to handle the new XFree86 4.0 fonts (and a few other ones..)
143
144 - the smooth renderer is now complete and supports sub-banding
145 to render large glyphs at high speed. However, it is still located
146 in "demos/src/ftgrays.c" and should move to the library itself
147 in the next beta.. NOTE: The smooth renderer doesn't compile in
148 stand-alone mode anymore, but this should be fixed RSN..
149
150 - introduced convenience functions to more easily deal with glyph
151 images, see "include/ftglyph.h" for more details, as well as the
152 new demo program named "demos/src/ftstring.c" that demonstrates
153 its use
154
155 - implemented FT_LOAD_NO_RECURSE in both the TrueType and Type 1
156 drivers (this is required by the auto-hinter to improve its results).
157
158 - changed the raster interface, in order to allow client applications
159 to provide their own span-drawing callbacks. However, only the
160 smooth renderer supports this. See "FT_Raster_Params" in the
161 file "include/ftimage.h"
162
163 - fixed a small bug in FT_MulFix that caused incorrect transform
164 computation !!
165
166 - Note: The tutorial is out-of-date, grumpf.. :-(
167
168================================================================================
169OLD CHANGES - 12-mar-2000
David Turnerc3c7e7f2000-03-13 14:19:31 +0000170
171 - changed the layout of configuration files : now, all ANSI configuration
172 files are located in "freetype2/config". System-specific over-rides
173 can be placed in "freetype2/config/<system>".
174
175 - moved all configuration macros to "config/ftoption.h"
176
177 - improvements in the Type 1 driver with AFM support
178
179 - changed the fields in the FT_Outline structure : the old "flags"
180 array is re-named "tags", while all ancient flags are encoded into
181 a single unsigned int named "flags".
182
183 - introduced new flags in FT_Outline.flags (see ft_outline_.... enums in
184 "ftimage.h").
185
186 - changed outline functions to "FT_Outline_<action>" syntax
187
188 - added a smooth anti-alias renderer to the demonstration programs
189 - added Mac graphics driver (thanks Just)
190
191 - FT_Open_Face changed in order to received a pointer to a FT_Open_Args
192 descriptor..
193
194 - various cleanups, a few more API functions implemented (see FT_Attach_File)
195
196 - updated some docs
197
198================================================================================
199OLD CHANGES - 22-feb-2000
David Turner58c10b52000-02-22 14:31:42 +0000200
201 - introduced the "psnames" module. It is used to:
202
203 o convert a Postscript glyph name into the equivalent Unicode
204 character code (used by the Type 1 driver(s) to synthetize
205 on the fly a Unicode charmap).
206
207 o provide an interface to retrieve the Postscript names of
208 the Macintosh, Adobe Standard & Adobe Expert character codes.
209 (the Macintosh names are used by the SFNT-module postscript
210 names support routines, while the other two tables are used
211 by the Type 1 driver(s)).
212
213 - introduced the "type1z" alternate Type 1 driver. This is a (still
214 experimental) driver for the Type 1 format that will ultimately
215 replace the one in "src/type1". It uses pattern matching to load
216 data from the font, instead of a finite state analyzer. It works
217 much better than the "old" driver with "broken" fonts. It is also
218 much smaller (under 15 Kb).
219
220 - the Type 1 drivers (both in "src/type1" and "src/type1z") are
221 nearly complete. They both provide automatic Unicode charmap
222 synthesis through the "psnames" module. No re-encoding vector
223 is needed. (note that they still leak memory due to some code
224 missing, and I'm getting lazy).
225
226 Trivial AFM support has been added to read kerning information
227 but wasn't exactly tested as it should ;-)
228
229 - The TrueType glyph loader has been seriously rewritten (see the
230 file "src/truetype/ttgload.c". It is now much, much simpler as
231 well as easier to read, maintain and understand :-) Preliminary
232 versions introduced a memory leak that has been reported by Jack
233 Davis, and is now fixed..
234
235 - introduced the new "ft_glyph_format_plotter", used to represent
236 stroked outlines like Windows "Vector" fonts, and certain Type 1
237 fonts like "Hershey". The corresponding raster will be written
238 soon.
239
240 - FT_New_Memory_Face is gone. Likewise, FT_Open_Face has a new
241 interface that uses a structure to describe the input stream,
242 the driver (if required), etc..
243
244TODO
245 - Write FT_Get_Glyph_Bitmap and FT_Load_Glyph_Bitmap
246
247 - Add a function like FT_Load_Character( face, char_code, load_flags )
248 that would really embbed a call to FT_Get_Char_Index then FT_Load_Glyph
249 to ease developer's work.
250
251 - Update the tutorial !!
252 - consider adding support for Multiple Master fonts in the Type 1
253 drivers.
254
255 - Test the AFM routines of the Type 1 drivers to check that kerning
256 information is returned correctly.
257
258 - write a decent auto-gridding component !! We need this to release
259 FreeType 2.0 gold !
260
261
262----- less urgent needs : ----------
263 - add a CFF/Type2 driver
264 - add a BDF driver
265 - add a FNT/PCF/HBF driver
266 - add a Speedo driver from the X11 sources
267
268
269==============================================================================
270OLDER CHANGES - 27-jan-2000
David Turner633da992000-01-27 14:07:33 +0000271
272 - updated the "sfnt" module interface to allow several SFNT-based
273 drivers to co-exist peacefully
274
275 - updated the "T1_Face" type to better separate Postscript font content
276 from the rest of the FT_Face structure. Might be used later by the
277 CFF/Type2 driver..
278
279 - added an experimental replacement Type 1 driver featuring advanced
280 (and speedy) pattern matching to retrieve the data from postscript
281 fonts.
282
283 - very minor changes in the implementation of FT_Set_Char_Size and
284 FT_Set_Pixel_Sizes (they now implement default to ligthen the
285 font driver's code).
286
287
288=============================================================================
289OLD MESSAGE
290
David Turnerd2b1f351999-12-16 23:11:37 +0000291This file summarizes the changes that occured since the last "beta" of FreeType 2.
292Because the list is important, it has been divided into separate sections:
293
David Turner5951ce91999-12-29 00:53:44 +0000294Table Of Contents:
295
296 I High-Level Interface (easier !)
297 II Directory Structure
298 III Glyph Image Formats
299 IV Build System
300 V Portability
301 VI Font Drivers
David Turnerd2b1f351999-12-16 23:11:37 +0000302
303-----------------------------------------------------------------------------------------
304High-Level Interface :
305
306 The high-level API has been considerably simplified. Here is how :
307
David Turner5951ce91999-12-29 00:53:44 +0000308 - resource objects have disappeared. this means that face objects can
309 now be created with a single function call (see FT_New_Face and
David Turnerd2b1f351999-12-16 23:11:37 +0000310 FT_Open_Face)
311
312 - when calling either FT_New_Face & FT_Open_Face, a size object and a
313 glyph slot object are automatically created for the face, and can be
314 accessed through "face->glyph" and "face->size" if one really needs to.
315 In most cases, there's no need to call FT_New_Size or FT_New_Glyph.
316
317 - similarly, FT_Load_Glyph now only takes a "face" argument (instead of
318 a glyph slot and a size). Also, it's "result" parameter is gone, as
319 the glyph image type is returned in the field "face->glyph.format"
320
321 - the list of available charmaps is directly accessible through
322 "face->charmaps", counting "face->num_charmaps" elements. Each
323 charmap has an 'encoding' field which specifies which known encoding
324 it deals with. Valid values are, for example :
325
326 ft_encoding_unicode (for ASCII, Latin-1 and Unicode)
327 ft_encoding_apple_roman
328 ft_encoding_sjis
329 ft_encoding_adobe_standard
David Turner5951ce91999-12-29 00:53:44 +0000330 ft_encoding_adobe_expert
David Turnerd2b1f351999-12-16 23:11:37 +0000331
332 other values may be added in the future. Each charmap still holds its
333 "platform_id" and "encoding_id" values in case the encoding is too
334 exotic for the current library
335
336
337-----------------------------------------------------------------------------------------
338Directory Structure:
339
340 Should seem obvious to most of you:
341
342 freetype/
343 config/ -- configuration sub-makefiles
344 ansi/
David Turner5951ce91999-12-29 00:53:44 +0000345 unix/ -- platform-specific configuration files
David Turnerd2b1f351999-12-16 23:11:37 +0000346 win32/
347 os2/
348 msdos/
349
350 include/ -- public header files, those to be included directly
351 by client apps
352
353 src/ -- sources of the library
354 base/ -- the base layer
355 sfnt/ -- the sfnt "driver" (see the drivers section below)
356 truetype/ -- the truetype driver
357 type1/ -- the type1 driver
358 shared/ -- some header files shared between drivers
359
360 demos/ -- demos/tools
361
362 docs/ -- documentation (a bit empty for now)
363
364-----------------------------------------------------------------------------------------
365Glyph Image Formats :
366
367 Drivers are now able to register new glyph image formats within the library.
368 For now, the base layer supports of course bitmaps and vector outlines, but
369 one could imagine something different like colored bitmaps, bi-color
370 vectors or wathever else (Metafonts anyone ??).
371
372 See the file `include/ftimage.h'. Note also that the type FT_Raster_Map is
373 gone, and is now replaced by FT_Bitmap, which should encompass all known
374 bitmap types.
375
376 Each new image format must provide at least one "raster", i.e. a module
David Turner5951ce91999-12-29 00:53:44 +0000377 capable of transforming the glyph image into a bitmap. It's also possible
David Turnerd2b1f351999-12-16 23:11:37 +0000378 to change the default raster used for a given glyph image format.
379
380 The default outline scan-converter now uses 128 levels of grays by default,
381 which tends to smooth many things. Note that the demo programs have been
David Turner5951ce91999-12-29 00:53:44 +0000382 updated significantly in order to display these..
David Turnerd2b1f351999-12-16 23:11:37 +0000383
384
385-----------------------------------------------------------------------------------------
386Build system :
387
388 You still need GNU Make to build the library. The build system has been
389 very seriously re-vamped in order to provide things like :
390
391 - automatic host platform detection (reverting to 'config/ansi'
392 if it is not detected, with pseudo-standard compilation flags)
393
394 - the ability to compile from the Makefiles with very different and
395 exotic compilers. Note that linking the library can be difficult for
396 some platforms.
397
398 For example, the file `config/win32/lcclib.bat' is invoked by the
399 build system to create the ".lib" file with LCC-Win32 because its
400 librarian has too many flaws to be invoked directly from the Makefile.
401
402 Here's how it works :
403
404 - the first time you type `make', the build system runs a series of
405 sub-makefiles in order to detect your host platform. It then dumps
406 what it found, and creates a file called `config.mk' in the current
407 directory. This is a sub-Makefile used to define many important Make
408 variables used to build the library.
409
410 - the second time, the build system detects the `config.mk' then use it
411 to build the library. All object files go into 'obj' by default, as
412 well as the library file, but this can easily be changed.
413
414 Note that you can run "make setup" to force another host platform detection
415 even if a `config.mk' is present in the current directory. Another solution
416 is simply to delete the file, then re-run make.
417
418 Finally, the default compiler for all platforms is gcc (for now, this will
419 hopefully changed in the future). You can however specify a different
420 compiler by specifying it after the 'setup' target as in :
421
422 gnumake setup lcc on Win32 to use the LCC compiler
423 gnumake setup visualc on Win32 to use Visual C++
424
425 See the file `config/<system>/detect.mk' for a list of supported compilers
426 for your platforms.
427
428 It should be relatively easy to write new detection rules files and
429 config.mk..
430
431 Finally, to build the demo programs, go to `demos' and launch GNU Make,
432 it will use the `config.mk' in the top directory to build the test
433 programs..
434
435-----------------------------------------------------------------------------------------
436Portability :
437
438 In the previous beta, a single FT_System object was used to encompass
439 all low-level operations like thread synchronisation, memory management
440 and i/o access. This has been greatly simplified :
441
442 - thread synchronisation has been dropped, for the simple reason that
443 the library is already re-entrant, and that if you really need two
444 threads accessing the same FT_Library, you should really synchronize
445 access to it yourself with a simple mutex.
446
447 - memory management is performed through a very simple object called
448 "FT_Memory", which really is a table containing a table of pointers
449 to functions like malloc, realloc and free as well as some user data
450 (closure).
451
452 - resources have disappeared (they created more problems than they
453 solved), and i/o management have been simplified greatly as a
454 result. Streams are defined through FT_Stream objects, which can
455 be either memory-based or disk-based.
456
457 Note that each face has its own stream, which is closed only when
458 the face object is destroyed. Hence, a function like TT_Flush_Face
459 in 1.x cannot be directly supported. However, if you really need
460 something like this, you can easily tailor your own streams to achieve
461 the same feature at a lower level (and use FT_Open_Face instead of
462 FT_New_Face to create the face).
463
464 See the file "include/ftsystem.h" for more details, as well as the
465 implementations found in "config/unix" and "config/ansi".
466
467
468-----------------------------------------------------------------------------------------
David Turner5951ce91999-12-29 00:53:44 +0000469Font Drivers :
470
471
472 The Font Driver interface has been modified in order to support
473 extensions & versioning.
474
475
476 The list of the font drivers that are statically linked to the
477 library at compile time is managed through a new configuration file
478 called `config/<platform>/ftmodule.h'.
479
480 This file is autogenerated when invoking `make modules'. This target
481 will parse all sub-directories of 'src', looking for a "module.mk"
482 rules file, used to describe the driver to the build system.
483
484 Hence, one should call `make modules' each time a font driver is added
485 or removed from the `src' directory.
486
487
488 Finally, this version provides a "pseudo-driver" in `src/sfnt'. This
489 driver doesn't support font files directly, but provides services used
490 by all TrueType-like font drivers. Hence, its code is shared between
491 the TrueType & OpenType font formats, and possibly more formats to
492 come if we're lucky..
David Turnerd2b1f351999-12-16 23:11:37 +0000493
494-----------------------------------------------------------------------------------------
495Extensions support :
David Turner5951ce91999-12-29 00:53:44 +0000496
497 The extensions support is inspired by the one found in 1.x.
498
499 Now, each font driver has its own "extension registry", which lists
500 which extensions are available for the font faces managed by the driver.
501
502 Extension ids are now strings, rather than 4-byte tags, as this is
503 usually more readable..
504
505 Each extension has:
506 - some data, associated to each face object
507 - an interface (table of function pointers)
508
509 An extension that is format-specific should simply register itself
510 to the correct font driver. Here is some example code:
511
512 // Registering an extensions
513 //
514 FT_Error FT_Init_XXXX_Extension( FT_Library library )
515 {
516 FT_DriverInterface* tt_driver;
517
518 driver = FT_Get_Driver( library, "truetype" );
519 if (!driver) return FT_Err_Unimplemented_Feature;
520
521 return FT_Register_Extension( driver, &extension_class );
522 }
523
524
525 // Implementing the extensions
526 //
527 FT_Error FT_Proceed_Extension_XXX( FT_Face face )
528 {
529 FT_XXX_Extension ext;
530 FT_XXX_Extension_Interface ext_interface;
531
532 ext = FT_Get_Extension( face, "extensionid", &ext_interface );
533 if (!ext) return error;
534
535 return ext_interface->do_it(ext);
536 }
David Turnerd2b1f351999-12-16 23:11:37 +0000537