FreeType & GSoC

The FreeType project participates in Google Summer of Code 2023. Here is our list of possible projects – if you have more ideas, please write to our mailing list so that we can discuss your suggestions, eventually adding them to this page.

If you are interested to participate as a student, please also contact us via the mailing list. It's probably best if you subscribe to it.

Note that there are half-time and full-time projects. Most of our projects are modular, more or less, allowing students to propose a subset of the mentioned targets if this appears appropriate.

Before contacting us, however, you should get really acquainted with the topic you would like to start with – in particular, search the mailing list archive and/or do some googling! We don't want to answer questions like “I'm interested in your project, I want to contribute, please tell me what to do!” again and again…

Update FreeType's build systems

Due to historical reasons, FreeType's build systems are strange to newcomers. The default one is based on GNU make, also integrating autoconf support. Alternatives are generic build files for cmake and meson, together with special support files for MS Visual Studio, OpenVMS, and some even more exotic, old platforms.

This project is intended to update the build systems. Here is a preliminary list of tasks.

• Investigate which build systems should be retained, modified, added, removed, etc., approaching the project with a conservative point of view. This needs intensive contact with the mailing list(s) to identify the needs of users and the preferences of developers. Right now, we tend to move to meson.
• Check software distributions for different platforms and analyze how FreeType's build systems are modified for integration. This might give further hints on necessary changes or adaptations.
• Especially for cmake support, there are some issues in Freetype's bug tracker that should be taken care of.
• Modernize and update the build system based on the outcome of the previous items. This might also include changes in the directory structure of the source files if necessary and useful.

Difficulty: medium. Size: 175h/350h. Requirements: Various Unix and Windows build tools, in particular GNU make, cmake, and meson. Potential mentors: Werner Lemberg, Alexei Podtelezhnikov, Toshiya Suzuki (FreeType).

Integrate FreeType with alternative rendering engines

Raph Levien has developed font-rs, an experimental font renderer written in the Rust programming language. A blogpost describes some of its features in more detail. It claims to be much faster than FreeType's anti-aliasing rendering module due to SIMD optimizations.

Note that the fontdue Rust package is another rendering engine based on font-rs, and it claims to be even faster and is actively developed. You can find some additional discussion here. Another project inspired by font-rs is Pathfinder, which takes advantages of GPU rendering.

The project is continuing and eventually finalizing a GSoC 2022 contribution (which couldn't be finished then properly due to circumstances out of the student's control) about implementing an alternative FT_Renderer module in C that can take priority over the native FreeType rasterizer. It should either wrap the calls to a linked precompiled object or port the Rust code to C. It requires in-depth feasibility analysis of either approach and a good understanding of FreeType's architectural details.

Difficulty: high. Size: 175h/350h. Requirements: Rust, C, Unix build tools. Potential mentors: Werner Lemberg, Alexei Podtelezhnikov, Toshiya Suzuki (FreeType), Raph Levien (Google).

Add a ‘capability database’ to FreeType's auto-hinter

At smaller sizes, usually in the range 12ppem to 20ppem, it can happen that separate outlines of glyphs touch each other (mainly caused by rounding issues), making glyphs illegible. A typical example is glyph ‘i’, where the vertical space between the dot on the i and the body must have a certain size to let the reader's eye separate the two parts. [Note that the auto-hinter's capability to hint glyphs smaller than 12ppem is very limited in general and thus not part of this project description.]

Another example is the tilde accent, ‘~’, used in languages like Spanish: Even at smaller sizes the wiggle of the accent shape must be preserved, otherwise it can happen that a character like ‘ã’ looks like ‘ā’.

There are numerous other cases where some knowledge of the shape of a given glyph might help the auto-hinter improve the hinting, irrespective of the font shape or family – coming back to glyph ‘i’, the dot on the i and its body must be separate for virtually all available fonts.

The project consists of the following parts.

• Identify hinting problems of the auto-hinter related to shape distortion and accent positioning. A good starting point is the FreeType bug database.
• Collect necessary adjustments. For the above two examples, it would be necessary (a) to tell the auto-hinter that there must be a certain vertical distance between the body and its accent, and (b) to distort some glyph shapes intentionally so that rasterization at small ppem values gives decent results.
• Invent a database format (to be compiled into the library) that describes the necessary actions. Basically, this would be a key-value table, where the key is the Unicode character code of the affected glyph, and the value is a list of necessary actions.
• Add a mechanism to the auto-hinter to read the database, and to apply the action (shift, distort, whatever) to the affected glyph outlines if necessary. This last feature is the non-trivial part of this project.

Difficulty: medium to high. Size: 350h. Requirements: C, and ideally some basic font hinting and rasterization knowledge. Potential mentors: Werner Lemberg, Alexei Podtelezhnikov (FreeType).

Integrate ftbench into FreeType's build structure(s)

The ftbench demo program (source code) is a small tool that benchmarks the performance of various FreeType library functions. The aim of this project is to integrate it into FreeType's build system(s) so that the timings of a baseline (for example, a released version) can be easily compared with the timings of the current git version. Eventually, the results should be integrated into FreeType's CI as provided by gitlab.

There are many approaches possible to accomplish the project. For example, the raw results emitted by ftbench could be post-processed by a script to produce a nice-looking HTML page. Another possibility is to modify the ftbench program directly to emit HTML code.

Difficulty: medium. Size: 175h/350h. Requirements: C, Unix build tools, HTML. Potential mentors: Werner Lemberg, Alexei Podtelezhnikov, Toshiya Suzuki (FreeType).

Integrate VFlib's TeX font support into FreeType

A GSoC 2018 project was a first try to integrate VFlib into FreeType. This library contains mature support for TeX's bitmap formats (in particular GF and PK fonts, together with TFM metric files and VF virtual fonts).

The project would be as follows.

• Evaluate the existing code to find out whether it can be used as a starting point to complete the begun task, this is, to merge VFlib's source code into FreeType, thus providing new modules to handle TeX bitmap fonts.
• Evaluate different routes if necessary. For example, it might be easier to provide simple and small wrapper modules that call VFlib functions. In other words, this wouldn't integrate the code of VFlib but have it as an external dependency.
• Create modules.

The canonic references for the PK, GF, TFM, and VF font formats are the source code of the TeX tools gftopk (for PK), gftype (for GF), tftopl (for TFM), and vftovp (for VF).

Difficulty: medium (high for VF support). Size: 175h/350h. Requirements: C, Unix build tools, knowledge of TeX infrastructure (using TeXLive is recommended). Potential mentor: Werner Lemberg (FreeType).

Do you have more ideas? Please write to our mailing list so that we can discuss your suggestions, eventually adding them to the list!