更新 How to create font data.md

修正一些符号和描述的错误。

Documents/How to create font data.md

@@ -61,10 +61,10 @@
 
 |Unicode编码(HEX)|UTF-8 字节流(BIN)|  
 |:-- |:-- |  
-|000000-00007F|0XXXXXXX|  
-|000080-0007FF|110XXXXX 10XXXXXX|  
-|000800-00FFFF|1110XXXX 10XXXXXX 10XXXXXX|  
-|010000-10FFFF|11110XXX 10XXXXXX 10XXXXXX 10XXXXXX|  
+|000000\~00007F|0XXXXXXX|  
+|000080\~0007FF|110XXXXX 10XXXXXX|  
+|000800\~00FFFF|1110XXXX 10XXXXXX 10XXXXXX|  
+|010000\~10FFFF|11110XXX 10XXXXXX 10XXXXXX 10XXXXXX|  
 
   由上可见，UTF-8提供了一种变长编码格式，忽略Unicode中高位字节为0x00的字节。  
   在字符串中的解码方式为从第一个字节起，如果字节最高位为0，那么此字节表示一个基本ASCII字符，编码为当前字节的值，如果最高位为1，那么从最高位向低，遇到第一个0为止1的个数(至少为两个)表达字符占用的字节数(包括当前字节)，后续字节均为10开头，那么取当前字节高位起第一个0之后的所有位以及后续特定数目字节的低六位(忽略开头的10)，拼接在一起，即当前字符对应的Unicode码。  
@@ -74,8 +74,8 @@
 
 ### 4.1. 标准ASCII字库  
   基本ASCII字库是最简单的，总共包含96个可见字符，编码自32(十六进制0x20)起，至127止，只需要对所有的可见字符取模即可，字库数据数据占用的空间也不会很大。  
-  基本ASCII字库的编码方式有两种，第一种是0~31空白，字符编码直接作为索引。另一种是去除0~31的空白，直接从32号开始，字符编码作为索引时首先减去32。  
-  市面上成熟的字库芯片或带有字库芯片的显示屏通常情况下，使用第一种方案，同时在0~31的位置上安排一些半角的特殊字符以充分利用空间或用于显示特殊控制字。  
+  基本ASCII字库的编码方式有两种，第一种是0\~31空白，字符编码直接作为索引。另一种是去除0\~31的空白，直接从32号开始，字符编码作为索引时首先减去32。  
+  市面上成熟的字库芯片或带有字库芯片的显示屏通常情况下，使用第一种方案，同时在0\~31的位置上安排一些半角的特殊字符以充分利用空间或用于显示特殊控制字。  
 
 ### 4.2. GB2312的中文字库  
   前文详述了GB2312编码的编码方式和特征，GB2312编码的字符索引也比较容易计算了，但是如果真的制作字库的话，还存在一些问题。  
@@ -156,7 +156,7 @@ SGUI_SIZE SGUI_Text_GetCharacterTableIndex(SGUI_UINT16 uiCharacterCode)
 (6*2)*96+(12*2)*3755+(12*2)*682 = 53820 Bytes
 ```
 。  
-  53MB的Flash消耗对于单片机来说是不可思议的，这还仅仅包含了一级汉字，如果再加上二级汉字，那么还需要额外的7.2MB空间，所以这种时候，通常就要使用外部字库了。  
+  53KB的Flash消耗对于单片机来说还是非常可观的，这还仅仅包含了一级汉字，如果再加上二级汉字，那么还需要额外的7.2KB空间，如果还需要其他不同大小的字体，空间资源需求还要成倍增加，所以这种时候，通常就要使用外部字库了。  
   但事实上，很多时候，界面上的文字都是既定好的，不需要动态的变化，这也就决定了整个系统中可能仅仅就需要使用少数的几个字符。这时候如果还要去设计外部字库显然对软硬件成本都是一种浪费，精简字库消耗才是正途。
   通过前文的说明，字符和字符串的编码，说到底不过就是从字符编码到字库索引上的一种算法表达，精简字库，说到底也是从这一方面着手，删除掉字库中用不到的文字和符号，重新定义编码和索引，字库的精简就完成了。  
   基于以上思想，精简字库首先要列出整个目标系统中所有可能用到的文字，然后进行去重，提炼出目标系统中用到的所有汉字。然后给这些汉字进行重新编码，简而言之就是进行简单排序，然后重新编号，这个编号就是新规定的字符编码。最后，用这个新的编码重新去对字符串进行编码，这样就完成了字库的精简了。