最近 FreeType 2.2.1 刚刚发布，尽管由于 API 的变化 (许多内部函数被隐藏起来了)，多数的 distro 并未把系统使用的 FreeType 升级到这一版本——我相信要过很长一段时间才有可能这 么做。但使用源代码编译的版本，我做了一点小小的对比分析。 因为精力有限，只对 FreeType 2.1.10 (目前绝大多数发行版正在使用的版本) 进行了比较，试图给出基于 FreeType 的程序 (如 fontconfig) 应当如何配置字体 才能获得最好的效果的一点建议。而事实上，font rasterizer (字体光栅化工具) 必须和其他的 rasterizer 比较才能看出明显的区别来，例如 ATSUI, Win32 GDI 等等。 同时，我也只对随 Windows 附的 simsun.ttc 做了测试。如果你有兴趣，欢迎分享 更多的测试结果。 测试的截图在 flickr 上。 经过比较，我们可以给出这样一些建议： 必须打开 anti-alias，gamma 才会起作用。 gamma = 0.0 时启用 sRGB (次像素反锯齿) 模式，这种模式要比默认的 gamma = 1.0 [...]
因为想写一个 lightweight & fast 的文本布局引擎，这两天在留意一些新的图形 API。其实有些都不算很新了，像 Anti-Grain Geometry、Amanith 和 Xara。 曾被誉为“Linux 图形未来希望”的 cairo 广受诟病的是它的效率，尽管从一开始 cairo 便宣称将会利用 glitz 这样的 backend 实现硬件加速的矢量图形绘制，从而达到软件绘制无法达到的效果。结果现在戏剧性的是，cairo 比所有这些用软件绘制的引擎都慢得多。 所以才有人写了这么一篇 Why Cairo?，意思大概说得很清楚了，Mozilla 选用 cairo 的借口现在看来是非常苍白无力的，比如说 cairo 引以为傲的“bring vector graphics to print”有多少人需要把网页输出到 PDF/PS？如果最基本的页面渲染都做不到高效，谈何页面印刷的高效？ 所以我觉得啊，rendering model 好当然不错，cross-platform 性能好也很好，但 cairo 是不是中 gnome 社群的毒太深了？什么东西都来搞个 backend，结果最后每个 backend 都半死不活的，没错，也许某天 David Reveman 搞定了 xgl 腾出手来整 glitz 了，可 David Reveman 就算搞定了 [...]
真的是.. a mess，估计就像 pango maillist 上有的人说的，有能力使用 layout engine 的人都能够直接看 reference 写程序，没能力的都去用 GUI Toolkit 提供的 high-level API 了。 最近看的几个 layout engine 包括：Uniscribe, Graphite, Pango 和 ICU。最惨的是它们的定位和功能还不一样，有些相互之间还有牵扯。 就是这样居然还有人能把 Graphite, ICU 和 ATSUI 集成起来给 TeX 用，考虑到 TeX 还是用 WEB (Pascal 的 literate programming 版本) 语言写成的，这真是让人崇拜得五体投地的强者啊。 (看了一下强者的 biography，原来自从我出生开始就在 SIL 工作了.. 那么这样我比较不自卑一点。) 更新：看完这篇 mail，我又很高兴了
Microsoft 在 (或者将在) Windows Media Center Edition, Windows Vista 和 Office 2007 中替代 Tahoma 作为界面和菜单的默认字体的就是现在看到的这个 Segoe UI。毫无疑问，它可以和 Tahoma 区分得很清楚，取代 Tahoma 的尖刻的圆角和 Trebuche MS 有几分相似——wikipedia 上是这么说的。 然而 Linotype 公司声称它与 Linotype 的 FrutigerNext 是一模一样的。看下面的对比，真的是几乎一模一样啊 (黑色的是 60pt 的 FruitigerNext，灰色的是 56pt 的 Segoe UI)： Wikipedia 上还提到，Microsoft 在 2004 年尝试在欧盟将 Segoe 和 Segoe Italic 注册为原创性字体设计，Linotype 提出了抗议，在 2006 年二月，欧盟拒绝了 Microsoft 的注册请求。Microsoft [...]
在印刷排版中，“point”是一个绝对的单位，它等于 1/72 英寸，可以用尺子丈量的，物理的英寸。但在 CSS 中 pt 的含义却非如此，例如我们指定一个字体是 9pt，我们会以为按照 CSS 规范，它等于： 9 * 1/72 = 1/8 inch 这是一个误解，因为我们的显示器被分割为了一个个的像素，单个像素只能有一种颜色 (为了简化，这里暂不讨论次像素反锯齿技术)，要在屏幕上显示，必须先把以 pt 为单位的长度转换为以像素为单位的长度，这个转换的媒介，就是 DPI (事实上，这里的所谓的 DPI，是操作系统和浏览器中使用的术语，即为 PPI, pixels per inch，和扫描仪、打印机、数码相机中的 DPI 是不同的概念)。 例如，无论在哪个操作系统中，Firefox 浏览器默认的 DPI 都是 96，那么实际上 9pt = 9 * 1/72 * 96 = 12px。 所以，虽然“DPI”中的“I”和“1pt 等于 1/72 inch”中的“inch”，都不代表物理上的英寸，但这两个单位互相之间是相等的，也就在相乘中约掉了。 那么，真实的物理长度怎么计算呢？请拿出一把尺子，丈量你的显示器的可见宽度 (我这里是 11.2992 英寸)，除以横向分辨率 (我这里是 1024 像素)，得到的就是每个像素的物理长度。 现在我们可以回答这样一个问题，网页上 [...]
© jjgod / blog. Powered by WordPress using the DePo Skinny Theme.