上篇文章《GBK转unicode码查询表》中有一个美中不足的地方，就是占用的内存空间稍大了一点，约128KB，当然，对于PC这种平台无所谓，但对于一些场合来说，能省内存就省内存，何况那个表省内存又是件很easy的事情。
首先说明，平时使用GBK汉字编码字符集就够用了。GB18030向下兼容GBK，所以在文章、代码直接称GBK了。对于这些标准细则，有兴趣的可以深究一下。
GBK转unicode码查询表的改进
GBK转unicode码查询表
大约大半年前完成一个矢量字库类，使用freetype库从矢量字库中读取字符轮廓，然后转成只有0、1的缓冲区，可以使用许多场合。涉及了freetype的操作，同时还有字符编码方面的知识。前不久，有同事反映说我提供的东西不能生成“绿”字。经测试，的确如此。查找代码发现原来编码转换表不全面，没有“绿”字的unicode码。那个对应表是在网上找的，自己也没做全面测试——我不会无聊到所有的汉字都测试一遍。
代码随笔——点阵汉字在LCD上的显示
其实我以前从没想过写Framebuffer的代码，网上流传较多的是LCD的移植(主要改参数)，之后没下文了。不过，曾经兴致冲冲地想搞Qtopia移植，在这过程中碰到过一个叫Tslib的东西。后来Qtopia没搞成功，倒研究起Tslib来了——对它的底层原理还没看明白，对于一些代码技巧及代码结构组织还是研究了一点。
点阵字体显示系列补记2：关于24点阵汉字显示程序及其修改版本
自从写完16点阵后，由于没啥事做，就继续看看24点阵是如何显示的。这种规格的点阵是使用UCDOS(虽然下载了，但用不了)中的汉字字库。又千辛万苦找到ASCII码的24点阵，再修改前面的程序，生成24点阵ASCII码的数组。测试完后，用一天时间，在触摸屏搞出了汉字显示，不过对比了Tslib库的代码，发觉自己写的简直是一塌糊涂，于是继续修改代码。
点阵字体显示系列补记：将字库文件转换成数组形式
昨天写完几篇文章后觉得意犹未尽，我想想了，既然字库文件是二进制文件，完全可以转化为十六进制，存储在数组中，这样在寻找字符时就不用操作文件了，直接在内存中获取。
点阵字体显示系列之三：使用ncurses显示汉字
ncurses这个库，最早听说应该是当年刚接触Linux的时候，当时，我们宿舍就一个人在鼓捣Linux，他是我们后来的班长，如今在ZLG混，也不知混得怎么样了。我也不知道哪条神经线路出现故障了，竟然傻乎乎去学Linux，到后来，一发不可收拾，从此走上了一条不归路。到毕业前，我曾经说过了研究ncurses库的，还写了文章，文章说要在毕业时将ncurses掌握到什么程度。
点阵字体显示系列之二：汉字显示
计算机中存在许多种格式的编码，比如ASCII、GB2312、GBK、UTF-8，等等。汉字以“内码”的形式存储于计算机中。对于汉字的处理，有三种不同情况，一为汉字的输入，比如常用的拼音输入、五笔输入；二为汉字的存储，即以某一编码存储于计算机中，比如GB2312、utf-8；三为汉字的显示，比如网页(及其它如MS Word等软件)中显示的各种字体，如宋体、黑体。
点阵字体显示系列之一：ASCII码字库的显示
早在阅读tslib源代码时就注意到里面有font_8x8.c和font_8x16.c两个文件(后来才得知，它们来自Linux内核，具体目录是./drivers/video/console)，它们包含了在屏幕上显示所需的所有字符(当然，是可打印字符)，由此也看了一下tslib显示字符的代码。对将来在触摸屏上显示汉字有所帮助，——这是后话，暂且按下不提。
使用Tslib在触摸屏上显示汉字
终于到了在触摸屏上显示汉字了，真正写代码、测试的时间是1天，在此之前的一切准备、学习花费约2周到3周时间。而为了获取触摸屏上显示的图像，花费约2天。由于网络驱动已经接近于放弃状态，NFS用不了，只好用U盘来回复制(即使没有耐心也必须有耐心了)。