opentype-shaping-documents

Documentation of OpenType shaping behavior

Explore on GitHub Read Hacker News discussions

2Distinct people

3Mentions

0Explicit recommenders

190GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Documentation of OpenType shaping behavior

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year3 dated mentions

Observed mentions: 2019-11-20 03:24:28 UTC to 2023-05-13 15:07:59 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	1	1
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	0	0
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	0	0
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	1	1
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	1	1

What Hacker News says

3 sources

mananaysiempre·May 13, 2023

> The tangent in (1) on how they contradict unicode could have been skipped as well Not only because confusables already exist, but also because (as I said[1] the previous time this was posted) covering all ligatures used in all typographical styles is very much a non-goal of Unicode. The official position is that the font shaping layer[2] sits atop Unicode’s semantic representation and is free to ligate, spindle, or mutilate it for display however it prefers (at least for Latin, Greek, and Cyrillic it’s a preference; other scripts can’t be rendered at all without doing it, such as Arabic—barring the legacy presentational forms—or Burmese[3]). The only reason Unicode even has those ligatures is that some IBM encodings (which were more presentational in nature) encoded them, and the IBM employees who wrote a large part of the early standar

Read the rest

d (based on the decades of i18n experience they had at that point) wanted roundtripping. [1] https://news.ycombinator.com/item?id=29639966 [2] https://github.com/n8willis/opentype-shaping-documents [3] https://r12a.github.io/scripts/mymr/my.html#compositeV

In Ligatures in programming fonts: hell no (2019)

mananaysiempre·Nov 15, 2022

(Not a language or Unicode expert, the following likely has important mistakes.) > Off the top of my head, I don't know of a terminal that actually implements the entire (very complex) set of Unicode text rendering behaviors There are at least two reasons for this: First, nobody actually seems to know how bidirectional text should interact with terminal control sequences, or indeed how it should be typeset on a terminal in the first place (what is the primary direction? where are the reordering boundaries?). There is the pre-Unicode bidirectional support mode (BDSM, I kid you not) in ECMA-48[1] and TR/53[2], which AFAIK nobody implements nor cares about; there are terminal emulators endorsed by bidi-language users[3], which AFAIK nobody has written down the behaviour of; there is the Freedesktop bidi terminal spec[4], which is a draft and

Read the rest

AFAIK nobody implements yet either but at least some people care about; finally, there are bidi-language users who say that spec is a mistake[5]. Second, aside from bidi and a smattering of other things such as emoji, there is no detailed “Unicode text rendering behaviour”, only standards specific to font formats—the most recent among them being OpenType, which is dubiously compatible across implementations, decently documented only through painstaking reverse engineering (sometimes in words[6], sometimes only in Freetype library code), and generally full of snakes[7]. And it has no notion of a monospace font—only of a (proportional) font where all Lat/Cyr/Grk characters just happen to have the same advance. AFAICT that is not negligence or an oversight, but rather a concession to the fact that there are scripts which don’t really have a notion of monospace in the typographic tradition and in fact are written such that it’s extremely unclear what monospace would even mean—certainly not one or two cells per codepoint (e.g. Burmese or Tibetan; apparently there are Arabic monospace fonts[8] but I’ve no idea how the hell they work). Not coincidentally, those are the scripts where you really, really need that shaper, otherwise nothing looks anywhere close to correct. [This post could have been titled “Contra Muratori on Unicode in terminal emulators”.] [1] https://www.ecma-international.org/publications-and-standard... [2] https://www.ecma-international.org/publications-and-standard... [3] https://news.ycombinator.com/item?id=8086417 [4] https://terminal-wg.pages.freedesktop.org/bidi/ [5] http://litcave.rudi.ir/ [6] https://github.com/n8willis/opentype-shaping-documents [7] https://litherum.blogspot.com/2019/03/addition-font.html [8] https://news.ycombinator.com/item?id=10395464

In Libgrapheme: A simple freestanding C99 library for Unicode

bjz_·Nov 20, 2019

Yeah! This was a big reason why we've invested in funding the work on https://github.com/n8willis/opentype-shaping-documents/ - hopefully this makes the barrier to entry to building font shaping engines a little lower for newcomers, and gives us a place to document findings, separate from any single implementation.

In Allsorts: font parser and shaping engine implemented in Rust