各位想必都看过 open 98 网站的三篇补字机制的文件,
其中真的不乏好的构想, 而且也有不少是各位都一起讨论过的观
念.

由於近日实在是太多大好的因缘聚合, 加上之前25T小组在处理
经文时, 真的为了缺字伤了不少脑筋, 这个问题愈早解决是愈
好, 故小弟自不量力, 邀请各位成立这个佛典缺字讨论小组.

後学先声明一点, 虽说是"讨论小组", 其实後学没什麽好的意见
和各位讨论. 这种比较技术性的东西, 几个能力好的朋友一些处
理就可以有很好的方案出来. 之所以加入, 主要是站在处理资料
的立场, 希望知道目前的讨论进度, 以及站在使用者的立场, 提
出一些现实可能遇到的问题给大家参考. 并不是我有什麽好技术
要与大家讨论, 这点要先说明, 不然大家就算不笑我, 我也会脸
红的.

讨论的方式, 依据後学在 25T 的讨论经验, 还是在私下用 mail
讨论最好. 上 buda-tech 有其公开的好处, 但总不若在私下谈
来的迅速方便. 而且在公开的地方谈是有些地方要顾忌的. 若有
阶段性的结果出来, 我们可再贴上 buda-tech , 广徵大家的意
见. 若有人有其它看法及有兴趣加入讨论. 再邀其至小组讨论.
如此可一兼二顾, 摸蛤兼洗裤.

目前己有之基本成员有中研院, 资功会, 佛光山及狮子吼的朋友
, 再加上後学接触的经典处理小组的一些成员, 若有兴趣加入讨
论, 请 mail 给小弟, 来者不拒, 底下是小弟目前的看法, 有兴
趣请加入, 其它的讨论就会在小组内部进行了喔!

  佛典缺字讨论小组成立前召集小组组长  heaven
  (过乾瘾用自封的, 成立後就下任了 :p)

本篇给各位参考, 若有兴趣的朋友, 欢迎加入佛典缺字讨论小组,
至该小组讨论下去. 谢谢!

  §罗嗦的契子§

在 25T 小组处理经文时, 讨论到最後的成品, 我曾对 maha 建议,
网路上大正藏第九册的格式太麻烦了, 而且很浪费空间, 若要做到
保留完整资讯, 可在每一段做个记号, 如此阅读比较清爽, 档案也
会变小. maha 立即向我说明, 这样在校对时很方便, 立刻可以知
道是何页何行何字, 在其它的处理也很方便. 日後要改, 则怎麽改
都可以....

後来听说 open 98 根据这种格式, 不到二小时就将六十华严全文
检索做出来, 并在其「再论补字机制」 提到 :

「在CCS 2.0 (参考www consortium)的规格中有一个很重要的观念
  ，即电脑萤幕及平面纸张只不过是同一份Core data (核心资料)
  的两不同出版方式而已，所以其内建有出版至萤幕或纸张的指令
  。」

也就是说, 我上述的想法犯了一个错误, 就是想将原始资料、成品
结果、其他处理来源(如全文检索)... 都希望是同一份东西, 所以
处处都遇到捉襟见捉肘的窘态, 怎麽都做不到一举数得的结果. 如
今这个观念, 的确是给了後学一些想法上的出路, 原始资料归原始
资料, 日後要怎麽展现或处理, 都是各人的事, 重点就在「如何输
入原始资料」及「如何展现成品」, 分开来想的确简单多了, 於故
试著整理自己在三篇补字机制及 25T 小组的处理心得, 看能不能整
理出些什麽给大家参考.

  §古早的问题§

缺字最老的问题, 大概就是造字的空间不足. 各家造字的乱象不谈
 (骂了好多人 :p)这个问题也是各家都会遇到的. 看了一些报告,
最常听到的做法是「将最需要的放入」, 比较不重要的就用组合字
或其它方式处理掉. 但什麽才是需要的? 若是输入 30 册大正藏,
重要的字就填满了, 其它的几册怎麽办? 除非大正藏及其它的辞典
, 工具书全部都出来了, 再来麻烦中研院等大机关来裁决?

日後或许会有不少新的标准出来, 但在这之前, 问题还是要解决,
我本来是放假完才要整理这一篇, 但有人觉得事情比较急, 故我就
先写了. 我们是可以慢慢玩, 但资功会及佛光山都是在陆续出成品
的单位, 他们可等不得, 拖愈久则问题愈多, 我想大家都能理解.
现有之 CNS , CCCII , Unicode 及讨论中的 big5-plus(?) , 都是
字较多的东西, CNS 及 CCCII 25t 小组有玩过了, 至於 OPEN 98
则认为 Unicode 会成为标准, 我想其自有专业的眼光. 若有机会,
可请其另文撰写, 发表看法. 这里只是要说, 在这些标准出来之前,
我们必需有一个自己的暂时标准, 并且能容易的转到後来的规格中.

现在就以补字机制及其它心得以「成品输出」及「资料输入」二个
角度来探讨, 看看是否有什麽问题在其中.

  §成品输出§

成品输出就是利用「原始资料」或称 Core data (核心资料) , 再
利用程式转入下列各种格式的成品. 有些如 Word , 则可以利用
Word 的巨集将核心资料转成其可展现的结果.

在此, 小弟只讨论异体字及缺字, 其它如天城体及罗马字母等, 我
没有去仔细想过.

●缺字 : 使用造字空间, 诸位专家们都说真正的缺字实在不多...
         我们就先这样同意好了.

  ○在特殊读经器 (如 OPEN 98 )  : 直接输出
  ○在支援多字面程式 (如 Word ) : 直接输出
  ○在支援图形的介面 (如浏览器) : 直接输出
  ○在纯文字模式 (如笔记本)     : 直接输出
  ○在 dos 模式 (如 pe2 , 汉书) : 直接输出

  ※以上或有兼具多特色的程式, 如 Word 可直援字面及内嵌图形图形.
  ※支援多字面程式, 即可同时看到明体, 楷书等同字(码)不同形的程式.

●异体字 : 使用标准 Big5 空间, 但使用其它字面. 在输出时必需有正
           体字, 字面编号, 异体字形的完整缺字表格.

  ○在特殊读经器 (如 OPEN 98 )  : 直接输出
  ○在支援多字面程式 (如 Word ) : 直接输出
  ○在支援图形的介面 (如浏览器) : 转成图档
  ○在纯文字模式 (如笔记本)     : 1.直接转成正体字 2.转成正体字
                                  但加上标记 3.转成组合字
  ○在 dos 模式 (如 pe2 , 汉书) : 1.直接转成正体字 2.转成正体字
                                  但加上标记 3.转成组合字

  §资料输入§

●缺字 : 由於使用造字空间, 只要提供良好之输入法, 则与一般字输入
         无异.
●异体字 : 在「三论补字机制」一文中, 作者提到为了「兼顾应用(人容
           易读)及流通(机器可读) 便利」提出了的 OPEN 98 经文原始
           档规格的建议, 格式有点类似 <#Vn>[正体字] ,而打算使用
           词库的方式来输入, 以避免使用者查表的困扰.

           这个方式以前 maha 也和我提过, 是为了要输入组合字用的.
           例如[□*木]这个字, 对仓颉的使用者可能会输入[女一木]=[VMD]
           , 只是在组合字时, 希望能输出[□*木]而 OPEN 98 的规格
           可能是输入<#V1>[床]. 输入原理相同, 但 maha 好像提过,
           通用词库无法输出半形字, 有关这方面及通用词库使用法,
           能否请 maha 介绍一下.

           或许我们可以输入[?女一木]或[?VMD], 到时再用转换程式
           依缺字表转换即可. 只是要考虑重覆字的情形, 例如梵网中
           [□*木]的缺字, 即是用 VMD.GIF 的图形来表示. 又想到一
           点, 若用[?VMD床], 大概就比较不会重覆了吧! 这类方法缺
           点是在转换前, 可能不易看出是什麽字.

  §其它§

其它要讨论的事及 OPEN 98 提出来的功能亦不少, 如检索 (异体字可用
正体字检索) , 加入其它标记, 让文章可依作者, 段落...等等您想得出
来的方式检索 (当然, tag 就要再定义下去) , 不过这些比较和缺字无
关, 又如 OPEN 98 亦提到可将自家之造字以另一字面来看待, 这样就可
以不动到核心资料....  等特异功能, 後学已无力再思索下去了...

总之, 核心归核心, 展现归展现. 是一个很好的观念. 以经典系列及梵网
为例, 经典系列是以纯文字档为核心, 所以展现出来的资料就是纯文字.
而梵网则是曾国丰的力造, 有兴趣的人可以去看看. 尤其在古文格式上,
我个人认为不错. 但我曾问过他一个问题, 若有 user 想 copy 资料,
您要怎麽还原? (因为他大量用了 JavaScaipt 在处理, 但处理时很方便,
但还原可能就有点麻烦). 他是说为什麽还原? 我说因为想在家里看, 或
是其它处理.... 那时结论是东坡站还是有原稿, 不然以後也可以提供
Html 格式档, 让 user 下载. 我想可以这样说, 梵网的整体很不错, 但
就是不易变更. 而且他辛苦的加上了作者, 校对者及其它线上注解, 在原
始档案有些可能没有, 也就造成了多份原始资料的场面出来. 在後来的发
展上是比较麻烦的.

这时若能将大家认为重要的资料加入核心资料中, 在成品展现及资料处理
上则大家各凭本事, 都是很好的方式. 而这些就有待大家的共同讨论了.

[问题一] : 若异体字和正体字不是全然相等时, 如何处理?
[问题二] : 有人问及通用字库的作法及限制? maha 能否提出心得.

  其它则看不到什麽问题, 只是一些规格讨论, 欢迎大家提出看法.

  heaven

Heaven <Heavenchow.bbs@buddha.cbs.ntu.edu.tw> 次写入到主题
<0000R1$X4v@buddha.cbs.ntu.edu.tw>...
> 我个人认为不错. 但我曾问过他一个问题, 若有 user 想 copy 资料,  
> 您要怎麽还原? (因为他大量用了 JavaScaipt 在处理, 但处理时很方便, 
> 但还原可能就有点麻烦). 他是说为什麽还原? 我说因为想在家里看, 或
> 是其它处理.... 那时结论是东坡站还是有原稿, 不然以後也可以提供
> Html 格式档, 让 user 下载. 我想可以这样说, 梵网的整体很不错, 但
> 就是不易变更. 而且他辛苦的加上了作者, 校对者及其它线上注解, 在原
> 始档案有些可能没有, 也就造成了多份原始资料的场面出来. 在後来的发
> 展上是比较麻烦的. 

	梵网现在用 javascript 只是要订出确实可用的显示介面, 终极目标
	并非使用 javascript 而是用类似 fast-cgi 或 server-side-include
	等技术来处理. 只是目前我没时间再去发展这些技术.

	重点当然是要有一份确定可以运用在许多已经确定需要支援的用途,
	比如说显示, 查询等等. 换句话说是在尝试建立适合经典本身的资料
	结构. 所以还原的问题, 目前一直没有放在第一位.

	但是呢, 若资料结构确定了的话, 例用程式 (ex: C-code) 就可以把他
	转回正式的 text file. 至於资料格式, 由其是缺字部份, 目前采定的
	方式是使用: [VMD.GIF, □*木]兼顾梵网中划出的字型以及用组字法所
	排出的字型. 再没有可行的解决方案前, 我只打算这样做.

	OPEN98 等技术似乎也被局限在 Windows/IE 上, 我当初选用 javascript
	而不用 vbsscript 的主因也在於不想让一家独大. 除了像 style-sheet
	这类因为各家支援正式的 html 标准差异造成的问题外, 其他的我希望
	不要被任何一家 browser 公司给左右. :)

	我想开放性是需要坚持的. ^_^

送件者:  "罗云" <kftseng@cc.nsysu.edu.tw>
> Heaven <Heavenchow.bbs@buddha.cbs.ntu.edu.tw> 次写入到主题
>       梵网现在用 javascript 只是要订出确实可用的显示介面, 终极目标
>       ........略......
>       但是呢, 若资料结构确定了的话, 例用程式 (ex: C-code) 就可以把他
>       转回正式的 text file. 至於资料格式, 由其是缺字部份, 目前采定的
>       方式是使用: [VMD.GIF, □*木]兼顾梵网中划出的字型以及用组字法所
>       排出的字型. 再没有可行的解决方案前, 我只打算这样做.

  我是有想到由原始资料 -> javascript 的方式, 这样可省下不少时间.
  若有适当的原始资料格式, 则大家要怎麽处理都很方便了.

>       OPEN98 等技术似乎也被局限在 Windows/IE 上, 我当初选用 javascript
>       而不用 vbsscript 的主因也在於不想让一家独大. 除了像 style-sheet
>       这类因为各家支援正式的 html 标准差异造成的问题外, 其他的我希望
>       不要被任何一家 browser 公司给左右. :)
>       我想开放性是需要坚持的. ^_^

  是的, 在这些竞争中, 不好的会改进, 只要它没有倒下, 而没倒就是要大家支持.
  我也会努力在产生高品质的原始经文上, 到时各家各凭本事, 做出各有特色的
  站站, 梵网还被人称为 "具有帝王风□" 呢! ^_^   大家加油!

  heaven

站友提到 OPEN 98 的技术似乎限於 Windows + IE,
这里说明一下为什麽会如此。

1.一个方法的好坏关键在於其基础的IDEA ，而
实际Implement 在那个平台则一点关系也没有，
而之所以选择 Windows + IE 的原因是
 a. 研发人员对Delphi 最熟, 而 Delphi 目前
    只能产生Windows 的executable.
 b. IE 对CSS的支援比NETSCAPE 充份。
 c. 不可否认大部份人比较容易接触到windows 的环境。

2.在有限的资源下，我们的目的是尽快把 IDEA 实作出来
  让大家有东西看看，完成後我们会公布文件的规格和核心
  程式码，届时如果大家有兴趣自然可依此转成其他平台。

3.我们评估过同样的功能如果以Java 来做似乎不太可能
  (还是本站研发人员功力不足之故?)
  用 C++ 来做的话成本可能会增加五倍左右。
  而用DELPHI 来开发，速度并没有损失太多，
  时程又可以加快不少，所以就选了DELPHI 。

4.OPEN 98 目前采用的技术是Server side 用 Delphi
  写的CGI 和ISAPI ，Client Side 用少量的Javascript.
  重点还是文件的格式和补字机制，因为只有这个是独家提供的，其
  馀都有现成的技术。

5.能跨平台当然最好，不过考虑到NT Server 建置成本低廉，
  我们可以用专属的
  一部5万元的PC 安装OPEN 98 的性能我想不输给二十万元
  而同时有十个Process 在跑UNIX WORKSTATION。
  OPEN 98  的全文检索速度关键在硬碟IO, Computing Power
  倒是其次。我们是理想是可以安装在各道场的INTRANET上。
  而很多道场根本就没有人可以维护UNIX的机器。

6.OPEN 98全文检索被要求同时能在CDROM 及 INTERNET 上执行，
  所以开发UNIX版本意义不大。

OPEN 98
--
=====================================
 Abhasvara, 光音天, OPEN 98 Taskforce
 佛典数位化资深义工
 Email:lyyen@ms1.hinet.net
=====================================
Ξ Origin: 狮子吼站 <cbs.ntu.edu.tw> [FROM: 210.61.183.51]

==> 於 光音天 (open98@Lion) 文中述及:
: 5.能跨平台当然最好，不过考虑到NT Server 建置成本低廉，
:   我们可以用专属的
:   一部5万元的PC 安装OPEN 98 的性能我想不输给二十万元
:   而同时有十个Process 在跑UNIX WORKSTATION。

        其实若用 PC+solaris 的话耗资比 NT server 便宜.
        若用 linux/freebsd 等的话就更省了. :)

        OS 部份完全免费...

:   OPEN 98  的全文检索速度关键在硬碟IO, Computing Power
:   倒是其次。我们是理想是可以安装在各道场的INTRANET上。
:   而很多道场根本就没有人可以维护UNIX的机器。

        我想维护的人才缺乏才是重点, 不然我是比较 prepare
        x86 solaris + apache + fast cgi 来作. 通透性与可移
        植性绝对比 PC+NT+IIS 来得强悍..

: 6.OPEN 98全文检索被要求同时能在CDROM 及 INTERNET 上执行，
:   所以开发UNIX版本意义不大。

        其实, 若是用 C-code 的话 (not c++) 要做到 internet
        与 cd rom 共通是很简易的事情, 只不过我享有那个能力
        的人不好找.

        我个人当然是认同 open 98 的努力, 只不过我有点坏习惯,
        不想成为某一个团体的拥护者, 所以这个牛脾气弄在网路
        上就变成我什麽 OS 都会完也会管理, 但就不喜欢非某种
        OS 或某公司出的软体莫属不可. :)

        老实说, 我觉得 MS 的 OPEN 策略只是去开拓他的市场占有率,
        并非真的多 open.. (最近被反托拉斯法缠身哩...) 这就不关
        电子佛典的事了, 只是有点文人的臭架子而已.
--
悲■□■□■□■悲■□■□■□■□■□■□■□■□■□■□■悲■□■□■□■悲
欣  法本法无法　欣  君子之交　其淡如水　执象而求　咫尺千里  欣  今付无法时  欣
交　无法法亦法　交  问余何适　廓尔忘言　华枝春满　天心月圆  交  法法何曾法  交
集□■□■□■□集□■□■□■□■□■□■□■□■□■□■□集□■□■□■□集
Ξ Origin: 狮子吼站 <cbs.ntu.edu.tw> [FROM: 140.117.10.222]

==> 於 光音天 (open98@Lion) 文中述及:
: 4.OPEN 98 目前采用的技术是Server side 用 Delphi
:   写的CGI 和ISAPI ，Client Side 用少量的Javascript.
:   重点还是文件的格式和补字机制，因为只有这个是独家提供的，其
:   馀都有现成的技术。

    这边光音天大德答的好像是偏向 cgi 层面的, 而我想
kftseng 原先讲的也有指 browsing 层面的?

刚刚我看到这则以前的消息:
"用Netscape 4.01a 测试了一下本站之显示效果，大吃一惊，
 原来Netscape 不支援相当多CSS的语法，如重要的 line-height
 和 control style等，导致问题很多，"

    其实 Open98 站整体据我看来几乎都可用标准 HTML
来表示出来（不过我不清楚 CSS 所以无法断定, 只是就
标准 HTML 来看显示效果）. 我在家□这台机器是使用
IE 3.0 的都有显示上的问题, 所以如果以後有改版时,
尽量使用标准 HTML 可能还是比较保险. 不过当然了,
这只是说顺手的话, 毕竟这是枝微末节 :)

Have a nice day!
--
寒山问拾得曰：
  世间谤我、欺我、辱我、笑我、轻我、贱我、厌我、骗我，如何处治乎？

拾得云：
  只是忍他、让他、由他、避他、耐他、敬他、不要理他。再待几年，你且看他。

Ξ Origin: 狮子吼站 <cbs.ntu.edu.tw> [FROM: 168.95.104.103]

==> 於 邱大刚 (DavidChiou@Lion) 文中述及:
: ==> 於 光音天 (open98@Lion) 文中述及:
: : 4.OPEN 98 目前采用的技术是Server side 用 Delphi
: :   写的CGI 和ISAPI ，Client Side 用少量的Javascript.
: :   重点还是文件的格式和补字机制，因为只有这个是独家提供的，其
: :   馀都有现成的技术。
:     这边光音天大德答的好像是偏向 cgi 层面的, 而我
: kftseng 原先讲的也有指 browsing 层面的?
: 刚刚我看到这则以前的消息:
: "用Netscape 4.01a 测试了一下本站之显示效果，大吃一惊，
:  原来Netscape 不支援相当多CSS的语法，如重要的 line-height
:  和 control style等，导致问题很多，"
:     其实 Open98 站整体据我看来几乎都可用标准 HTML
: 来表示出来（不过我不清楚 CSS 所以无法断定, 只是就

之所以要用CSS (cascading style sheet, 中文好像是"串接样式表"的样子)
的原因主要是因为画面美观，CSS有Line Height的设定功能，
这样可以让经文行距加大，看起来比较舒服，另外
也可方便风格样式的管理。
CSS当然不是必要的，但我肯定会成为标准(事实上 HTML 4.0已纳入之)
因为不但很方便好用、强化视觉效果，更可避免HTML走上
排版语言的歪路，回到原始的「结构化文件描述语言」的正途。

: 标准 HTML 来看显示效果）. 我在家□这台机器是使用
: IE 3.0 的都有显示上的问题, 所以如果以後有改版时,

老实说IE 到了4.0，在技术上才能和Netscape抗衡，
OPEN 98 之所以强调要用IE ，其中重要的原因是我们取得了
IEAK 授权，可以在CDROM 中附IE和PWS，所以就尽量
用IE 来做测试环境，不管大家喜不喜欢，今年
Windows 98出来，就算有装Netscape ，电脑中一定也会有
一套IE, 现实就是如此。(当然不是100%，听说微软在打官司，
胜负未定)

: 尽量使用标准 HTML 可能还是比较保险. 不过当然了,
: 这只是说顺手的话, 毕竟这是枝微末节 :)
: Have a nice day!

外观不是重点，OPEN 98全文索引软体 今年会配上缺字解决方案
发行光碟版(分Editor/Server 版及 Reader版，
後者肯定是Public Domain ，Editor/Server 版则未定)
，届时应该会考虑加入纯文字及RTF输出的功能。

OPEN 98
--
=====================================
 Abhasvara, 光音天, OPEN 98 Taskforce
 佛典数位化资深义工
 Email:lyyen@ms1.hinet.net
=====================================
Ξ Origin: 狮子吼站 <cbs.ntu.edu.tw> [FROM: 210.61.183.51]