jjgod

原帖由 aloft 于 2009-5-4 16:12 发表


呵呵，说清楚些，你负责搭哪个架子，大家不要做重复工作

特指搭建 Google Code 项目，导入代码这些底层工作

jjgod

已搭好: http://code.google.com/p/ctex-kit/

需要提交权限的请给我发站内消息或者通过邮件告诉我你的 google 帐号。

目前添加了 xeCJK 和 ctex 宏包，还有什么需要导入的？

milksea

CJKpunct，最新版见 http://bbs.ctex.org/viewthread.p ... age%3D1&page=16。这个包对于复合字体（如 ctex 宏包定义的 rm）机制似乎不是很完善。

jjgod

原帖由 milksea 于 2009-5-4 17:53 发表
CJKpunct，最新版见 http://bbs.ctex.org/viewthread.p ... age%3D1&page=16。这个包对于复合字体（如 ctex 宏包定义的 rm）机制似乎不是很完善。

添加了 4.8.1-2 版本，见: http://ctex-kit.googlecode.com/svn/trunk/CJKpunct/

aloft

赞快速

yulewang

我需要个svn帐号。您知道我google的account的。

现在我们来讨论一个问题：
CTeX宏包采用何种方式支持UTF8. 因为只有支持了UTF8，才可能被XeTeX和LuaTeX完整支持。 我能想到的只有以下三个方案：
- 我们把所有的中文字符串split出来，分为两套文件（gb编码和UTF8编码），然后按照用户的选项，决定是启用哪套文件，以及是载入cjk还是cjkutf8。这个做法最科学，也能够保持ctex原先优秀的代码质量，但是工作量大。
- 我们把 CTeXUTF8宏包整个merge进去，原先版本改为CTeXGBK，然后CTeX宏包成为一个抽象的包。如果发现用户触发了UTF8的开关，则整个读入CTeXUTF8而不是CTEXGBK。
- 第一个方法工作量很大。第二个方案最好实现，不过会产生很多冗余的代码，而且CTeXUTF8并不是完整地按照doc strip的方式完成的，不好做文档。所以第三个方法就是采用runtime的iconv来实现，不过受到平台制约（Windows下我们要提供一个iconv）。

待CTeX支持UTF8后，xetex载入就不会发生任何字体和编码的问题了，稍微改改就能够直接在xetex下用了。而且也为port到LuaTeX(这个引擎只支持utf)做好了准备。

LiYanrui

我比较倾向第一种方式，只是不知道如何去做。有没有办法用脚本去处理？

yulewang

btw, 我们是否考虑产生一个core，一个third party目录，一个doc目录，和一个obsolete目录，把目前所有CTeX中文用户组的重要工具都加入，成为一个大集合（CTeX讨论区这些材料都太零散），这样提交给CTAN会泾渭分明，更有目的性，而且更方便版上面的用户搜寻。
能想到的是：
- 把ctex和xeCJK, cjknumber, cjkpunct加入到core，由官方的同仁维护。
- 把zhspacing, ConTeXt中的zhfonts等加入third party（这个由作者维护，官方不负责维护）
- 把lshort, lnotes, tex for the impatient, liyanrui的ConTeXt文档，TeXLive 2008 手册以及其他作者同意用开源协议的文档加入doc
- 把CCT和中文字体的生成脚本以及其文档加入obsolete。

milksea

我觉得多种编码的东西不大可能完全用那个 DocStrip 写成单文件的包。我也倾向于第一种方式。用 iconv 是最不可取的。

milksea

这个想法不错。
不过 CJKnumb 不是已经在 CJK bundle 里面了么？原本是不是 WL 写的？不过这个东西确实只是中文。