看板: BudaTech ◎ 佛典电子化讨论 板主: HeavenChow |
阅读文章: 第 688/2032 篇 | 上篇 | 下篇 | 回覆 | 转寄 | 转贴 | m H d | 返回 |
发信人: dnstudio <dnstudio@m2.dj.net.tw>, 信区: BudaTech 标 题: Re: 回maha有关大辞典新版之 发信站: 国立中山大学网路组 Mailing List (Wed Jun 25 10:03:10 1997) 转信站: Lion!ccnews.nsysu!news.nsysu!buda-tech@sccid.nsysu 来 源: sccid.nsysu.edu.tw COSINE wrote: > > 新版还是会以光碟发行,只不过改成html相容,至於网路 > 版,目前还有一些技术上及非技术上的问题。我尽力试试。 > > 之所以用图形方式显示造字,有三个原因: > 1)既然是少见到要用「造」的字,检索的机率必定不高,何况也可以用 > ?的方式来代表所有的造字,如罗?罗,一样可查出。 > 2)没有造字空间的问题。 看法相同, 用图形是末学一直在做的, 有人会问那 dos怎麽办? 末学认为 这些 users 从市场的角度言, 是没有必要考虑的. > 3)现在我们面临的最大问题不是检索,而是造字没有标准,没有标准则 > 无法交换,一切都免谈,所以目前最重要的工作就是建立标准,建立 造字标准?标准造字表? Excuse me. As I know we already have one. It is the effort by 台大佛研恒清 and 中研院庄德明. Why don't we keep delevelping based on this one, so the effort won't be waste. > 一个有弹性的标准。标准一旦形成,我们就可以要求软体系统□/font> > 字形商,把它 build-in 在系统内,才能把造字问题解决。图形方式 > 大家可把它视作为过渡方案。 > 这问题的□结应是造字空间有限的问题, 而不是厂商不 build-in 的关系. 谈得更深点还可能是中文文字本身在电脑上应用的根本问题, 例如中文字也在不断演化增加, 只要原来的字增减一画就是一个新字, 目前方言字, 如广东方言字, 闽南方言字, 中国地大人多方言也多, 将来各地方言字都出来, 恐怕在大的造字空间都不够; 不若拉丁字由几个基本字母(character)来组成单字(word), 单字再多 还是由那几个基本字母组成. 这是根本问题, 除非, 电脑字的显示设计 从头来过, 并由中国人主导, 这在可见的未来似乎是不可能的事. > fkr 格式是我自己定的,乃FKRead (佛光读经器)之前三码。 > 有鉴於佛光大辞典上一版和其他软体整合能力不足及 > 造字的问题,故下一版会考虑直接推出一个读经器, > 并定出一个新的档案格式,方便大家交换电子佛典。 > 故它不只是电子版的辞典,更像是一个内建线上 > 解释佛学名相的整合的读经介面。 > > 我的想法是: > > FKRead Convertor + user definable rules > Pure Text --> *.fkr > > 大家有自己的输入规格A内缩,造字都不一,不可能 > 强行统一,故应可以经由可程式化的描述档加上 > 转换程式将各家的纯文字档转成统一格式fkr。方便交换。 > > 接下来,再由另一支程式解读fkr ,并转成html输出至browser > > FKRead fkr Parser and Viewer > > *.fkr ---> HTML > raw text -> html -> fkread (display directly to uer interface) If there is no format for raw text, then there is not need to write a parser for it. Since your application runs on Win95, it's best to follow the standard interchangable text format in that, this format nowaday undoubtablly is html. Also, the trend on html is heading toward dynamic html which you will be able to make multimedia presentation. > 此外,版本控制能力,检索能力等也很重要。 MS 的 source safe 是版本控制的软体. > 我现在正在考虑fkr的格式,要决定其规格真不容易,如果 > 太周详担心implement 很困难,做不出来,太简单又怕没有远见, > 造成往後compatible的负担,真是一个delimma。 > 佛光大辞典的coding 部份只有我一人在做,辛苦一□S有关系, > 只是担心会影响进度,让大家久等不好意思,我有以下数点想请 > 大家帮忙,毕竟这是个不小的工程,需要整合很多技术, > 单靠一人确实有不胜study之慨: > > 1)大家一齐来决定档案格式,要包括那些内容,预计应有 > 经名(书名),作者,译者,原书页码,版本,输入者,提供者, > 经文结构等。 > 从全文检索的角度看, 这些应该要建立属性表 (aka database) 来辅助. 记得在妙云集程式的讨论中末学已提过了. > 2)往後在网路上我们共同来维护一份统一的造字表,用001-->?? , 002--->??表示 > 其中001 002是造字序码,??是造字表达式,(用中研院庄先生的方法) > 我会把这些造字做成bmp格式小图,在读经器内可以show出来。 > 以後佛光大辞典既然是一个读经器,它就应该有包容各家造字的能力。 > 末学已经在做了, 末学之前给师父的档案中 budfont.hlp 即是. 16, 24size的 bmp已有近千字, 都是根据庄居士的造字档. > 3)佛光大辞典v1是用delphi 3.0 compile的,我想没有意外的话,v2 > 也会用delphi 来做,所以请大家推荐对佛典电子化有与趣的delphi高手, > 我想组成一个 5至10人的cyber-team 来做这做这项工作,就像老外做linux > 的方式一样。 > 这是 public domain software 的做法, 师父是说佛光辞典的软体要成为 public domain 的软体? > 4)我想知道大家对大辞典内图片的看法,真的有必要每张都做进光碟去吗? > 因为扫描不是问题,问题是已经找不到原始的图片了,如果用和原书不一样的 > 图大家可以接受吗? > 是否只要原来的"专家"认可就可以了, 有图毕竟是好的, 在电脑内也最好是 彩色的. > 有关於佛典保存及流布,昨天我 post 的一篇慧开法师的文章很值得参考, > 大家有空可以看看。 > -- 张文明 日月工作室 mailto: dnstudio@m2.dj.net.tw 电子佛教藏经阁: http://w5.dj.net.tw/~DNStudio/canon |
阅读文章: 第 688/2032 篇 | 上篇 | 下篇 | 回覆 | 转寄 | 转贴 | m H d | 返回 |
□ 台大狮子吼佛学专站 http://buddhaspace.org |