原始URL: http://www.alfredrossi.com/?p=73
When I was first looking into building FreeType for the iPhone I noticed that there were a lot of people asking questions on if this could be done and how, but there was a clear lack of specific instructions and concrete information on the topic.
It turns out that getting FreeType2 to build on the iPhone is a mostly straight forward (though somewhat lengthy) process if you can figure out how the source fits together. It should be noted that I customize the build here to include only the relevant features needed for basic TTF/OTF loading. If you need to build in some of the more advanced features for any reason check docs/INSTALL.ANYbefore continuing. The file docs/INSTALL.ANY goes a long way toward explaining how the source is structured, and I strongly recommend reviewing this file before trying to build it for yourself.
The first thing to do is to download and extract the FreeType2 source package. I’m using the latest at the time of writing which is version 2.3.9. I don’t suspect that the instructions here are highly version specific, but I can’t promise success with a different version.
If you browse through the source tree you may notice the make files ending in .mk and the Jamfiles. These interfere with our attempts to build and need to be deleted.
Coming from a *nix background I find issuing a recursive find and delete in the root of the extracted package to be the quickest way to take care of it all. However, If you aren’t comfortable with using the console you should do this some other way since serious damage can result if you accidentally issue the command in the wrong folder or make a typo.
find . -name "*.mk" -o -name "Jamfile" -o -name "README" | xargs rm
I include README files in the delete too because Xcode complains about not being able to build them.
The next step is to import the src and include directories from this package into your Xcode project. On my machine I do this by right clicking on the project name under “Groups & Files” and creating a new group called “FreeType”. Once created, right click on the new “FreeType” group and select Add > Existing Files…. Navigate to your extracted source package and select the include andsrc directories.
Importing "src" and "include" directories
At the next dialog select “Copy items into destination group’s folder.” and “Recursively create groups.”
Select "Copy" and "Recursively create groups"
This is what Groups & Files should look like following import.
You should have something like this after import. (Please excuse my Jamfile, as I imported before realizing I needed to clean out the make files.)
The FreeType2 source is factored into components with each component occupying a subdirectory of src. There is also a base subdirectory which holds freetype’s core. If you take a look atdocs/INSTALL.ANY you’ll see that we only need pshinter, psnames, sfnt, cff, raster,smooth, and truetype in addition to baseto handle TTF loading.
By command clicking on each select the groups autofit, bdf, cache, cid, gxvalid,gzip, lzw, otvalid, pcf, pfr, psaux, tools,type1, type42, and winfonts and press thedelete key. I recommend selecting Also Move to Trash, when prompted, to help keep your project directory clean.
In the base/ folder there are c files which correspond to the components we’ve just removed from the project, along with some platform specific files; these need to be disabled as well. Remove ftbdf.c, ftcid.c, ftfstype.c, ftgasp.c,ftgxval.c, ftlcdfil.c, ftmac.c, ftmm.c, ftotval.c, ftpatent.c, ftpfr.c, fttype1.c,ftwinfnt.c, ftxf86.c
These modules also need to be disabled in include/freetype/confg/ftmodule.h. Mine looks like this after commenting out the ones that have been deleted:
//FT_USE_MODULE( FT_Module_Class, autofit_module_class ) FT_USE_MODULE( FT_Driver_ClassRec, tt_driver_class ) //FT_USE_MODULE( FT_Driver_ClassRec, t1_driver_class ) FT_USE_MODULE( FT_Driver_ClassRec, cff_driver_class ) //FT_USE_MODULE( FT_Driver_ClassRec, t1cid_driver_class ) //FT_USE_MODULE( FT_Driver_ClassRec, pfr_driver_class ) //FT_USE_MODULE( FT_Driver_ClassRec, t42_driver_class ) //FT_USE_MODULE( FT_Driver_ClassRec, winfnt_driver_class ) //FT_USE_MODULE( FT_Driver_ClassRec, pcf_driver_class ) //FT_USE_MODULE( FT_Module_Class, psaux_module_class ) FT_USE_MODULE( FT_Module_Class, psnames_module_class ) FT_USE_MODULE( FT_Module_Class, pshinter_module_class ) FT_USE_MODULE( FT_Renderer_Class, ft_raster1_renderer_class ) FT_USE_MODULE( FT_Module_Class, sfnt_module_class ) 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 ) //FT_USE_MODULE( FT_Driver_ClassRec, bdf_driver_class )
If you tried to build at this point things would go horribly wrong. I get nearly 6000 errors and around 200 warnings, but everything is not as bad as it seems. One thing that’s apparent at this point if you’ve tried the build is that FreeType’s include directory isn’t in the search path.
To fix the include directory problem, click the app name under Targets inGroups & Files and click Info at the top of the Xcode window. Make sure that you’re editing the settings for All Configurations under the Configurationsdrop down box. Enter into the Build tab and scroll down to Header Search Paths under Search Paths. If you peek at the project directory you’ll notice that your src and include directories got pulled into the root of your project. Add a new search path for include/. NOTE: It probably makes sense to reorganize your project directory so that these appear in a “freetype” directory or something to that effect, but for simplicity we won’t bother with that here.
Add freetype's include directory to our include search path.
Since each time we build our app we’re building FreeType as well we need to make sure that FreeType includes the headers it needs to build the internals. Otherwise, just the include files for linking against FreeType are present during compilation, which are insufficient to build FreeType itself. Checking the bottom of include/freetype/config/ftheader.h we note thatFT2_BUILD_LIBRARYneeds to be defined.
To set FT2_BUILD_LIBRARY, with the Build tab still selected we click on theGear Icon in the lower left corner of the info window and select Add User-Defined Setting. Give the setting the name OTHER_CFLAGS and set it’s value to -DFT_BUILD_LIBRARY. We also need to set -DDARWIN_NO_CARBON to keep it from trying to use the base/ftmac.c file we deleted. So the following should be set for OTHER_CFLAGS
-DFT2_BUILD_LIBRARY -DDARWIN_NO_CARBON
Setting -DFT2_BUILD_LIBRARY in the info window.
At this point it should almost build for the simulator. Compilation should succeed leaving you with linker errors. It turns out that some of the c files are actually being included directly from other c files, leading to a clashing of symbol names when the two files are linked together. One resolution to this is to tell Xcode that these c files are actually header files.
To change the filetype right click the file in Groups & Files and select Get Infoand change the value in the File Type to sourecode.c.h.
Changing the Xcode File Type of ftcalc.c
The following files in base/ are being used as header files and need to have their Xcode File Type changed: base/ftadvanc.c, base/ftcalc.c base/ftgloadr.c,base/ftnames.c, base/ftobjs.c, base/ftoutln.c, base/ftrfork.c, base/ftstream.c,base/fttrigon.c, base/ftutil.c.
For each component only the c file which matches the component name needs to be built and all other c files in the component directory can be treated as an include. To be specific every .c file in cff/, pshinter/, psmodule/,raster/,sfnt/, smooth/, truetype/ except cff.c, pshinter.c, psnames.c, raster.c, sfnt.c,smooth.c and truetype.c respectively.
The downside here is that Xcode will now issue a warning for each file that it does not know how to compile it. These are nothing more than a minor annoyance, and can be safely ignored.
At this point the source should build for the simulator. If you tried to build it part way through and you’re now getting linker errors you may have to clean the build.
If you try to build it for the device, though, it will fail on some inlined assembly in the FT_MulFix_arm routine in include/freetype/config/ftconfig.h around line 323 or so. Changing asm to __asm__ does the trick. It should now look like this:
static __inline__ FT_Int32 FT_MulFix_arm( FT_Int32 a, FT_Int32 b ) { register FT_Int32 t, t2; __asm__ __volatile__ ( "smull %1, %2, %4, %3/n/t" /* (lo=%1,hi=%2) = a*b */ "mov %0, %2, asr #31/n/t" /* %0 = (hi >> 31) */ "add %0, %0, #0x8000/n/t" /* %0 += 0x8000 */ "adds %1, %1, %0/n/t" /* %1 += %0 */ "adc %2, %2, #0/n/t" /* %2 += carry */ "mov %0, %1, lsr #16/n/t" /* %0 = %1 >> 16 */ "orr %0, %2, lsl #16/n/t" /* %0 |= %2 << 16 */ : "=r"(a), "=&r"(t2), "=&r"(t) : "r"(a), "r"(b) ); return a; }
And that should do it. You should now be able to load fonts from resources and use FT_New_Memory_Face to load the font data into freetype.