以下是卑微的本人的思考，抛砖引玉：
1. 字体裁剪。针对每个页面生成专用字体文件，比如页面a只使用了1 07个汉字，就为它生成只含107个汉字的字体文件，大概只有10~20KB，下载速度极快。 ------ 如果对每个页面生成专用一个字体文件需要服务器资源，如果让浏览器下载107个汉字的字体文件（每个字体一个文件）会降低浏览速度。应该找出服务器运算/输出文件速度和浏览器下载多个文件速度并显示的平衡点。
2. 字体收集。如果页面上包含了一个字形，连服务器的字形库里也没有，就提供一个接口，鼓励用户制作这个字形并上传给服务器。 ----- 寻找unicode已有字符是个困难的事，应该想办法避免让用户上传认为没有但实际unicode已经拥有的字符。这涉及字符识别。关于字符识别可以考虑研发古文OCR软件，帮助Wikisource识别 工整手写的古文 https://archive.org/details/cadal，让编者校对，其中Unicode没有的字符按照阁下的工具显示。
可以考虑成立一个类似wiki commons http://commons.wikimedia.org/ 的中心服务网站，用户可在上面上传字符，供所有安装插件的wiki使用。
在 2014年5月12日 下午12:34，Xiao Xiangquan xiaoxiangquan@gmail.com写道：
大家好， 在今年的Google Summer of Code项目中，我所申请的“为通用语言选择器提供中文字体支持”项目成功入选， 将在未来的三个月内完成这一工程，并争取早日合并入主代码库。
*工程概述：** *如果一个页面中包含了需要某种字体才能显示的文字，而阅读者的设备上没有这种字体，就会显示出无法阅读的“豆腐块”。这种问题对于中文尤为常见， 因为很多非中文用户的设备里没有中文字体；而且中文用户的字体库里也不可能含有所有字符。我们知道汉字有8万个以上， 仅在Unicode中就定义了7万多，而实际上中文常用字很少，只有3500个左右。大多数用户都只安装了这些常用字， 几乎不可能有人安装了包含所有汉字的字体。而Wiki作为一种包罗万象的媒体，页面上可能包含任何汉字。 可以想象一下，我们写一个“古汉字专题Wiki”或者“生僻汉字专题Wiki”，对大多数人来说它们将是无法阅读的。
Webfonts技术是解决豆腐问题的一个办法，已经在wikimedia中启用。当发现页面中的特殊字体无法正常显示时，就从服务器上下载对应的字体文件。 然而到目前为止wikimedia的webfonts仍然不支持中文，可能是因为中文字体太大了。即便只包含常用的3000多个汉字的字体文件， 大小也会以数MB记，而我们要的是包含所有生僻字的解决方案，字体文件将达到几十MB，无法想象在打开一个页面时如果要加载这么大的文件，谁还会愿意打开。
本工程要解决的就是上述问题，主要完成两件事：
- 字体裁剪。针对每个页面生成专用字体文件，比如页面a只使用了107个汉字，就为它生成只含107个汉字的字体文件，大概只有10~
20KB，下载速度极快。 2. 字体收集。如果页面上包含了一个字形，连服务器的字形库里也没有，就提供一个接口，鼓励用户制作这个字形并上传给服务器。
解决了这两个问题，你将几乎再也看不到任何中文“豆腐块”，你写的包含任何汉字的wiki页面，也几乎可以被世界上任何读者无障碍阅读。
欢迎关注本工作的进展，提出意见、建议，试用、报告Bug等。
工作进度： https://www.mediawiki.org/wiki/Extension:UniversalLanguageSelector/ Fonts_for_Chinese_wikis
项目提议书（英文）： https://www.mediawiki.org/wiki/Extension:UniversalLanguageSelector/ Fonts_for_Chinese_wikis/proposal
我的LinkedIn： linkedin.com/in/xiaoxiangquan 我的新浪微博： weibo.com/xiaoxq
Wikizh-l 邮件列表 Wikizh-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikizh-l