# FreeType is a C font rasteriser, and its GitHub mirror is not where you file bugs > FreeType renders fonts, producing glyph images from most vector and bitmap font formats, and its GitHub repository is an official mirror of the GitLab project with an explicit warning not to open pull requests or issues there. The engine is small, portable and configurable, and the build system offers several ways in. **freetype/freetype** — Official mirror of https://gitlab.freedesktop.org/freetype/freetype – please DO NOT add pull requests here or open issues! - Repository: https://github.com/freetype/freetype - Stars: 926 · Forks: 446 - Language: C - License: NOASSERTION - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/freetype-freetype ## The GitHub repository says do not file issues here The repository description is unusually direct. It is the official mirror of the project hosted on gitlab.freedesktop.org, and it asks in capitals that you do not add pull requests there or open issues there. That instruction is not bureaucracy. The canonical development happens on the freedesktop GitLab instance, and the README repeats the same routing in prose. Bug reports go to the GitLab issue tracker, and that GitLab instance also supports confidential reports, which matters for a project that parses untrusted font files. The README says that reporting by email to the public freetype-devel list is less preferable, and it asks for a detailed explanation of the problem, noting that there is nothing worse than receiving a terse message that only says it doesn't work. Patches follow the same pattern. For larger changes, provide merge requests on GitLab. Alternatively, send patches to the freetype-devel mailing list, with thanks in advance for the work on improving FreeType. So for anyone evaluating the project, the practical consequence is that the GitHub tree is a mirror of the upstream development line, not a fork you would propose changes to. Reading it, tracking it and cloning it are all fine. Contributing to it is not. The version in the tree is 2.15.0, and the copyright notice at the end of the README covers 2006 through 2026 and names David Turner, Robert Wilhelm and Werner Lemberg. ## What the library actually produces: glyph images from font files FreeType is a freely available software library to render fonts. It is written in C and described as small, efficient, highly customizable and portable, while capable of producing high-quality output, in the form of glyph images, of most vector and bitmap font formats. That last clause is the scope of the project. This is the rasterisation layer. It takes a font file and turns characters into images you can draw, and it handles both outline formats and bitmap formats. It is not a text layout engine, and it is not a shaping library. Understanding that boundary is the fastest way to know whether you want it. The word customizable is doing real work in that description. The source tree is organised around modules, with a modules.cfg file at the top level and module directories under src/, so the set of font drivers you compile in is a configuration decision rather than a fixed list. The include/ directory holds the public headers, the docs/ directory holds the reference and the changelog, and tests/ holds the test suite. The engine is also designed to be embedded. The objs/ directory at the top level is the default object output location for the build, which tells you the project expects to be compiled in place, not consumed as a prebuilt binary. For an application that needs to draw text through a platform's own text rendering, FreeType is often already underneath. For an application that needs the glyph bitmaps, the outlines, or the metrics directly, it is the layer you call. ## Cloning, not downloading, if you build from git The README has a warning for anyone who builds from the source repository rather than from a distribution bundle, and it is easy to miss. For using the FreeType git repository instead of a distribution bundle, you are asked to read the file README.git. The note is explicit: you have to actually clone the repository, using a snapshot will not work, and the instruction adds, in other words, don't use gitlab's Download button. That is a practical constraint on CI. A tarball of the repository at a given commit is not a usable source for the build, because the generated build system files are produced by the project's own tooling and the autogen step needs the full history and submodules. The repository carries a .gitmodules file, so the submodule contents come along with a proper clone. The top-level layout supports that reading. There is an autogen.sh script, a configure script, a CMakeLists.txt, a meson.build with meson_options.txt, a Makefile, a mkfile, and MSBuild.sln with MSBuild.rsp for the Visual Studio build. Four build routes, and the git tree carries the machinery to produce the autotools route. The Makefile at the top level is deliberately thin. It sets the project name to freetype and the project title to FreeType, defines TOP_DIR defaulting to the current directory, defines OBJ_DIR defaulting to the top directory plus objs, and then includes the toplevel make fragment from the builds directory. ```bash PROJECT := freetype PROJECT_TITLE := FreeType TOP_DIR ?= . OBJ_DIR ?= $(TOP_DIR)/objs include $(TOP_DIR)/builds/toplevel.mk ``` The comment on TOP_DIR says it holds the path to the topmost directory in the project engine source hierarchy, and that if it is not defined it defaults to the current directory. ## One engine, several build systems, and the docs live in three places Choosing how to build is a separate decision from whether to use the library, and the repository supports more than one answer. The autotools route runs through autogen.sh and the configure script. The Meson route uses meson.build and meson_options.txt. The CMake route uses CMakeLists.txt, and there is a Visual Studio solution for the Windows build. The mkfile and the vms_make.com file cover other legacy toolchains. The tests/ directory holds the test suite that these builds run. Documentation is split three ways, which is the other place a new user loses time. The first location is inside the repository. The API reference is located in the directory docs/reference, with index.html as the top entry point, and the README carries an honest caveat that the search function for locally installed documentation does not work because of cross-site scripting issues. The README also points at docs/CHANGES, saying it contains important information, and at the docs/INSTALL* files for installation instructions. The second location is a separate documentation package. It is available from the project's download site as one of three files. ```bash freetype-doc-2.15.0.tar.xz freetype-doc-2.15.0.tar.gz ftdoc2150.zip ``` The third is online, where the documentation can be viewed at the project's documentation URL. That is an unusual amount of documentation for a C library of this kind, and it is worth using rather than skipping. The API reference in the repository tells you what the calls do, and the separate package and the online version are what you consult when you are trying to work out how to use them rather than what they are called. ## Where FreeType is the wrong tool The clearest mistake is expecting a text engine here. FreeType produces glyph images from font files. If what you need is a line of text laid out for display, with the right glyphs selected for the script, the right ordering for right-to-left text, and the right substitutions applied, then that work happens in a layer above this one, and a library that only rasterises will not do it for you. Choosing FreeType for a full text layout job means writing the layout part yourself. The second case is a platform that already does the job. If your operating system offers a text rendering API that returns the glyphs you need, adding a font rasteriser to the stack duplicates work you could have delegated. The value of FreeType is control, and that control has a cost in code you now own. The third case is a project that cannot take on the C dependency and its update responsibility. This is a C library with a portability surface that spans Meson, CMake, autotools, Visual Studio and older toolchains, and it parses font files. Font parsing is the kind of code where a security fix matters, so a vendored copy is a copy you will have to keep updating. The fourth case is a build you cannot do properly. The README's own note that a snapshot will not work applies to CI systems that fetch tarballs of a commit. If your pipeline downloads archives rather than clones, you are looking at the distribution bundles instead, which is a different and more constrained upgrade path. ## Licence, maintenance and how to reach the people who do the work The licence field on the repository is a custom type that GitHub cannot categorise, and the README routes you to the source of truth rather than naming a licence in prose. It says to see the file LICENSE.TXT for the available licenses, and the file LICENSE.TXT is at the top of the tree next to the README. The same notice appears at the end of the README and at the top of the Makefile. Both say that the file is part of the FreeType project and may only be used, modified and distributed under the terms of the FreeType project license, LICENSE.TXT, and that by continuing to use, modify or distribute the file you indicate you have read the license and understand and accept it fully. Two things follow. First, the terms are in the file, and they are not one of the licences GitHub's picker recognises, so an automated scan will need a human to read the actual text. Second, the licence is a dual-style arrangement, since the README refers to the available licenses in the plural and the project historically ships both a library licence and a GPL option for embedding in GPL software. The specifics are in LICENSE.TXT, and whether a given use fits your distribution model is a question for your own counsel rather than for a review. Maintenance is the easy part. The repository is not archived and the last push was on 2026-10-21, so the code is current. The README version is 2.15.0. Reaching the maintainers is the part with process. The preferred way of communication with the FreeType team is using e-mail lists, and there are four of them with distinct purposes. ```bash general use and discussion: freetype@nongnu.org engine internals, porting, etc.: freetype-devel@nongnu.org announcements: freetype-announce@nongnu.org git repository tracker: freetype-commit@nongnu.org ``` The lists are moderated, and the contact page is where the subscription instructions live. Bug reports belong on the GitLab issue tracker, patches on the GitLab merge request page, and the details of the process are on the project's developer page. ## Conclusion Adopt FreeType if you need direct access to rasterised glyph outlines from most vector and bitmap font formats in a C codebase, and if you want the sizing and configuration control that a platform text stack does not give you. Do not adopt it if you need text shaping, layout or bidirectional behaviour, because that layer sits above this one, or if your platform already gives you the glyph access you need. Before you integrate, read docs/INSTALL* for the build route that fits your platform and docs/CHANGES for important information, and remember that the GitHub copy is a mirror, so bugs go to the GitLab issue tracker and patches to the merge request page. ## FAQ ### Where should I file a bug report for FreeType? The GitHub repository is an official mirror and asks that you do not open issues there. Bug reports go to the GitLab issue tracker at gitlab.freedesktop.org/freetype/freetype, which also supports confidential reports, and larger changes go to the merge request page there. ### What version of FreeType is in the repository? The README is headed FreeType 2.15.0. The documentation package for that version is published as freetype-doc-2.15.0.tar.xz, freetype-doc-2.15.0.tar.gz or ftdoc2150.zip. ### Can I build FreeType from a tarball of the git repository? No. The README says that if you use the git repository instead of a distribution bundle, you have to actually clone the repository, and that using a snapshot will not work, adding that you should not use the Download button. ### Which build systems does FreeType support? The repository contains autogen.sh with a configure script, a meson.build with meson_options.txt, a CMakeLists.txt, an MSBuild solution for Visual Studio, and a Makefile that includes builds/toplevel.mk. ### Where is the FreeType API reference? It is in the docs/reference directory of the repository, with index.html as the top entry point. The README notes that the search function for locally installed documentation does not work because of cross-site scripting issues. ### What licence does FreeType use? The repository licence field is a custom type that GitHub cannot categorise. The README and Makefile both point to the file LICENSE.TXT at the top of the tree for the available licenses. ## Sources - [freetype/freetype on GitHub](https://github.com/freetype/freetype) - [Issues](https://github.com/freetype/freetype/issues) - [README](https://github.com/freetype/freetype/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/freetype-freetype