David Turner | 58c10b5 | 2000-02-22 14:31:42 +0000 | [diff] [blame^] | 1 | LATEST CHANGES - 22-feb-2000 |
| 2 | |
| 3 | - introduced the "psnames" module. It is used to: |
| 4 | |
| 5 | o convert a Postscript glyph name into the equivalent Unicode |
| 6 | character code (used by the Type 1 driver(s) to synthetize |
| 7 | on the fly a Unicode charmap). |
| 8 | |
| 9 | o provide an interface to retrieve the Postscript names of |
| 10 | the Macintosh, Adobe Standard & Adobe Expert character codes. |
| 11 | (the Macintosh names are used by the SFNT-module postscript |
| 12 | names support routines, while the other two tables are used |
| 13 | by the Type 1 driver(s)). |
| 14 | |
| 15 | - introduced the "type1z" alternate Type 1 driver. This is a (still |
| 16 | experimental) driver for the Type 1 format that will ultimately |
| 17 | replace the one in "src/type1". It uses pattern matching to load |
| 18 | data from the font, instead of a finite state analyzer. It works |
| 19 | much better than the "old" driver with "broken" fonts. It is also |
| 20 | much smaller (under 15 Kb). |
| 21 | |
| 22 | - the Type 1 drivers (both in "src/type1" and "src/type1z") are |
| 23 | nearly complete. They both provide automatic Unicode charmap |
| 24 | synthesis through the "psnames" module. No re-encoding vector |
| 25 | is needed. (note that they still leak memory due to some code |
| 26 | missing, and I'm getting lazy). |
| 27 | |
| 28 | Trivial AFM support has been added to read kerning information |
| 29 | but wasn't exactly tested as it should ;-) |
| 30 | |
| 31 | - The TrueType glyph loader has been seriously rewritten (see the |
| 32 | file "src/truetype/ttgload.c". It is now much, much simpler as |
| 33 | well as easier to read, maintain and understand :-) Preliminary |
| 34 | versions introduced a memory leak that has been reported by Jack |
| 35 | Davis, and is now fixed.. |
| 36 | |
| 37 | - introduced the new "ft_glyph_format_plotter", used to represent |
| 38 | stroked outlines like Windows "Vector" fonts, and certain Type 1 |
| 39 | fonts like "Hershey". The corresponding raster will be written |
| 40 | soon. |
| 41 | |
| 42 | - FT_New_Memory_Face is gone. Likewise, FT_Open_Face has a new |
| 43 | interface that uses a structure to describe the input stream, |
| 44 | the driver (if required), etc.. |
| 45 | |
| 46 | TODO |
| 47 | - Write FT_Get_Glyph_Bitmap and FT_Load_Glyph_Bitmap |
| 48 | |
| 49 | - Add a function like FT_Load_Character( face, char_code, load_flags ) |
| 50 | that would really embbed a call to FT_Get_Char_Index then FT_Load_Glyph |
| 51 | to ease developer's work. |
| 52 | |
| 53 | - Update the tutorial !! |
| 54 | - consider adding support for Multiple Master fonts in the Type 1 |
| 55 | drivers. |
| 56 | |
| 57 | - Test the AFM routines of the Type 1 drivers to check that kerning |
| 58 | information is returned correctly. |
| 59 | |
| 60 | - write a decent auto-gridding component !! We need this to release |
| 61 | FreeType 2.0 gold ! |
| 62 | |
| 63 | |
| 64 | ----- less urgent needs : ---------- |
| 65 | - add a CFF/Type2 driver |
| 66 | - add a BDF driver |
| 67 | - add a FNT/PCF/HBF driver |
| 68 | - add a Speedo driver from the X11 sources |
| 69 | |
| 70 | |
| 71 | ============================================================================== |
| 72 | OLDER CHANGES - 27-jan-2000 |
David Turner | 633da99 | 2000-01-27 14:07:33 +0000 | [diff] [blame] | 73 | |
| 74 | - updated the "sfnt" module interface to allow several SFNT-based |
| 75 | drivers to co-exist peacefully |
| 76 | |
| 77 | - updated the "T1_Face" type to better separate Postscript font content |
| 78 | from the rest of the FT_Face structure. Might be used later by the |
| 79 | CFF/Type2 driver.. |
| 80 | |
| 81 | - added an experimental replacement Type 1 driver featuring advanced |
| 82 | (and speedy) pattern matching to retrieve the data from postscript |
| 83 | fonts. |
| 84 | |
| 85 | - very minor changes in the implementation of FT_Set_Char_Size and |
| 86 | FT_Set_Pixel_Sizes (they now implement default to ligthen the |
| 87 | font driver's code). |
| 88 | |
| 89 | |
| 90 | ============================================================================= |
| 91 | OLD MESSAGE |
| 92 | |
David Turner | d2b1f35 | 1999-12-16 23:11:37 +0000 | [diff] [blame] | 93 | This file summarizes the changes that occured since the last "beta" of FreeType 2. |
| 94 | Because the list is important, it has been divided into separate sections: |
| 95 | |
David Turner | 5951ce9 | 1999-12-29 00:53:44 +0000 | [diff] [blame] | 96 | Table Of Contents: |
| 97 | |
| 98 | I High-Level Interface (easier !) |
| 99 | II Directory Structure |
| 100 | III Glyph Image Formats |
| 101 | IV Build System |
| 102 | V Portability |
| 103 | VI Font Drivers |
David Turner | d2b1f35 | 1999-12-16 23:11:37 +0000 | [diff] [blame] | 104 | |
| 105 | ----------------------------------------------------------------------------------------- |
| 106 | High-Level Interface : |
| 107 | |
| 108 | The high-level API has been considerably simplified. Here is how : |
| 109 | |
David Turner | 5951ce9 | 1999-12-29 00:53:44 +0000 | [diff] [blame] | 110 | - resource objects have disappeared. this means that face objects can |
| 111 | now be created with a single function call (see FT_New_Face and |
David Turner | d2b1f35 | 1999-12-16 23:11:37 +0000 | [diff] [blame] | 112 | FT_Open_Face) |
| 113 | |
| 114 | - when calling either FT_New_Face & FT_Open_Face, a size object and a |
| 115 | glyph slot object are automatically created for the face, and can be |
| 116 | accessed through "face->glyph" and "face->size" if one really needs to. |
| 117 | In most cases, there's no need to call FT_New_Size or FT_New_Glyph. |
| 118 | |
| 119 | - similarly, FT_Load_Glyph now only takes a "face" argument (instead of |
| 120 | a glyph slot and a size). Also, it's "result" parameter is gone, as |
| 121 | the glyph image type is returned in the field "face->glyph.format" |
| 122 | |
| 123 | - the list of available charmaps is directly accessible through |
| 124 | "face->charmaps", counting "face->num_charmaps" elements. Each |
| 125 | charmap has an 'encoding' field which specifies which known encoding |
| 126 | it deals with. Valid values are, for example : |
| 127 | |
| 128 | ft_encoding_unicode (for ASCII, Latin-1 and Unicode) |
| 129 | ft_encoding_apple_roman |
| 130 | ft_encoding_sjis |
| 131 | ft_encoding_adobe_standard |
David Turner | 5951ce9 | 1999-12-29 00:53:44 +0000 | [diff] [blame] | 132 | ft_encoding_adobe_expert |
David Turner | d2b1f35 | 1999-12-16 23:11:37 +0000 | [diff] [blame] | 133 | |
| 134 | other values may be added in the future. Each charmap still holds its |
| 135 | "platform_id" and "encoding_id" values in case the encoding is too |
| 136 | exotic for the current library |
| 137 | |
| 138 | |
| 139 | ----------------------------------------------------------------------------------------- |
| 140 | Directory Structure: |
| 141 | |
| 142 | Should seem obvious to most of you: |
| 143 | |
| 144 | freetype/ |
| 145 | config/ -- configuration sub-makefiles |
| 146 | ansi/ |
David Turner | 5951ce9 | 1999-12-29 00:53:44 +0000 | [diff] [blame] | 147 | unix/ -- platform-specific configuration files |
David Turner | d2b1f35 | 1999-12-16 23:11:37 +0000 | [diff] [blame] | 148 | win32/ |
| 149 | os2/ |
| 150 | msdos/ |
| 151 | |
| 152 | include/ -- public header files, those to be included directly |
| 153 | by client apps |
| 154 | |
| 155 | src/ -- sources of the library |
| 156 | base/ -- the base layer |
| 157 | sfnt/ -- the sfnt "driver" (see the drivers section below) |
| 158 | truetype/ -- the truetype driver |
| 159 | type1/ -- the type1 driver |
| 160 | shared/ -- some header files shared between drivers |
| 161 | |
| 162 | demos/ -- demos/tools |
| 163 | |
| 164 | docs/ -- documentation (a bit empty for now) |
| 165 | |
| 166 | ----------------------------------------------------------------------------------------- |
| 167 | Glyph Image Formats : |
| 168 | |
| 169 | Drivers are now able to register new glyph image formats within the library. |
| 170 | For now, the base layer supports of course bitmaps and vector outlines, but |
| 171 | one could imagine something different like colored bitmaps, bi-color |
| 172 | vectors or wathever else (Metafonts anyone ??). |
| 173 | |
| 174 | See the file `include/ftimage.h'. Note also that the type FT_Raster_Map is |
| 175 | gone, and is now replaced by FT_Bitmap, which should encompass all known |
| 176 | bitmap types. |
| 177 | |
| 178 | Each new image format must provide at least one "raster", i.e. a module |
David Turner | 5951ce9 | 1999-12-29 00:53:44 +0000 | [diff] [blame] | 179 | capable of transforming the glyph image into a bitmap. It's also possible |
David Turner | d2b1f35 | 1999-12-16 23:11:37 +0000 | [diff] [blame] | 180 | to change the default raster used for a given glyph image format. |
| 181 | |
| 182 | The default outline scan-converter now uses 128 levels of grays by default, |
| 183 | which tends to smooth many things. Note that the demo programs have been |
David Turner | 5951ce9 | 1999-12-29 00:53:44 +0000 | [diff] [blame] | 184 | updated significantly in order to display these.. |
David Turner | d2b1f35 | 1999-12-16 23:11:37 +0000 | [diff] [blame] | 185 | |
| 186 | |
| 187 | ----------------------------------------------------------------------------------------- |
| 188 | Build system : |
| 189 | |
| 190 | You still need GNU Make to build the library. The build system has been |
| 191 | very seriously re-vamped in order to provide things like : |
| 192 | |
| 193 | - automatic host platform detection (reverting to 'config/ansi' |
| 194 | if it is not detected, with pseudo-standard compilation flags) |
| 195 | |
| 196 | - the ability to compile from the Makefiles with very different and |
| 197 | exotic compilers. Note that linking the library can be difficult for |
| 198 | some platforms. |
| 199 | |
| 200 | For example, the file `config/win32/lcclib.bat' is invoked by the |
| 201 | build system to create the ".lib" file with LCC-Win32 because its |
| 202 | librarian has too many flaws to be invoked directly from the Makefile. |
| 203 | |
| 204 | Here's how it works : |
| 205 | |
| 206 | - the first time you type `make', the build system runs a series of |
| 207 | sub-makefiles in order to detect your host platform. It then dumps |
| 208 | what it found, and creates a file called `config.mk' in the current |
| 209 | directory. This is a sub-Makefile used to define many important Make |
| 210 | variables used to build the library. |
| 211 | |
| 212 | - the second time, the build system detects the `config.mk' then use it |
| 213 | to build the library. All object files go into 'obj' by default, as |
| 214 | well as the library file, but this can easily be changed. |
| 215 | |
| 216 | Note that you can run "make setup" to force another host platform detection |
| 217 | even if a `config.mk' is present in the current directory. Another solution |
| 218 | is simply to delete the file, then re-run make. |
| 219 | |
| 220 | Finally, the default compiler for all platforms is gcc (for now, this will |
| 221 | hopefully changed in the future). You can however specify a different |
| 222 | compiler by specifying it after the 'setup' target as in : |
| 223 | |
| 224 | gnumake setup lcc on Win32 to use the LCC compiler |
| 225 | gnumake setup visualc on Win32 to use Visual C++ |
| 226 | |
| 227 | See the file `config/<system>/detect.mk' for a list of supported compilers |
| 228 | for your platforms. |
| 229 | |
| 230 | It should be relatively easy to write new detection rules files and |
| 231 | config.mk.. |
| 232 | |
| 233 | Finally, to build the demo programs, go to `demos' and launch GNU Make, |
| 234 | it will use the `config.mk' in the top directory to build the test |
| 235 | programs.. |
| 236 | |
| 237 | ----------------------------------------------------------------------------------------- |
| 238 | Portability : |
| 239 | |
| 240 | In the previous beta, a single FT_System object was used to encompass |
| 241 | all low-level operations like thread synchronisation, memory management |
| 242 | and i/o access. This has been greatly simplified : |
| 243 | |
| 244 | - thread synchronisation has been dropped, for the simple reason that |
| 245 | the library is already re-entrant, and that if you really need two |
| 246 | threads accessing the same FT_Library, you should really synchronize |
| 247 | access to it yourself with a simple mutex. |
| 248 | |
| 249 | - memory management is performed through a very simple object called |
| 250 | "FT_Memory", which really is a table containing a table of pointers |
| 251 | to functions like malloc, realloc and free as well as some user data |
| 252 | (closure). |
| 253 | |
| 254 | - resources have disappeared (they created more problems than they |
| 255 | solved), and i/o management have been simplified greatly as a |
| 256 | result. Streams are defined through FT_Stream objects, which can |
| 257 | be either memory-based or disk-based. |
| 258 | |
| 259 | Note that each face has its own stream, which is closed only when |
| 260 | the face object is destroyed. Hence, a function like TT_Flush_Face |
| 261 | in 1.x cannot be directly supported. However, if you really need |
| 262 | something like this, you can easily tailor your own streams to achieve |
| 263 | the same feature at a lower level (and use FT_Open_Face instead of |
| 264 | FT_New_Face to create the face). |
| 265 | |
| 266 | See the file "include/ftsystem.h" for more details, as well as the |
| 267 | implementations found in "config/unix" and "config/ansi". |
| 268 | |
| 269 | |
| 270 | ----------------------------------------------------------------------------------------- |
David Turner | 5951ce9 | 1999-12-29 00:53:44 +0000 | [diff] [blame] | 271 | Font Drivers : |
| 272 | |
| 273 | |
| 274 | The Font Driver interface has been modified in order to support |
| 275 | extensions & versioning. |
| 276 | |
| 277 | |
| 278 | The list of the font drivers that are statically linked to the |
| 279 | library at compile time is managed through a new configuration file |
| 280 | called `config/<platform>/ftmodule.h'. |
| 281 | |
| 282 | This file is autogenerated when invoking `make modules'. This target |
| 283 | will parse all sub-directories of 'src', looking for a "module.mk" |
| 284 | rules file, used to describe the driver to the build system. |
| 285 | |
| 286 | Hence, one should call `make modules' each time a font driver is added |
| 287 | or removed from the `src' directory. |
| 288 | |
| 289 | |
| 290 | Finally, this version provides a "pseudo-driver" in `src/sfnt'. This |
| 291 | driver doesn't support font files directly, but provides services used |
| 292 | by all TrueType-like font drivers. Hence, its code is shared between |
| 293 | the TrueType & OpenType font formats, and possibly more formats to |
| 294 | come if we're lucky.. |
David Turner | d2b1f35 | 1999-12-16 23:11:37 +0000 | [diff] [blame] | 295 | |
| 296 | ----------------------------------------------------------------------------------------- |
| 297 | Extensions support : |
David Turner | 5951ce9 | 1999-12-29 00:53:44 +0000 | [diff] [blame] | 298 | |
| 299 | The extensions support is inspired by the one found in 1.x. |
| 300 | |
| 301 | Now, each font driver has its own "extension registry", which lists |
| 302 | which extensions are available for the font faces managed by the driver. |
| 303 | |
| 304 | Extension ids are now strings, rather than 4-byte tags, as this is |
| 305 | usually more readable.. |
| 306 | |
| 307 | Each extension has: |
| 308 | - some data, associated to each face object |
| 309 | - an interface (table of function pointers) |
| 310 | |
| 311 | An extension that is format-specific should simply register itself |
| 312 | to the correct font driver. Here is some example code: |
| 313 | |
| 314 | // Registering an extensions |
| 315 | // |
| 316 | FT_Error FT_Init_XXXX_Extension( FT_Library library ) |
| 317 | { |
| 318 | FT_DriverInterface* tt_driver; |
| 319 | |
| 320 | driver = FT_Get_Driver( library, "truetype" ); |
| 321 | if (!driver) return FT_Err_Unimplemented_Feature; |
| 322 | |
| 323 | return FT_Register_Extension( driver, &extension_class ); |
| 324 | } |
| 325 | |
| 326 | |
| 327 | // Implementing the extensions |
| 328 | // |
| 329 | FT_Error FT_Proceed_Extension_XXX( FT_Face face ) |
| 330 | { |
| 331 | FT_XXX_Extension ext; |
| 332 | FT_XXX_Extension_Interface ext_interface; |
| 333 | |
| 334 | ext = FT_Get_Extension( face, "extensionid", &ext_interface ); |
| 335 | if (!ext) return error; |
| 336 | |
| 337 | return ext_interface->do_it(ext); |
| 338 | } |
David Turner | d2b1f35 | 1999-12-16 23:11:37 +0000 | [diff] [blame] | 339 | |