Opentype-shaping-documents Alternatives

opentype-shaping-documents reviews and mentions

• Ligatures in programming fonts: hell no
  2 projects | news.ycombinator.com | 13 May 2023

  > The tangent in (1) on how they contradict unicode could have been skipped as well

  Not only because confusables already exist, but also (as I already 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 IBM employees wrote a large part of the early standard (based on the decades of i18n experience they had at that point) and 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#combiningV

• Libgrapheme: A simple freestanding C99 library for Unicode
  6 projects | news.ycombinator.com | 15 Nov 2022

  > 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 likely two problems with 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 (where are the paragraph boundaries?). There is the pre-Unicode bi-directional support mode (BDSM, I kid you not) in ECMA-48[1] and TR/53[2], which AFAIK nobody implements nor cares about, and which doesn’t seem to actually; there are terminal emulators made 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 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 rendering behaviour”, there are only standards specific to font formats, the most recent 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 monospace font—only of a (proportional) font where all Lat/Cyr/Grk characters just happen to have the same advance.

  AFAICT that is not an oversight or negligence, 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 need that shaper, otherwise nothing works.

  [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