文書處理第零課: 放下對外觀的執著

(刊載於 2002 年 10 月號 Linuxer 雜誌)

也請見 本文 2009 重新改版。

追求美麗, 可能也是一種錯誤

想像幾位正在出期末考題的英文老師。 每一位老師負責出 5 題, 最後交由劉老師彙整。 一如往常, 劉老師提醒大家要用 12 點字, 選項前面要空 8 格, ... 劉老師收齊每一位老師辛苦排版過的檔案之後, 才發覺同樣是空 8 格, 有些老師按空格鍵, 有些老師用的卻是數量不等的 tab 鍵 (因為每個人的電腦設定不同)。 結果不但其他老師辛苦排版的工夫白費了, 劉老師還得額外地先將每一位老師所打的 tab 鍵刪除, 才能夠手動小心對齊。

[各自著色, 再拼起來]

每位作者都被要求參與調整外觀的工作, 人仰馬翻之後卻得到一份 "藍得不同調" 的文件 (ㄟ, 請不要有政治聯想) 這是用無電腦時代的思維在使用電腦的後果。 聽說有一位酋長受贈一部 20 馬力的汽車, 於是找來 20 匹馬來拖車, 與此大約有異曲同工之妙。

重視文件美麗的外觀, 可能是一種錯誤。 文書處理, 應該從 「放下對外觀的執著」 開始學起, 不要教文件的作者如何在頁面邊緣留幾公分, 如何選用大小不同的字體。 老師的工作是出考題; 會議論文作者的工作是議論辯述; 科員的工作是拿捏公文的措辭; 至於對文件的外觀化妝打扮, 這應該是排版專家的工作。

內容交給作者, 外觀交給排版專家

如果不是大家迷信電腦, 逼得校長規定要用電腦來做每一件事, 也許劉老師 (以及其他英文老師) 的日子會好過些。 每位老師只管將題目寫在紙上。 大家說好遇到要強調的地方就用紅色螢光筆標出來; 遇到沒有教過的單字則用黃色螢光筆標出來;... 最後劉老師把所有紙片交給印刷商統一打字, 並且交代: "紅色螢光筆處用 14 點粗體字; 黃色螢光筆處用 12 點斜體字; ..." 最後印出來的文件不是更美觀而且更一致嗎?

[各自只留框, 拼起來以後再統一倒入顏料]

更好的是, 如果新校長不滿意原來的考卷外觀, 下次出題的時候, 不需要重新一一與每位老師溝通 -- 只有劉老師交代印刷商的那一段話 (姑且稱之為 "文件外觀規範條文") 需要修改。 如果歷史科, 音樂科, ... 也採用相同的模式, 那麼連新校長自己都會覺得命令的貫徹實在太有效率了。

當然問題的癥結不在於使用了電腦, 而在於誤用了電腦。 「內容與外觀分開處理」 separation of content from presentation 並不是新觀念。 [1] 將 "文件外觀規範條文" 獨立出來, 這個做法從早期的文書處理軟體 (例如 latex 的 .sty 檔), 到現在的 xml 相關規格中 (例如 .css 檔) 一直都是一項非常重要的觀念。 作者只負責文件的內容, 及標示出文件的 結構 (各層次的標題, 段落章節, 那段要強調, 那段是註腳, ...); 至於標題要用幾點的字, 每段開頭要空幾格, 這些規定只有一個人需要知道。 如果方法正確的話, 追求美麗, 可以不是錯誤。

放下執著, 好處多多

讓作者只負責文件的內容與結構, 不要去操煩外觀, 有很多好處。

  1. 結構相關觀念比外觀相關觀念少很多, 每位作者需要學習/注意的細節減少, 複雜度降低。
  2. 發生溝通錯誤/不一致的頻率也因而降低。
  3. 文件外觀規範條文, 如果用電腦看得懂的語法撰寫, 更可將調整外觀這件重複/繁瑣/無趣的工作丟給電腦, 一次處理大量文件。
  4. 管理規範條文的人只有一位, 容易貫徹長官對文件外觀的要求 (在要求頻頻改變的場合, 這點更彌足珍貴)。
  5. 比較容易對管理規範條文的人單獨加強排版方面的訓練, 調整出來的效果更專業, 更美觀。
  6. 同樣的內容, 一份文件只要搭配不同的外觀規範條文, 就能以不同的面貌呈現在紙張/網頁/錄音帶,... 各種不同的媒體上。
  7. 人力可以發揮相乘的效果。 什麼意思? 試想: 一本論文集彙集了 20 篇論文, 要用 5 種不同的媒體呈現。 用我們的方法只需要 20+5 的人力, 就可以達到舊方法 20x5 人力的功效!

明瞭 「內容與外觀分開處理」 的好處之後, 下一步才是決定要選用什麼樣的資訊技術來實作。 聽說 XML 當紅, 我們不妨來了解一下。

只要是 XML 就一定沒有問題嗎?

拜微軟之賜, 消費者從彼此文件不相容, 甚至同一套軟體新舊文件不相容的夢魘中, 學到了使用公開格式以維護自身接駁資訊權利的重要性。 那麼現在當紅的 XML [2] 是否就不會製造問題了呢? 其實 XML 只是一個空殼子, 或者說是一個泛稱。 你的 XML 文件裡面採用了那些 Schema 或 DTD 呢? 如果用上了 MathML 的 DTD, 文件裡就可以出現微分方程等等複雜的數學式; 如果用上了 SVG 的 DTD, 文件內就可以嵌入可平滑放大縮小的線條圖 (本文的附圖顯然還沒有用到這個技術, 所以有點醜); ... 但是消費者的 XML 文件內如果使用到封閉不公開的 Schema/DTD, 那麼他接駁資訊的權利一樣有可能受損。 只確定文件使用 XML 技術, 但不確定使用了那些 Schema/DTD, 就好像只確定吃素, 但不確定有沒有吃到罌粟種子之類的食物 (也是素食沒錯吧?) 並不能保證文件/飲食健康正常。

[單單是 XML 本身, 並不能拿來用, 必須搭配一至數種 Schema 或 DTD]
DTD 功用
MathML 表達複雜的數學式
SVG 用座標方式來記錄線條/幾何圖形
xhtml 製作與 html 幾乎完全相同的文件檔案

誰提供的 Schema/DTD 值得信賴呢? 筆者個人認為, 像是負責訂定與網頁相關的各種規範的 W3C, 與訂定低層網路通訊規範的 IETF [3] 這些單位所推薦的 Schema/DTD 特別值得重視。 他們訂定各種標準時附有說明文件, 不但將成果公佈在網路上讓大家自由拷貝, 連討論的過程都攤在陽光下。 參與討論的人來自世界各地, 有自學的電腦高手, 學者專家, 廠商代表,... 只要你有能力提供建設性的建議, 你的發言就會受到重視。 因此受到 W3C 與 IETF 推薦的 Schema/DTD, 不論在公信力, 實用性, 前瞻性上, 都比較有保障。 順便一提, 我國研考會所推動的電子化公文 XML 格式, 實在應該拿出來接受大眾以上述標準加以檢視, 以免受到社會大眾指責閉門造車甚至圖利特定廠商的誤解。

xhtml + css2

回到主題, 有沒有現成, 為 W3C 所推薦的 Schema/DTD 適合用來取代目前一般化文書處理的封閉 .doc 格式呢? DocBook [4] 是一個值得注意的發展方向。 不過目前處理 DocBook 的工具, 對一般使用者而言, 親和力還不夠, 門檻稍高。

一個同時兼具前瞻性又顧及現實的選擇是 xhtml。 一方面它向下相容於舊的 html (對既有, 並不特別支援 XML 的軟體而言, xhtml 1.0 基本上與 html 4.0 是同一回事) 所以當今的各種瀏覽器及網頁編輯器都可以讀取; 另一方面因為它以 XML 為基礎, 所以將來 (其實現在已經有一部分實現了) 可與其他文件搭配/剪接。 例如 Mozilla 已經可以顯示一份內含 xhtml, MathML, SVG 三種語法的文件。 即便將來的主流是 DocBook 或其他新的 XML 格式, 既有的 xhtml 文件也將很容易批次轉換。

「我們談文書處理, 怎麼談到網頁去了呢? 」 如前所述, 把製作一份文件的紙張版/網頁版/錄音帶版當做各自獨立的工作來思考, 是過時的想法。 對觀念正確的文件作者而言, 傳遞訊息才是最重要的目標; 用何種媒介傳遞, 只是手段的選擇而已。 起源於網頁的 xhtml 與起源於書本的 DocBook 在 XML 上面找到交集, 正印證了這個觀點。 同一份 xhtml 文件, 搭配不同的外觀規範條文 (稱為 css; 新版稱為 css2) 就可以產生列印版, 網頁版, 語音版, ... 這正是我們需要的技術。

每個人都有選擇他自己喜歡手機的自由: 用 Nokia 的手機打給易利信接收, 並不會出現 「不相容, 請換手機」 的訊息。 軟體的彈性理應更大, 只要大家用相同的公開, 標準格式交換檔案, 就不必統一規定大家都要用 OpenOffice 或 K-Office。 眾多公開格式當中, 選擇 xhtml 作為文件檔案的標準, 看來是最不偏頗的決定, 而這也將有助於文書處理軟體的多元化及公平競爭

不理外觀, 手工打造文件很簡單

我們來看幾個實際的範例。 你可以用 MS Word 或 FrontPage 來製作這樣的文件; 不過筆者偏好以簡馭繁。 如果有一個人要跨越一條 2 公里長的橋, 他應該如何規劃太空梭的降落地點呢? 他當然不! 騎 腳踏車 簡單多了。 何必誤用科技, 讓人類的幫手反過來成為自己的負擔?

首先, 如果你只是要寫一篇短短的社論, 你只需要知道兩件事:

  1. 不論是一個空格/五個空格/換列一次/換列五次, 效果完全一樣。 因此你根本不要為如何對齊而操心。 當然有空格/沒有空格是有差別的。 因此我們通常在標點符號後面換列或放幾個空格。
  2. 每個段落的開頭放一個 <p>

例如用 vim, nano, 或是記事本建一個檔案叫做 wpl0.html, 內容如下:

    <p>想像幾位正在出期末考題的英文老師。 每一位老師負責出
    5 題, 最後交由劉老師彙整。
    一如往常, 劉老師提醒大家要用 12 點字,
    選項前面要空 8 格, ...


    <p>每位作者都被要求參與調整外觀的工作,
    人仰馬翻之後卻得到一份...

    <p>重視文件美麗的外觀, 可能是一種錯誤。 文書處理, 應該從
    「放下對外觀的執著」 開始學起, ...

然後用 lynx, mozilla, 或是 ie 打開來看, 自然就是一篇排列整齊的文章。

當然, 文章需要標題; 比較長的文章, 還需要分章節:

    <h1>文書處理第零課: 放下對外觀的執著</h1>

    <h2>追求美麗, 可能也是一種錯誤</h2>
    <p>想像幾位正在出期末考題的英文老師。 ...
    <h2>內容交給作者, 外觀交給排版專家</h2>
    <p>如果不是大家迷信電腦, ...
    <h2>放下執著, 好處多多</h2>
    <p>讓作者只負責文件的內容與結構, ...

這裡的 <h1> 與 <2> 代表這個標題的 層次。

製作文件/寫文章, 有時候需要強調一段文字; 有時候需要逐一列舉:

    ... 如果方法正確的話, <em>追求美麗, 可以不是錯誤</em>。
    ...
    <ol>
    <li>結構相關觀念比外觀相關觀念少很多, ...
    <li>發生溝通錯誤/不一致的頻率也因而降低。
    ...
    <li>人力可以發揮相乘的效果。 ...
    </ol>

放入插圖時, 要指定插圖來自那個檔案; 放入表格時, 要指定格子邊緣線條的粗細。 不論是插圖或是表格, 都要記得加上一小段文字說明 -- 萬一你的讀者不是在 "讀" 你的文件, 而是在 "聽" 你的文件, 你希望如何口頭描述這張圖, 或口頭摘要這個表格?

    <img src = "xml.png" alt=
    "[單單是 XML 本身, 並不能拿來用, 必須搭配一至數種 Schema 或 DTD]" />
    <table border="1" summary="常用的 DTD 及其功用">
    <tr><td>DTD <td> 功用
    <tr><td>MathML <td>表達複雜的數學式
    <tr><td>SVG <td>用座標方式來記錄線條/幾何圖形
    <tr><td>xhtml <td>製作文件檔案 (幾乎等於 html)
    </table>

讀者可別被標記裡面這些複雜的 alt 啦 summary 啦給嚇到了, 筆者經常在寫文章; 但幾乎每次要用到時都想不起來, 因為從來沒有強記的動機 -- 反正抄舊的來改就好了, 幹麻自己嚇自己, 認為這些標記必須記得起來才有資格寫文章?

這些標記其實大約已是筆者所記得標記的一半以上; 而光是這些標記就足以應付筆者網站文件製作所需功能的九成以上。 我在大學教書/寫講義/投稿, 過去從來不曾學過任何封閉或開放的 office 軟體/網頁製作軟體 (學 LaTeX 是另一回事, 不能算是 office 軟體, 主要是為了寫數學式) 以後也不打算學。 我認為把時間花在改善文件的內容更有意義。 如果一定要學習包裝外觀, 我寧可學習如何撰寫 css (還記得嗎? 就是我們先前所說的, 眾多作者當中只需要一個人學習的 "文件外觀規範條文" ) 因為軟體的壽命一般都遠不如公開, 流行檔案格式的壽命來得長, 這才符合我長遠的學習投資效益。 腳踏車易學易停放, 操作者彼此妨礙小, 操作方式多年未變, 在很多艱難的環境都可以用, 又足以應付常人所需; 筆者認為目前 「人人學駕太空梭」 的趨勢有認真檢討的必要。

工欲善其事, 必先利其器

其實駕太空梭與騎腳踏車是兩個極端。 我們特別強調騎腳踏車的好處, 只是為了突顯 「人人學駕太空梭」 的荒謬。 對大多數人而言, 如果有機車或汽車可以開, 也許才是既不嫌小題大作, 又不需刻苦耐勞的中庸正解。

手工打造的網頁其實並不標準; 所幸有 tidy [5] 這支程式可以將半調子的 html 檔整修成符合 w3c 標準的 html 檔。 它還可以將舊格式 (html 3.2 甚至是 html 2.0) 的檔案轉成 xhtml 1.0 -- 筆者所有的上課講義及文章過去就是這麼轉過來的。 當然有些工作非得人工更正不可, 例如插圖沒有 alt 或表格沒有 summary 就必須由作者你自己針對這張插圖或表格手工填入有意義的文字說明。

如果你不喜歡看到 html 檔裡面的那些標記, 可以考慮使用 Mozilla [6] 的 composer -- 常用的標記都在選單裡面, 而且你馬上就可以看到插圖表格大致的長相 (不要對外觀的細節太認真, 因為它會隨著不同的 style sheet 而改變)。

如果你並不畏懼看標記, 只是懶得強記, 那麼 bluefish [7] 是一個很好的折衷方案。 標記可以用拉選單的方式填入; 但顯示出來的仍是 html 原始檔。 中小學裡教文書處理, 這可能是一個比較恰當的切入點, 既不會過難, 又不至於讓有思考能力, 願意推敲理解的小朋友誤以為學電腦等於機械化地按選單, 誤以為文書處理等於整修文件的外觀。 用這種方式學習製作文件, 即使將來遇到只有 "手工具" edit/notepad/nano/vim 可以用的時候, 一樣可以活得下去。

至於繪圖或是撰寫數學運算式, 就比較難用手工的方式進行了. 目前已有一些軟體支援 SVG 與 MathML 文件的顯示與編輯, 但是由於 SVG [8] 與 MathML [9] 的標準也還正在演進當中 ...

有捨才有得; 有得必有失

我們常拿因滿把抓而無法從糖果罐當中抽手的狼狽猴子來警惕自己: 適當的時候不妨鬆手釋懷, 往往反而更容易收穫滿足。 文書處理正是一個例子。 放下對外觀的執著, 反而可以更有效率地產生外觀一致的文件; 放下對特定應用軟體的執著, 反而可以藉著交替使用不同工具而善用更多無法放入同一軟體的功能。

另一方面, 我們也要接受事實: 世界上沒有萬靈丹。 為享受 xhtml + css2 所帶來的一切好處, 我們必須忍受這個過渡技術的小小不便。 畢竟 html 原始的功用不在於列印, 所以即便是加上了 css2, 在外觀上仍會遇到一些差強人意的小問題。 不過對於重視資訊內容的傳遞與保存甚於花邊外觀的大部分作者而言, 這些小小的犧牲應該是值回票價的。

學習文書處理, 可以是機械化的滑鼠點選, 也可以是處處悟哲理的機會。 筆者衷心希望臺灣未來有越來越多人選擇後面這條路。

參考資料

  1. http://www.w3.org/WAI/GL/WCAG20/
  2. http://www.xml.org/
  3. http://www.ietf.org/
  4. http://www.oasis-open.org/docbook/xml/
  5. http://tidy.sourceforge.net/
  6. http://www.mozilla.org/
  7. http://bluefish.openoffice.nl/
  8. http://www.w3.org/Graphics/SVG/Overview.htm8
  9. http://www.w3.org/Math/