Making notes for an emoji font making library.
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
data
practical
tables
.DS_Store
.gitattributes
readme.md

readme.md

Emoji font making

Purpose

Orxporter needs a font encoding library, so I'm creating my own documentation and notes to facilitate making that.

The purpose of these documents is to:

  1. Digest the specifications of TrueType and OpenType in a way that strips extraneous information that's not relevant to making an emoji font.
  2. Provide a guide for anyone else interested and provide justifications for the design decisions that the library this documentation was made to help will make.

Assumptions

  • This is going to assume that the relationships between characters/ligatures and emoji is 1:1 (which it basically is in Emoji)
  • This is going to assume that all the glyphs that will be produced in any font all have the same square metrics.
  • These fonts should work flawlessly on their target operating systems without any complaints or compatibility issues (as long as those platforms support the emoji font format in question).
  • Fuck Silicon Valley, fuck capitalism.

There may be inaccuracies at this stage

I'm not an expert on digital typography and it's not entirely complete or explained yet.

There may be information I've missed so this may not provide the basis for completely working fonts. I'm pretty sure I've gone over everything that's needed for the most part, but we'll have to see how things go.


Overview of encoding

OpenType and TrueType

OpenType and TrueType are both packaged in a structure known as sfnt. This is basically a series of tables that may or not have information that references each other.

Luckily because we're just doing emoji, there's not too much we have to store, but there still are differences in how we have to encode things between each emoji format and between TrueType and OpenType. For the sake of ease of development and understanding, This guide will try to streamline the two together as much as possible, only breaking off in divergent ways when absolutely necessary.

This guide assumes the data types and tables are identical between OpenType and TrueType unless explicitly stated otherwise.


Data

sfnt wrapper

The data format, and the wrapper for all of the tables.

The tables!

You can encode them in whatever order, but Microsoft has a list of what works best in Windows. (This might also be more performant elsewhere?)

loca is typically expected in a TTF font, but because our TTF fonts will have no TTF contours/outlines, this table shouldn't be necessary.

1. metrics and technical metadata

I still need to learn more about font metrics and make assumptions based on those. (Because most if not all of the metrics for an emoji font, given the project's assumptions, should be the same.)

These tables often do the same thing as each other, just in slightly different ways, different contexts or different encoding systems, so they are all getting lumped together.

  • main headers - requires more writing
  • hhea + hmtx: header and metrics for horizontal writing orientation
  • vhea + vmtx: header and metrics for vertical writing orientation
  • maxp maximum profile: defines the memory requirements for the font.
  • OS/2 - Windows and OpenType-specific metadata and metrics.
  • post - Information for PostScript printers.

vhea and vmtx aren't technically required, but it would be kind of ignorant and Anglocentric of us not to do them.

2. glyph and ligature mapping

  • cmap - Still needs more writing and disambiguation. I'm not really done here!
  • GSUB - in progress. Unclear if this is only applicable to OpenType fonts or not.

3. glyph data

This is where the meat of the font is. This is where the graphical information is stored.

How they are encoded is the basis for what we consider the format of the font is - so a font with sbix glyph tables is an sbix format font, a font with SVG glyph tables is an SVGinOT font, and so on.

Depending on the format, the visual information may be stored solely in one table (SVG, sbix), or two tables working together (CBDT/CBLC, COLR/CPAL).

  • SVG: SVGinOT
  • sbix: Apple
  • CBx: CBDT/CBLC - Google
  • Cx: COLR/CPAL - Will look into later if we see the point in doing it.

4. name

Human-readable metadata.

Recurring elements

Platform IDs

Font Metrics


Current practical notes

What I've found out while making fonts.

  1. macOS SVGinOT validation
  2. SVGinOT metrics problems

Todo

  • Refine metrics used. (There should be some descending, your use of vertical metrics is totally off)
  • I don't understand what PPEM is. (Used in sbix strikes)

Formats

SVGinOT (Mozilla, Adobe)

The most supported and the most ideal format. Other formats have to be done for old OS support, however.

  • Windows 10 (Creators Update)
  • macOS 10.14+
  • iOS 12+?
  • Various Linux distros
  • Firefox 50+

OpenType - otf extension

TABLES

- head

- hhea
- hmtx
- vhea
- vmtx
- maxp
- OS/2

- cmap
- GSUB
- SVG

- name
- post

sbix (Apple)

Stores glyphs as raster images rendered at multiple resolutions that's picked dynamically based on DPI and font size. These images can be a variety of formats (PNG, JPG, TIFF, etc.).

  • macOS 10.7+
  • iOS 2.2+

TrueType - ttf extension

TABLES

- bhed (assumed)
- bdat (assumed)
- bloc (assumed)

- hhea
- hmtx
- vhea
- vmtx
- maxp
- OS/2

- cmap
- sbix

- name
- post

CBx (CBDT/CBLC) (Google)

Stores glyphs as PNGs at multiple resolutions.

  • Android 4.4+?
  • Chrome OS (what version?)

TrueType - ttf extension

TABLES

- bhed (assumed)
- bdat (assumed)
- bloc (assumed)

- hhea
- hmtx
- vhea
- vmtx
- maxp
- OS/2

- cmap
- CBDT
- CBLC

- name
- post

Cx (COLR/CPAL) (Microsoft)

Stores glyphs as multiple layers of vector graphics (COLR) that are given colour palettes (CPAL).

This is only useful for Windows 8. Windows 10 has support for all of the above emoji formats.

OpenType - otf extension

TABLES

- head

- hhea
- hmtx
- vhea
- vmtx
- maxp
- OS/2

- cmap
- GSUB
- COLR
- CPAL

- name
- post