Blame docs/html/the-distinction-between-levels-0-and-1.html

Packit 874993
Packit 874993
<html>
Packit 874993
<head>
Packit 874993
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Packit 874993
<title>The distinction between levels 0 and 1: HarfBuzz Manual</title>
Packit 874993
<meta name="generator" content="DocBook XSL Stylesheets V1.78.1">
Packit 874993
<link rel="home" href="index.html" title="HarfBuzz Manual">
Packit 874993
<link rel="up" href="clusters.html" title="">
Packit 874993
<link rel="prev" href="reordering-in-levels-0-and-1.html" title="Reordering in levels 0 and 1">
Packit 874993
<link rel="next" href="level-2.html" title="Level 2">
Packit 874993
<meta name="generator" content="GTK-Doc V1.25.1 (XML mode)">
Packit 874993
<link rel="stylesheet" href="style.css" type="text/css">
Packit 874993
</head>
Packit 874993
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
Packit 874993
Packit 874993
Packit 874993
Home
Packit 874993
Up
Packit 874993
Prev
Packit 874993
Next
Packit 874993
Packit 874993
Packit 874993

Packit 874993
The distinction between levels 0 and 1
Packit 874993

Packit 874993
    So, the above is pretty much what cluster levels 0 and 1 do. The
Packit 874993
    only difference between the two is this: in level 0, at the very
Packit 874993
    beginning of the shaping process, we also merge clusters between
Packit 874993
    base characters and all Unicode marks (combining or not) following
Packit 874993
    them. E.g.:
Packit 874993
  

Packit 874993
Packit 874993
  A,acute,B
Packit 874993
  0,1    ,2
Packit 874993
Packit 874993

Packit 874993
    will become:
Packit 874993
  

Packit 874993
Packit 874993
  A,acute,B
Packit 874993
  0,0    ,2
Packit 874993
Packit 874993

Packit 874993
    This is the default behavior. We do it because Windows did it and
Packit 874993
    old HarfBuzz did it, so this remained the default. But this behavior
Packit 874993
    makes it impossible to color diacritic marks differently from their
Packit 874993
    base characters. That's why in level 1 we do not perform this
Packit 874993
    initial merging step.
Packit 874993
  

Packit 874993

Packit 874993
    For clients, level 0 is more convenient if they rely on HarfBuzz
Packit 874993
    clusters for cursor positioning. But that's wrong anyway: cursor
Packit 874993
    positions should be determined based on Unicode grapheme boundaries,
Packit 874993
    NOT shaping clusters. As such, level 1 clusters are preferred.
Packit 874993
  

Packit 874993

Packit 874993
    One last note about levels 0 and 1. We currently don't allow a
Packit 874993
    MultipleSubst lookup to replace a glyph with zero
Packit 874993
    glyphs (i.e., to delete a glyph). But in some other situations,
Packit 874993
    glyphs can be deleted. In those cases, if the glyph being deleted is
Packit 874993
    the last glyph of its cluster, we make sure to merge the cluster
Packit 874993
    with a neighboring cluster.
Packit 874993
  

Packit 874993

Packit 874993
    This is, primarily, to make sure that the starting cluster of the
Packit 874993
    text always has the cluster index pointing to the start of the text
Packit 874993
    for the run; more than one client currently relies on this
Packit 874993
    guarantee.
Packit 874993
  

Packit 874993

Packit 874993
    Incidentally, Apple's CoreText does something else to maintain the
Packit 874993
    same promise: it inserts a glyph with id 65535 at the beginning of
Packit 874993
    the glyph string if the glyph corresponding to the first character
Packit 874993
    in the run was deleted. HarfBuzz might do something similar in the
Packit 874993
    future.
Packit 874993
  

Packit 874993
Packit 874993
Packit 874993

Generated by GTK-Doc V1.25.1
Packit 874993
</body>
Packit 874993
</html>