pistondevelopers/freetype-rs

Rust bindings for FreeType library

Cargo: We use Cargo to compile the project

freetype-rs

Requirements

  • Cargo: We use Cargo to compile the project.
  • FreeType2 development libraries: For installation instructions see freetype-sys.

Build

Clone this repo then run

cd freetype-rs
cargo build

Examples

To build examples, use cargo test. They are all built in ./target/debug/examples/*.

To run examples, use cargo run --example name, for example:

cargo run --example single_glyph examples/assets/FiraSans-Regular.ttf A

How to contribute

Issues

Collection of the latest Issues

YeonJi2

YeonJi2

Comment Icon0

If a glyph was loaded using LoadFlag::RENDER like this:

and created a bitmap glyph using to_bitmap:

In to_bitmap, not only it will pass the_glyph(which contains self's raw pointer) to FT_Glyph_To_Bitmap, but it also receives the resulting pointer through the_glyph. So the_glyph would contain pointer to the new glyph after successful FT_Glyph_To_Bitmap. https://github.com/PistonDevelopers/freetype-rs/blob/5975d3c8bd8cf9711174ac97c28118845ad274a1/src/glyph.rs#L76-L86 But the problem is that FT_Glyph_To_Bitmap will NOT replace the_glyph's value if glyph was already rendered(and still return error code 0, which means it's OK). I was able to confirm this by modifying the source code like this, and checking the output:

So to_bitmap copies the old value(which is again, self's raw pointer) to the BitmapGlyph, creating two glyphs pointing to the same glyph. Not only this means modifying old glyph can affect the "new" BitmapGlyph, but it also means when drop is called on both glyphs, it will cause double-free and eventually segfault.

Using DEFAULT flag(which does not render the glyph) does stop the segfault, and to_bitmap works without any issue.

So I think there should be a check if glyph is already a bitmap before calling FT_Glyph_To_Bitmap. FT_GlyphRec's format field might help that.

A code that segfaults

Below simply loads a glyph with LoadFlag::RENDER(which renders the glyph and turns it into bitmap), and then tries to convert it to bitmap. I used explicit drop call to show exactly where it was segfaulting.

This will crash with following output:

Backtrace:

It probably segfaulted because two glyphs were sharing the pointer(because of the bug I mentioned above), and dropping one of them invalidated the other glyph.

RazrFalcon

RazrFalcon

Comment Icon1

The glyph_outline example crashes with segfault while trying to outline the 0 glyph (I had to modify the example a bit, since it accepts only characters) using the Noto Tinos-BoldItalic.ttf (md5sum d303824b18cfd6f13838f94791b708bd).

Output: terminated by signal SIGSEGV (Address boundary error)

According to gdb it crashes here.

freetype-rs 0.20.0

ishitatsuyuki

ishitatsuyuki

Comment Icon0

This is as easy as face.raw().bbox. Useful for getting line height.

ishitatsuyuki

ishitatsuyuki

Comment Icon0

FT_Stroker is required to render outline text, which probably will be added in text libraries then.

rbrich

rbrich

Comment Icon1

According to freetype docs, the contour may start with conic off point. This case is not handled by CurveIterator, which assumes that first point is always on curve.

I encountered the problem with FreeSans.ttf, glyph "0". The inner contour has these tags: 00101001. The first point is conic off, so the last point should be used instead as the curve's starting point.

This is my render of the wrong outline: screen shot 2017-02-14 at 10 59 01

Another example is the glyph for "8", the tags are 00010010010, ie. both ends of the contour are off-curve.

emberian

emberian

Comment Icon19

This issue was automatically generated. Feel free to close without ceremony if you do not agree with re-licensing or if it is not possible for other reasons. Respond to @cmr with any questions or concerns, or pop over to #rust-offtopic on IRC to discuss.

You're receiving this because someone (perhaps the project maintainer) published a crates.io package with the license as "MIT" xor "Apache-2.0" and the repository field pointing here.

TL;DR the Rust ecosystem is largely Apache-2.0. Being available under that license is good for interoperation. The MIT license as an add-on can be nice for GPLv2 projects to use your code.

Why?

The MIT license requires reproducing countless copies of the same copyright header with different names in the copyright field, for every MIT library in use. The Apache license does not have this drawback. However, this is not the primary motivation for me creating these issues. The Apache license also has protections from patent trolls and an explicit contribution licensing clause. However, the Apache license is incompatible with GPLv2. This is why Rust is dual-licensed as MIT/Apache (the "primary" license being Apache, MIT only for GPLv2 compat), and doing so would be wise for this project. This also makes this crate suitable for inclusion and unrestricted sharing in the Rust standard distribution and other projects using dual MIT/Apache, such as my personal ulterior motive, the Robigalia project.

Some ask, "Does this really apply to binary redistributions? Does MIT really require reproducing the whole thing?" I'm not a lawyer, and I can't give legal advice, but some Google Android apps include open source attributions using this interpretation. Others also agree with it. But, again, the copyright notice redistribution is not the primary motivation for the dual-licensing. It's stronger protections to licensees and better interoperation with the wider Rust ecosystem.

How?

To do this, get explicit approval from each contributor of copyrightable work (as not all contributions qualify for copyright) and then add the following to your README:

and in your license headers, use the following boilerplate (based on that used in Rust):

Be sure to add the relevant LICENSE-{MIT,APACHE} files. You can copy these from the Rust repo for a plain-text version.

And don't forget to update the license metadata in your Cargo.toml to:

I'll be going through projects which agree to be relicensed and have approval by the necessary contributors and doing this changes, so feel free to leave the heavy lifting to me!

Contributor checkoff

To agree to relicensing, comment with :

Or, if you're a contributor, you can check the box in this repo next to your name. My scripts will pick this exact phrase up and check your checkbox, but I'll come through and manually review this issue later as well.

  • @bvssvni
  • @coeuvre
  • @Potpourri
  • @andrewrk
  • @zummenix
  • @indiv0
  • @hannobraun
  • @nstoddard
  • @seemk
  • @ankit3005
  • @boghison
  • @TyOverby
  • @tomaka
  • @jneem
  • @Kagami
  • @xilec
  • @petevine
  • @cybergeek94
  • @lifthrasiir
  • @sinistersnare
  • @aepsil0n
  • @caspark
  • @leonkunert
  • @Boreeas
  • @m4rw3r
  • @ddrmanxbxfr
  • @mprobinson
  • @Ms2ger
  • @xaviershay
  • @ssirai
nstoddard

nstoddard

discussion
Comment Icon4

In commit bba330b4d3dac6a04935f6fb27e31ad00fb07433, several methods that took &mut self were changed to take &self instead. Why was this change made? It seems like a bad idea to me. Several of those methods change internal state, so omitting mut might cause problems.

abonander

abonander

bug
Comment Icon9

I downloaded Freetype's source to get the body of the relevant function (since there doesn't seem to be a debug symbols package available in the Ubuntu/Mint repos ¯_(ツ)_/¯ ):

The only place a segfault looks possible is the virtual call memory->alloc() which I think would segfault if memory was null, correct?

I can't figure out how to configure a debug build for Freetype or else I'd have tried to debug this further. I mean, I can configure it, but the ./configure script is giving me weird errors.

Is this possibly related to #90?

Versions

Find the latest versions by id

Information - Updated Apr 04, 2022

Stars: 70
Forks: 55
Issues: 15

Cargo-xbuild is a replacement for xargo which is now no longer supported

Cross compling sysroot features can be specified in the command line parameters or via cargo config

Cargo-xbuild is a replacement for xargo which is now no longer supported

Cargo Advent of Code Helper

cargo-aoc is a simple CLI tool that aims to be a helper for the Criterion

Cargo Advent of Code Helper

cargo-tree has been integrated directly into Cargo as of the 1

This repository is archived as a result

cargo-tree has been integrated directly into Cargo as of the 1

cargo-ndk - Build Rust code for Android

This cargo extension handles all the environment configuration needed for successfully building libraries

cargo-ndk - Build Rust code for Android

cargo-all-features

Cargo subcommands that build and test all feature flag combinations for a crate

cargo-all-features

cargo-geiger ☢️

A program that lists statistics related to the usage of unsafe Rust code in a Rust

cargo-geiger ☢️

cargo-io-lib-template

This is tweaked cargo init --lib for FOSS

cargo-io-lib-template

cargo-spellcheck

Grammar check using on how to define a custom dictionary file

cargo-spellcheck

cargo-cov: Source coverage for Rust

cargo-cov is a cargo subcommand which performs source coverage collection and reporting for Rust crates

cargo-cov: Source coverage for Rust

cargo-raze: Bazel BUILD generation for Rust Crates

An experimental support Cargo plugin for distilling a workspace-level

cargo-raze: Bazel BUILD generation for Rust Crates
Facebook Instagram Twitter GitHub Dribbble
Privacy