各位想必都看過 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]