| <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
| <html> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> |
| <title>A clustering example for levels 0 and 1: HarfBuzz Manual</title> |
| <meta name="generator" content="DocBook XSL Stylesheets V1.79.1"> |
| <link rel="home" href="index.html" title="HarfBuzz Manual"> |
| <link rel="up" href="clusters.html" title="Clusters"> |
| <link rel="prev" href="working-with-harfbuzz-clusters.html" title="Working with HarfBuzz clusters"> |
| <link rel="next" href="reordering-in-levels-0-and-1.html" title="Reordering in levels 0 and 1"> |
| <meta name="generator" content="GTK-Doc V1.25 (XML mode)"> |
| <link rel="stylesheet" href="style.css" type="text/css"> |
| </head> |
| <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"> |
| <table class="navigation" id="top" width="100%" summary="Navigation header" cellpadding="2" cellspacing="5"><tr valign="middle"> |
| <td width="100%" align="left" class="shortcuts"></td> |
| <td><a accesskey="h" href="index.html"><img src="home.png" width="16" height="16" border="0" alt="Home"></a></td> |
| <td><a accesskey="u" href="clusters.html"><img src="up.png" width="16" height="16" border="0" alt="Up"></a></td> |
| <td><a accesskey="p" href="working-with-harfbuzz-clusters.html"><img src="left.png" width="16" height="16" border="0" alt="Prev"></a></td> |
| <td><a accesskey="n" href="reordering-in-levels-0-and-1.html"><img src="right.png" width="16" height="16" border="0" alt="Next"></a></td> |
| </tr></table> |
| <div class="section"> |
| <div class="titlepage"><div><div><h2 class="title" style="clear: both"> |
| <a name="a-clustering-example-for-levels-0-and-1"></a>A clustering example for levels 0 and 1</h2></div></div></div> |
| <p> |
| The basic shaping operations affect clusters in a predictable |
| manner when using level 0 or level 1: |
| </p> |
| <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "> |
| <li class="listitem"><p> |
| When two or more clusters <span class="emphasis"><em>merge</em></span>, the |
| resulting merged cluster takes as its cluster value the |
| <span class="emphasis"><em>minimum</em></span> of the incoming cluster values. |
| </p></li> |
| <li class="listitem"><p> |
| When a cluster <span class="emphasis"><em>decomposes</em></span>, all of the |
| resulting child clusters inherit as their cluster value the |
| cluster value of the parent cluster. |
| </p></li> |
| <li class="listitem"><p> |
| When a character is <span class="emphasis"><em>reordered</em></span>, the |
| reordered character and all clusters that the character |
| moves past as part of the reordering are merged into one cluster. |
| </p></li> |
| </ul></div> |
| <p> |
| The functionality, guarantees, and benefits of level 0 and level |
| 1 behavior can be seen with some examples. First, let us examine |
| what happens with cluster values when shaping involves cluster |
| merging with ligatures and decomposition. |
| </p> |
| <p> |
| Let's say we start with the following character sequence (top row) and |
| initial cluster values (bottom row): |
| </p> |
| <pre class="programlisting"> |
| A,B,C,D,E |
| 0,1,2,3,4 |
| </pre> |
| <p> |
| During shaping, HarfBuzz maps these characters to glyphs from |
| the font. For simplicity, let us assume that each character maps |
| to the corresponding, identical-looking glyph: |
| </p> |
| <pre class="programlisting"> |
| A,B,C,D,E |
| 0,1,2,3,4 |
| </pre> |
| <p> |
| Now if, for example, <code class="literal">B</code> and <code class="literal">C</code> |
| form a ligature, then the clusters to which they belong |
| "merge". This merged cluster takes for its cluster |
| value the minimum of all the cluster values of the clusters that |
| went in to the ligature. In this case, we get: |
| </p> |
| <pre class="programlisting"> |
| A,BC,D,E |
| 0,1 ,3,4 |
| </pre> |
| <p> |
| because 1 is the minimum of the set {1,2}, which were the |
| cluster values of <code class="literal">B</code> and |
| <code class="literal">C</code>. |
| </p> |
| <p> |
| Next, let us say that the <code class="literal">BC</code> ligature glyph |
| decomposes into three components, and <code class="literal">D</code> also |
| decomposes into two components. Whenever a cluster decomposes, |
| its components each inherit the cluster value of their parent: |
| </p> |
| <pre class="programlisting"> |
| A,BC0,BC1,BC2,D0,D1,E |
| 0,1 ,1 ,1 ,3 ,3 ,4 |
| </pre> |
| <p> |
| Next, if <code class="literal">BC2</code> and <code class="literal">D0</code> form a |
| ligature, then their clusters (cluster values 1 and 3) merge into |
| <code class="literal">min(1,3) = 1</code>: |
| </p> |
| <pre class="programlisting"> |
| A,BC0,BC1,BC2D0,D1,E |
| 0,1 ,1 ,1 ,1 ,4 |
| </pre> |
| <p> |
| Note that the entirety of cluster 3 merges into cluster 1, not |
| just the <code class="literal">D0</code> glyph. This reflects the fact |
| that the cluster <span class="emphasis"><em>must</em></span> be treated as an |
| indivisible unit. |
| </p> |
| <p> |
| At this point, cluster 1 means: the character sequence |
| <code class="literal">BCD</code> is represented by glyphs |
| <code class="literal">BC0,BC1,BC2D0,D1</code> and cannot be broken down any |
| further. |
| </p> |
| </div> |
| <div class="footer"> |
| <hr>Generated by GTK-Doc V1.25</div> |
| </body> |
| </html> |