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