[開放原力] 打造三太子

最近一個月來，我著手進行了一項（目前為止仍然只有一個人維護的）軟體專案，這項專案命名為「三太子」，目的是要把 Opera 桌面瀏覽器按照台灣使用者的習慣與偏好，加以調整。Opera 本身雖然是一套私有軟體，但是其企業文化相當鼓勵使用者社群在不修改 Opera 本身程式碼的前提下加以修改、包裝客製版本；有些客製化版本甚至有機會獲得 Opera 公司的官方支援，並成為正式釋出的版本之一。中國的「朱雀」就是這樣的例子。

像這樣的一個第三方維護專案，也可以是開放源碼專案。事實上，開放源碼社群行之多年的各種技術、慣例、文化，即使拿來跟私有軟體合作，也能夠有很好的搭配；本著拋磚引玉的精神，我決定以本文來記錄這一個月來用於「三太子」專案的各種實務要點，回饋給開放源碼界的各位。

在本文開始之前，還有一件事：日前歐萊禮出版社的新書《The Art of Community》（社群的藝術）已採用創用ＣＣ「姓名標示─非商業性─相同方式分享」3.0 授權條款釋出，並可於其網站上下載英文原本及多種語言的譯本，讀者不妨也將此書納入開放源碼社群經營的重要參考。
 

■ 命名

許多開放源碼專案往往始於「我想要做某某事」的想法，由極少數人（例如只有一個人）開始動手進行；接下來隨著專案日趨成熟，參與的人也越來越多，專案也越來越龐大、複雜。不論專案成員有多少人，當專案成為專案的那一刻，就要有個名字，或者是個代號；「名稱」在任何語言當中都有神奇的魔力，可以把一個不存在的、虛幻的、抽象的概念，轉化成一個具體存在的實體，可以讓溝通能夠集中，讓彼此知道在談論的是什麼。

命名本身是一項大學問，甚至有專門以命名謀生的行業，在此便不多論述；不過命名時有個重點，是每個參與專案的人都該牢記在心的：不管命名的背後考慮了多少細節、用了多少暗示或明示，名字就只是個名字而已，世界上沒有十全十美的名字，一定會有人對這個名字有意見──但是請饒了自己吧，名字取好後沒事最好不要更動，精力應該著重在專案的發展上，而不是一直繞著名字打轉。

「三太子」這樣的名字，說實話多少受到了「朱雀」的影響。中國版 Opera 叫「朱雀」，如果跟著叫「玄武」、「青龍」、「白虎」之類的顯然太過沒有創意，而且就沒辦法跟 Opera 的主題色：紅色相稱了。那如果從另一個角度來想，Opera（歌劇）到了中國變京劇（Chinese Opera），到了台灣是不是應該叫「歌仔戲」（Taiwanese Opera）呢？總覺得哪裡怪怪的。後來在跟我一個朋友的閒聊之中，冒出了「哪吒三太子」這樣的想法；哪吒三太子在台灣的民間信仰當中，是很重要的神祇，手上有各種神兵利器，而且腳踏風火輪，行動迅速，似乎可以跟 Opera 的本質巧妙呼應！再說，風火輪就是圓形的，又是紅色的嘛！所以最後就決定這個專案要叫「三太子」了。

有了中文名字後，接著還得有個英文名字，除了可以保留日後「與國際接軌」的可能性外，英文名字也適合用於檔案命名。由於「哪吒」的出處是梵文佛經當中的「Nalakuvara」音譯之略，因此「三太子」的英文名稱就決定採用「Nalakuvara」了。
 

■ 決定基準

許多軟體專案在發展之初並不會先訂好完整的里程碑，或者繪製完整的藍圖（實務上來說，確實不是所有的軟體專案都可能在一開始就做好這些事）；不過就算如此，也應該在一開始就先決定好取捨的準則，讓參與開發的協同工作者，或者是專案的使用者，都能夠明確地判斷哪些事項比較有可能會囊括在專案內，哪些則不大可能。

這項工作可以為整個專案奠定起最高指導原則，日後若有功能衝突時，或者需要排定工作項目優先順序時，都該以此最高指導原則為基準。有些專案在初期僅憑著核心成員之間的默契來行事，隨著時間過去，或者是隨著成員變動，這些「默契」就很有可能發生變化或喪失，導致專案走向不明，甚至是無法持續下去，實在是相當可惜。

儘可能地把「默契」轉化成具體的文字，讓各種決策都有明白的依據，這是任何專案健全成長的必要根基之一。

「三太子」的基準相當簡單，跟五洲製藥的理念一樣，是「先講究不傷身體，再講究效果」。因為 Opera 本身的開發理念之一就是希望能兼具簡潔與功能強大，因此這也成為「三太子」的最高指導原則──讓 Opera 更適合台灣使用者的同時，也一定要讓 Opera 保持簡潔、乾淨。

在這樣的前提下，「三太子」必須要盡可能地遵循 Opera 本身的設計，按照 Opera 原本的目錄架構邏輯來放置檔案，致力於維持 Opera 一貫的美感。如果可能的話，盡可能地不要添加第三方應用程式、外掛、使用者 JavaScript，這樣才是符合 Opera 精神的「三太子」。

這樣的決定還有一個好處：理論上各平台的 Opera 的邏輯是一致的，因此在儘可能不添加額外程式的前提下，所有對 Opera 的動作理論上也會是能夠跨平台的。也就是說，遵守這樣的指導原則，可以讓「三太子」更靈活、有彈性，也能更容易地移植到不同的平台上。我們稍後就會看到這樣的實證。

可惜現實世界當中並非事事順心，有些台灣使用者極為渴望的功能，不靠外力難以達成；這種情況下，「三太子」仍盡力保持 Opera 本身的純淨，想辦法把「破壞」減到最少，並且把各種額外添加的東西都做成選項──如果使用者不想要，那麼這些東西就不會進來。
 

■ 版本管理

就算只有一個人的專案，也應該要使用版本管理系統，而且儘可能不要拿本機當做版本管理系統的伺服器端。

使用版本管理系統的好處實在是不遑多論了：便於管理（從基本的版本比對到複雜的版本分支及合併）、便於協同作業、作為備份，每一項都十足重要。就算是只有一個人、沒有分支的專案，也有可能因為一時手殘（或者是任何意外）而毀掉手中的檔案，需要回溯到先前可正常運作的版本，任何開發者這時都會對著版本管理系統發出「哈里路亞！」的讚嘆聲。

版本管理系統的選用會跟專案的本質、專案成員的偏好有關。以「三太子」來說，這個專案會將專案當中的某個目錄直接打包壓縮釋出，因此會產生一堆「.svn」目錄的 svn 在此就不是那麼合適；由於我原本就一直有在使用 Perforce（兩個使用者以內免費，用來開發開放源碼專案的話也可以去申請免費授權金鑰），這套版本管理軟體在各方面表現都不錯，也沒有「.svn」的問題，因此最後「三太子」就決定採用 Perforce 來管理修訂版。

不論使用哪一種版本管理系統，最重要的是要乖乖按照正確的取出、放入流程來使用，並且要養成仔細撰寫修訂版日誌的習慣。「三太子」半個月內就產生了數百次修訂版，如果沒有修訂版日誌，根本不可能在需要的時刻找到正確的版本。
 

■ 源碼語言

每一種語言都有其擅長之處，也有其不擅長之處。軟體專案應該選用能夠滿足需求的語言──不過值得注意之處在於，一個專案不見得就只能使用一種語言。

在「三太子」當中，基本上是按照不同作業系統版本的 Opera 安裝方式不同，來選擇所要搭配的腳本語言。

Windows 版本的 Opera 在安裝時有較多使用者互動，而 Windows 的使用者也比較習慣圖型化使用者介面，因此就要選擇能輕易處理 GUI、能處理 UTF-8 字串、能夠處理檔案及目錄、能夠讀寫登錄、能讀寫 INI 設定檔的腳本語言，最好還要能輕易編譯成執行檔，讓使用者毋須安裝執行環境就可以使用這樣的腳本。在這樣考量之下，最後雀屏中選的是 AutoHotKey。

到了 Linux 及 FreeBSD 上，則完全不一樣了。Linux 及 FreeBSD 版本的 Opera 在安裝時沒什麼需要使用者介入的地方，而且這些作業系統的使用者往往也比較熟悉文字使用者介面，所以選用了 Shell Script 來處理。

Mac OS X 又是另一種情況。由於 Mac OS X 內建了一套叫 Automator 的腳本語言，也支援 GUI，所以屆時「三太子」若要移植到 Mac OS X 上，就會選用 Automator 來實作。

不管選用了何種語言，如果能先撰寫虛擬碼及描述程式邏輯的文件，那麼日後要是不幸得改用不同的語言來實作時，就會比較輕鬆。不過請注意：許多軟體專案隨著時間成長，軟體本身的發展往往會超出虛擬碼及程式邏輯一開始的設定範圍，這時別忘了要跟著更新相關的文件及虛擬碼，以免產生了一堆過時而無法使用的文件，在關鍵的時候反而就幫不上忙了。
 

■ 源碼註解與文件

有了版本管理之後，修訂版日誌可以協助了解每一批修改的用意為何；但是修訂版日誌無論如何也無法取代源碼註解。源碼註解可以幫助明天的你還能看懂今天所寫的東西，也能幫你釐清邏輯上的瑕疵與漏洞──換句話說，詳細的註解其實主要還是幫自己的忙，其次才是幫其他人看懂你都在寫些什麼。

除了源碼當中的註解外，還要另外維護使用者文件跟開發者文件。使用者文件用來讓專案的使用者知道這個專案做了些什麼事、有什麼功能可以使用、有哪些東西可以調整或開關、如果出錯了可能是誰造成的；開發者文件則是讓其他有興趣參與開發的人，可以更迅速地上手，掌握整個專案的結構與步調。

雖然維護這些註解與文件所費不貲（「三太子」專案花在文件上的時間大約是三分之一到一半左右），但是卻會是物超所值的行動，因為藉由這些文件，可以讓整個專案更容易地被檢視，有瑕疵時也能更迅速地補正，因此使用者及開發者之間的關係更透明而直接，信任關係也就越強烈。「信任」正是一切社群的核心，妥善而完整的文件則是開放源碼專案累積信任的重要基礎。

「三太子」對 Opera 所做的一切處理，皆儘可能詳實地公布在網頁上，這樣不但能讓台灣使用者社群更放心地使用三太子，也能讓台灣使用者社群藉此機會更瞭解 Opera，甚至是以此為基礎，打造屬於自己的個人 Opera。
 

■ 訊息管道

任何一個開放源碼專案，有了名字、進行開發、有了文件之後，更重要的是得有個便於公眾取用的入口。在網頁時代，這個入口也就是一個網頁或網站。

但是光有網站還不夠，因為這年頭網站實在太多了，開放源碼專案也如過江之鯽，九成以上的使用者對任何網站都只會看一次──這些使用者可能是看到某些資訊入口網站或媒體的報導而來，但是離開之後就不會再回來。

對於健康的開放源碼專案來說，只有一次的高度關注是沒有用的，細水長流才是生生不息的象徵。如何能夠掌握那唯一一次的使用者來訪呢？在網站上提供源料，或者是利用 twitter 或 plurk 這類可供訂閱／跟隨的媒介，都會是不錯的作法。藉由這類管道，使用者就能源源不絕地獲得最新的更新資訊，誘使他們再度回訪。

有些開放源碼專案總是在新版本釋出的時候玩跟著撰寫釋出聲明，這對於專案發展來說幫助是有限的；正確的作法其實是儘可能頻繁地更新訊息，不論是網頁上的文件有修正，或者是專案源碼有變更，就算還沒有達成階段里程碑而不會釋出新版，也還是可以先放出風聲，一方面可以讓社群感受到專案的活躍，另一方面也能鼓舞社群回應，並避免已修正的問題重複回報。

如果每一則訊息，以及網頁上的每一段資訊，也都能有個靜態鏈結，那麼社群成員就更能把相關的訊息散佈出去，使整個專案能見度更高。
 

■ 多語

任何軟體專案，只要是會有前端使用者介面的部份，就一定要顧及多語的使用情境。這部份可以分成幾個不同的層次，循序漸進：

1. 在不同語言的環境之中，至少要能正確地顯示同一種語言的訊息
2. 在不同語言的環境之中，至少要能正確地處理同一種語言的輸入內容
3. 在不同語言的環境之中，至少要能正確地處理同一種語言、不同編碼（例如 Big5 跟 UTF-8）的輸入內容
4. 在不同語言的環境之中，能夠正確地按照語言環境變數，用不同的語言來表達相關訊息內容
5. 在不同語言的環境之中，能夠正確地處理不同語言、不同編碼的輸入內容
6. 在不同語言的環境當中，能夠處理不同語言及編碼的檔案名稱與路徑名稱

處理輸入內容的時候，重點在於要判斷輸入內容的原始編碼，統一轉換成 UTF-8 等通用編碼格式，再繼續做處理（正好 Opera 的設定檔都必須以 UTF-8 編碼來撰寫）。

處理訊息時，會遇到的問題則是要同時維護多種語言的版本；為了讓程式／腳本本身盡可能單純、簡化，這些訊息字串最好抽出另外處理，而不要嵌入主程式／主腳本之中。開放源碼界的 GNU gettext 是個相當成熟的國際化框架，當專案成長到某個程度時就可以予以採用，如此也便於把不同語系檔交付給不同的社群成員來負責。（當然在專案還很小的時候就率先採用 gettext 也很好，並沒有什麼不妥）

從網頁服務乃至於商業化的獨立遊戲，處處都可見到 gettext 的蹤跡，足見其成熟度。
 

■ 跨平台

軟體專案要如何跨平台呢？最簡單的辦法是使用本身就跨平台的開發框架，並且避開平台特定性的元件或語言模組。很不幸地「三太子」沒有辦法這樣做。因為 Opera 在不同平台上的安裝方式、檔案放置位置都有所不同，所以正如前述一般，「三太子」在不同平台上選用了不同的實作腳本語言。不過「三太子」一開始就決定了靈活與彈性的最高指導原則，儘可能避開平台限定的元件，因此很容易就可以移植到許多不同的平台上。

實務上，「三太子」的開發也是在不同的平台上平行（但是同步）進行，這時候就得說虛擬機器實在是開發者的好朋友了。

VMware 的 VMware Server、VMware Player 及 Sun 的 VirtualBox 都是開放源碼的虛擬化解決方案，另外微軟也有一套免費（但是沒有開放源碼）的 Virtual PC，都可以讓開發者在自己的電腦上準備好多種不同作業環境，用來開發及測試。

「三太子」最先完成的平台是 Windows，並且將多語訊息抽離出來另外處理，主要的腳本保持簡潔，又撰寫了詳細的註解，很快就整理出虛擬碼；在虛擬碼的協助之下，很快地就轉寫成 Shell Script 的版本，於是 Linux 及 FreeBSD 平台很快就處理完一半了，剩下來的部份就是將檔案的換列格式調整成 UNIX 格式，並且重新分配檔案路徑，調整檔案權限，然後就可以打包收工。
 

■ 檔案測試與釋出

不論做的變更有多小，檔案都應該要實際測試過再釋出，因為疏忽跟意外總是在料想不到的地方發生。前述虛擬化的做法還有一個優點，就是可以幫準備好的環境建立快照，日後就可以利用這些快照，迅速還原到用來測試的環境。包括全新的乾淨安裝，以及移除舊版後的再安裝、直接覆蓋的安裝、使用非預設路徑及設定的安裝等，通通都要測試過一遍。

在「三太子」的發展過程當中，最常出現的瑕疵是因為 Big5 衝碼導致腳本執行失敗，以及忘記更改版號，好在多半都有在測試階段發現，及時更正。

隨著專案規模擴大，要測試的流程與變數也會越來越多，如果可能的話，最好分配給社群成員來進行。不過為了要確認測試方式的一致性，應該要準備好測試說明文件，並且準備好檢核清單，方便社群成員回報。

釋出檔案時，除了應有釋出註記、版本沿革文件外，最好在檔名對不同的版本做區分，以免使用者同時下載多種不同版本產生檔名衝突。另外若是自行尋找空間放置檔案，則應該要盡可能尋找多個不同的下載空間，讓使用者能夠選擇對他們來說更為便利、迅速的下載來源。提供檔案的 MD5／SHA1 加總檢核碼是確保檔案下載完整的好方法，但是並非所有的使用者都瞭解如何運用加總檢核碼，所以釋出的檔案本身若能檢查自己的完整性，對於使用者來說將會更為便利。
 

■ 外交

檔案釋出了，對於一個軟體專案來說，才是真正的開始。當你的軟體投入廣大的使用者社群後，會面臨到許多你原本所沒有設想到的情境，也可能會激盪出更多不同的需求與想法，其中有些真的是非常珍貴的回應，但是也有一些會導致專案往奇怪的方向發展。專案一開始設立的基準此時就會是護身符了，理性、禮貌、平和地拿出專案基準，與使用者社群互動，就可以釐清八成的回應是否應該納入開發流程、應該納入哪個里程碑。

但是使用者社群並不是開放源碼專案唯一該接觸的對象。現今的軟體產業很少從上到尾靠自己就能搞定，尤其像「三太子」這樣的專案，除了接觸瀏覽器的使用者外，還有網頁及網頁服務的提供者，以及瀏覽器製造者（也就是 Opera 公司），也會與「三太子」的發展攸關。因此這些「上下游產業」也是「三太子」專案在發展過程當中，不斷聯繫的對象。

說實話，「三太子」專案的最終目標，是讓「三太子」專案可以不需要繼續下去──一旦 Opera 能夠針對台灣的使用者社群提供更好的預設值及功能，而網頁服務提供商也能更完善地支援 Opera，那麼「三太子」就可以下台鞠躬了。促成此事需要仰賴社群的力量，而一個目標明確、透明誠實的專案，則是凝聚社群力量的良好管道。

「三太子」專案首次釋出檔案後半個月內就有超過五千人次的下載數，並且在台灣及中國都掀起了一陣討論；目前已經有台灣的網頁服務提供商表達願意配合「三太子」專案修改產品的意願，而 Opera 的台灣辦公室、中國辦公室、挪威總部也都有相關的人員主動聯繫「三太子」專案，足見「三太子」專案至今的經營與發展方向，大致還算穩健、正確。
 

■ 結語

經營一個開放專案，跟經營一個開放社群，兩者都是相當不容易的工作，更需要相當的熱誠與精力，才有辦法保持日久彌新、穩健成長。「三太子」在這個領域當中，實在是非常年輕的一個專案；它到底會如何發展，沒有人能說得準。

身為計畫的維護者，我能確定的事情只有一樣：秉持著開放的心胸、開放的想法，保持開放的文件與開放的源碼，讓整個專案的內容便於整個社群開放取用，那麼整個社群在此專案上所投注的每一分每一秒，就都能累積下來，成為重要的資產。即便未來這個專案因故告一段落，這些資產也還是會陪伴著整個社群，讓整個社群能以此為基礎，繼續繁衍出其他的計畫。
 

■ 相關連結

「三太子」計畫與文件集
Opera
《The Art of Community》
Perforce 版本管理系統
AutoHotKey 腳本語言
鳥哥的 Linux 私房菜──學習 Shell Scripts
Automator 腳本語言
GNU gettext
VMware Server
VMware Player
Sun VirtualBox
Microsoft Virtual PC

[源碼秘技] 淺談簡報設計的技巧～以 Impress 為例（3）

＊圖文整合篇＊

圖文的比例

簡報的主題若能選擇能表達其意境的圖片，往往能傳達出比預期還要多的訊息，而且觀眾的印象也比較深刻，所以在投影片內適度地加入圖片，簡報的效果往往會更好。不過圖文之間如何安排？有了圖片之後，文字還可以如何加以精簡，好讓二者合一，發揮更好的效果？這是值得大家研究的大學問。
 

圖和文字的比例應該是多少才是最好呢？這可沒有一定的規則，多數的情形是：圖多於字、圖片所佔的面積大於文字會比較好，畢竟圖片總是比較賞心悅目一些。當然實際製作時還是要視情況而定，不是圖越多、越大就是越好。使用的數量、大小，還得看簡報的內容和版面設計而定。

至於圖片要不要經過特殊處理，如透明、漸層、濾鏡或特效等，一樣還是要根據整體版面的設計、配色和想表達的意境而定，不見得非用不可。而某些影像效果，簡報軟體也會提供，若想節省製作時間，不妨多加利用。

底下所示範的設計方式，是以多張不同的圖來襯托主題的圖片，讓觀眾在欣賞圖片時，就能自行聯想到簡報者想表達的核心概念，最後再以簡短的一句話，讓觀眾更加確認自己所瞭解的主題是什麼，如此可以達到讓觀眾印象深刻的效果。

步驟一：

增加一張投影片後，版面配置選擇「空白投影片」。

步驟二：

在繪圖工具列上按「取自檔案」鈕，以便選擇自己準備好的圖片檔案。

步驟三：

選擇存放圖片的資料夾，點選要加入的圖片後按「開啟」。

步驟四：

除非事先已經根據投影片的版面設計而把圖片製作成適合的大小，否則加進投影片的圖，通常還得設定一下大小。

這裡我們要把三張圖片排成一列，所以一定得要縮小圖片，因此在圖片上按滑鼠右鍵，點選快顯功能表的「位置和大小」。

步驟五：

在「位置與大小」標籤內，把「大小」這一區的「調整」勾選起來，然後「寬度」改為9公分。由於已經勾選「調整」，「高度」會跟著「寬度」等比例縮放。（唉！這裡的翻譯讓人更難懂！）

〔補充說明〕

縮放圖片也可以在選取圖片之後，直接拖曳上面的節點。如果同時按住 Shift 鍵，就可按照等比例縮放。只是用拖曳的方法不容易把所有的圖片都設定為同樣的大小，因此改用指定數值的方式來做比較好。至於以拖曳進行縮放的方式並不難，且為了節省篇幅，在此就省略不談。

步驟六：

接著我們要為圖片加上框線。在圖片仍舊是被選取的狀態下，按「圖片」工具列的「線條」鈕。
 

步驟七：

在「線條」標籤內，「樣式」選擇「連續」；「顏色」改為「藍灰色」；「寬度」是「0.15」公分；右下角的「角樣式」，則選擇「斜接」。全部設定完畢後，按一下「確定」。

步驟八：

用相同的方式，把想放進來的圖片全加進來，需要設定外框線者全設成一樣，並調整好圖片的位置。

接著，按一下繪圖工具列的「文字」鈕。

步驟九：

拖曳出文字框並輸入所需的文字，接著把文字選取起來（或點選文字方框），在文字格式化工具列上，「字型大小」設為 36 級字並加上「粗體」，最後「字型顏色」改為「白色」。

步驟十：

拖曳綠色的節點調整好文字框的大小，並把它移到最右邊，讓文字框與投影片的右邊界對齊。

步驟十一：

這樣子的畫面不但賞心悅目，且更能點出主題之所在。

使用圖片時，要特別注意文字與圖片的閱讀動線，如果安排的不好，觀眾就得費心去尋找重點。通常，橫向文字的閱讀動線是「Z」字形，進行圖文的版面安排時，不妨多試試這個原則。

最後要提醒大家，除非圖片是自己生產的，否則使用圖片一定要注意授權問題。如果獲得合法授權，也別忘了和授權人之間的使用協議，該加入的相關資訊，可千萬別忘了。

全版面的圖和文字的搭配

在單一投影片內用多張圖片，也不見得全是好事，這道理和文字用很多一樣，只是投影片的面積有限，產生的問題不像文字那麼嚴重而已。其次，要找到多張合用的圖片，老實說，不是想像中那麼容易的事。

這時可以考慮另一個不錯的方式，就是選用一張能涵蓋整張投影片的圖（也就是標題所說得全版面的圖），文字則直接加在圖上面。不過，想要採用這種方式，圖片不但要經過細心的挑選，有時還得經過適當的影像處理，例如部份採用單色或透明漸層，預留好文字所需的空間，而加入的文字更要注意精簡程度和外觀設定，否則很容易破壞圖片的美感。講究一點的朋友，連文字都是用影像處理軟體特別設計過，好配合圖片的意境。
 

步驟一：

加入一張完全空白的投影片，然後按繪圖工具列的「取自檔案」鈕。

步驟二：

選擇存放圖片的資料夾，點選想要加入的圖片後按「開啟」。

步驟三：

加入圖片後，調整好圖片的位置和大小（範例的圖已經事先以影像處理軟體調整好尺寸，大小和投影片一樣），接著在投影片以外的空白處按一下，取消圖片的選取狀態。然後在繪圖工具列上按一下「圖說文字」旁的下拉式清單按鈕，從出現的顯單中，點選「圓角矩形圖說文字」。

步驟四：

在投影片上拖曳出一個「圓角矩形圖說文字」的框。

步驟五：

表示說明來源的尖角上有個黃色的控制點，拖曳它可改變方向和大小。這裡我們讓它指向圖片上的荷花。

〔補充說明〕

這裡使用圖說文字的用意，除了要使用擬人化的效果，也希望加入的文字會比較清楚明顯。其實，大家也可以利用影像處理軟體製作一張便利貼的影像，放置在全版面的圖上面，在其上加入文字，可營造出「備忘」的效果。

步驟六：

在「圓角矩形圖說文字」框內按二下滑鼠，即可切換到文字編輯狀態，我們就可以輸入需要的文字內容了。

把這裡的文字分為兩個段落，一來方便把部份文字變得特別大，好強調重點之所在；二來不會因內容太長讓「圓角矩形圖說文字」框變得又扁又長，進而破壞圖片整體構圖的平衡和美感。

步驟七：

把要強調的重點（本例為10%）加以放大（此處為136級字），其他的文字則設為24級字並加上粗體。最後把所有的文字都設為藍色。

要注意的是，設定好文字大小後，「圓角矩形圖說文字」框要調整一下大小和位置，好配合整體版面的配置。

步驟八：

透過線條和充填工具列，把外框的線條樣式設為「隱入的」，顏色則改為「黃色3」，最後按一下「平面」鈕。

步驟九：

切換到「陰影」標籤，勾選「使用陰影」，「間隔」改為「0.2」公分，顏色則設為「白色」。設定好了之後按一下「確定」。

步驟十：

藉由圖片的意境和超大的文字設定，我們就可以達到強調10%這個數據的效果。

〔補充說明〕

某些朋友可能和 Attila 一樣不擅長處理圖片，此時除了可以請朋友幫忙（幫忙後，別忘記獻上自己的感謝），也可以到某些提供免費授權的圖片網站去下載。當然，這一類的網站提供的圖片數量通常有限，必要時也可到專業的網站去購買合法圖片來用。

或者學一下 Attila，平常出門時，隨手用數位相機拍下所有的美麗事和物（拍人物照，還有隱私和肖像權的問題，通常會被 Attila 省略），以備製作作品的不時之需。

簡報設計的技巧其實很多，這裡所介紹的只是滄海之一粟而已。其實 Attila 最想傳達的理念，是簡報設計一定要把重心放在「凸顯主題」這點。畢竟溝通要講求效果，如果講得天花亂墜，投影片也提供了相關資料，但沒辦法讓自己的想法確實傳達給觀眾，那簡報不就白費力氣了？還不如直接提供相關資料，才不會浪費彼此寶貴的時間。

然而投影片做的好，簡報的內容就會好嗎？Attila 的答案傾向肯定。因為製作投影片時，通常也會仔細思考演講的相關內容，也就是說會針對即將要進行的簡報，加以斟酌和取捨。所以製作投影片的過程，不僅僅只是為了製作出一份簡報檔，同時也是在為自己決定簡報時的口頭內容。只要認真的把投影片設計好，簡報的內容通常也不會差到哪裡啦！

當然，二者之間還是有落差，平時還是要多參考各種演講技巧，並且經常演練，有機會上台時千萬不要害怕，而是要把它當作訓練和檢討的寶貴機會，多多累積經驗，以後才能進行更好、更棒的簡報！

（待續）