FreeType & GSoC

The FreeType project has successfully participated at Google Summer of Code. Here is our ideas list for future years – if you have another one, 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.

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…

Develop a test framework for checking FreeType's rendering output

Right now, FreeType's rendering results of the current development version are not systematically compared to a baseline version, using continuous integration (CI) or something similar. This is problematic, since rendering regressions can be very easily missed due to subtle differences.

The idea is to select a representative set of reference fonts from font corpora (which already exist mainly for fuzzing). The fonts are used to produce glyph images for various sizes and rendering modes (anti-aliased, B/W, native hinting, auto-hinting, etc.). FreeType can already produce MD5 checksums of glyph images as part of its debugging output; these values should be compared against a baseline version of rendering results. If there are differences, HTML pages should be generated that contain comparison images of the baseline's and the current development version's rendering result, ideally indicating how large the differences between the images are by using some yet to be defined measure.

Difficulty: medium. Requirements: C, Unix build tools. Potential mentors: Werner Lemberg, Alexei Podtelezhnikov, Toshiya Suzuki (FreeType).

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 ftjam, 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.
  • 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 a bunch of 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. Requirements: Various Unix and Windows build tools, in particular GNU make and cmake. Potential mentors: Werner Lemberg, Alexei Podtelezhnikov, Toshiya Suzuki (FreeType).

Port the font-rs/fontdue rendering engine to FreeType

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; of particular interest is that it is much faster than FreeType's anti-aliasing rendering module.

Note that the fontdue Rust package is another rendering engine based on font-rs, and it claims to be even faster. You can find some additional discussion here.

The gist of this project would be to port the Rust code to C and to integrate it into FreeType, providing it as an alternative rendering engine that eventually might replace the old one. It would be necessary to investigate how this can be done, and whether it is feasible at all. In case a port doesn't make sense (for whatever reasons) it should be investigated whether the ideas of the code can be used to re-implement the rasterizer in C.

Difficulty: medium (if porting) to high (if reimplementing). Requirements: Rust, C, Unix build tools. Potential mentors: Werner Lemberg, Alexei Podtelezhnikov, Toshiya Suzuki (FreeType), Raph Levien (Google).

Improve the ‘ftinspect’ demo program (started as a GSoC 2019 project, unfinished)

Right now, FreeType comes with a suite of small graphic tools to test the library, most notably ‘ftview’ and ‘ftgrid’. The used graphics library, while working more or less, is very archaic, not having any comfort that modern GUIs are providing.

To improve this, a new demo program called ‘ftinspect’ was started, based on the Qt GUI toolkit. However, the development is currently stalled, mainly for lack of time.

The idea is to finish ftinspect, handling all aspects of the other demo programs. Currently, it only provides the functionality of ‘ftgrid’.

If the student prefers, the Qt toolkit could be replaced with GTK.

Difficulty: medium. Requirements: C, C++, Qt, Unix build tools. Potential mentor: Werner Lemberg (FreeType).

Replace FreeType's tracing and debugging facilities with an external logging library

FreeType extensively uses a home-brewed tracing solution that mainly relies on the C preprocessor and the fprintf function printing to stderr (see file docs/DEBUG for documentation). However, this simplistic approach is not adequate for all platforms, where stderr is not always easily accessible.

Many freely available tracing and logging libraries exist. It would be necessary to test and check which one meets FreeType's requirements. A few requirements have already been discussed in the mailing list. Note that this discussion is by no means exhaustive.

As a rough guideline, the project could be structured as follows.

  • Get accustomed to FreeType's current tracer/logger, all its current features, and how it is currently being used. Extract a few representative samples from FreeType to help with the next step.
  • Evaluate, compare, and discuss freely available tracing and logging libraries in respect to FreeType's current tracer/logger.
  • Replace the old tracer/logger with the new one within FreeType.
  • Write a brief but precise ‘how-to’ article for FreeType's website about using the new tracer/logger which is aimed at FreeType's developers.

Difficulty: medium. Requirements: C, C++, Unix and Windows build tools. Potential mentors: Werner Lemberg, Alexei Podtelezhnikov, Toshiya Suzuki (FreeType), Armin Hasitzka.

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 i-dot 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 prevented, 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 – the i-dot 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. Requirements: C, and ideally some basic font hinting and rasterization knowledge. Potential mentors: Werner Lemberg, Alexei Podtelezhnikov (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!

Last update: 6-Sept-2020