wez/wezterm
1
1
Fork 0
mirror of https://github.com/wez/wezterm.git synced 2024-12-27 15:37:29 +03:00
Code Issues Projects Releases Wiki Activity
f1be33939b
wezterm/deps/freetype/bindings.h

14 lines
383 B
C
Raw Normal View History

Build our own freetype, harfbuzz This is primarily for macos where the default freetype installation is unable to render color emoji, but should also help make things more consistent across the various platforms. It's a little bit awkward on linux because the font-loader crate pulls in the now-conflicting servo-font* crates. I've disabled font-loader on linux systems; it's just calling fontconfig under the covers anyway.
2019-03-23 19:28:40 +03:00
#include <ft2build.h>
#include <freetype/freetype.h>
freetype: update bindings to include Paint API
2023-08-16 01:01:40 +03:00
#include <freetype/ftcolor.h>
Build our own freetype, harfbuzz This is primarily for macos where the default freetype installation is unable to render color emoji, but should also help make things more consistent across the various platforms. It's a little bit awkward on linux because the font-loader crate pulls in the now-conflicting servo-font* crates. I've disabled font-loader on linux systems; it's just calling fontconfig under the covers anyway.
2019-03-23 19:28:40 +03:00
#include <freetype/ftlcdfil.h>
#include <freetype/tttables.h>
#include <freetype/ftmodapi.h>
#include <freetype/ftoutln.h>
fonts: add support for "variable" fonts With this configuration: ```lua local wezterm = require 'wezterm' return { font_dirs = {"/Users/wez/Downloads/Inconsolata"}, font = wezterm.font("Inconsolata"), font_locator = "ConfigDirsOnly" } ``` wezterm is now able to see the 74 variations that are available in the single inconsolata ttf. Running `WEZTERM_LOG=wezterm_font=trace wezterm` will log the variations. refs: https://github.com/wez/wezterm/issues/655
2021-04-08 03:45:38 +03:00
#include <freetype/ftmm.h>
fonts: synthesize bold when missing refs: #815
2021-05-23 02:20:35 +03:00
#include <freetype/ftsynth.h>
fonts: improve cap-height and use_cap_height_to_scale_fallback_fonts We now compute the cap-height from the rasterized glyph data. Moved the scaling action of use_cap_height_to_scale_fallback_fonts from glyphcache into the font resolver: when enabled, and we have data about the baseline font and the font being resolved, then the resolving font will be scaled such that the cap-height of both fonts has the same pixel size. The effect of this is that `I` glyphs from both fonts should appear to have the same height. Added a row of `I`'s in differing styles at the bottom of styles.txt to make this easier to visualize. refs: #1189
2021-10-03 04:20:45 +03:00
#include <freetype/ftglyph.h>
freetype: expose sfnt name functions
2021-10-10 20:14:41 +03:00
#include <freetype/ftsnames.h>
add experiemental svg font support The vertical alignment is wonky, and some glyphs have the wrong aspect and are missig colors. eg: the watermelon glyph in Noto Color Emoji (U+1f349). Turn this off by default, and skip loading fonts that have svg by default.
2023-08-15 15:46:19 +03:00
#include <freetype/otsvg.h>
freetype: expose some more constants
2021-10-10 20:18:47 +03:00
#include <freetype/ttnameid.h>
Reference in New Issue Copy Permalink