Silverlight 2 = Java Applet in .NET World

對於資訊技術的發展，我總覺得很有意思，許多過去被提出但似乎失敗的想法總是會透過不同的方式捲土重來，比方說過去總被認為執行速度太慢、不夠嚴謹的scripting語言，居然就因為早期寫CGI的Perl、瀏覽器都支援的JavaScript、廣為流行的PHP、甚至最近的Rails中的Ruby而佔有一席之地，只要是網頁開發，到處都是scripting語言。

而十年前Java初登場時最紅的Java Applet，似乎越來越黯淡，不過就在我最近瞭解Silverlight 2時，卻有一種莫名其妙的熟悉感，這不就是.Net下的Java Applet嗎？只是當然Silverlight進化些，有現成的動畫與影音機制，但骨子裡不就是Java Applet嗎？

怪事第二件：Google Chrome跑了就出錯！[賽門鐵克SEP軟體相衝]

這兩天大熱門就是Google Chrome，想當然要試用一下，沒想到在我主要的工作機上，就是無法正常運作，一跑就會出現以下的畫面：

這是甚麼狀況啊？厲害的是果然如同Google說的，每個Tab都是不同的Process，按下「確定」後，Chrome並不會結束，還是繼續運作，但是在網址列不管輸入甚麼，按下「Enter」後，一樣出現這個錯誤，屢試不爽。另外一台機器上則沒有問題，可以正常執行，天啊，Google大神，救救我吧！

[更新]根據找到的 Problems installing Google Chrome when Symantec Endpoint Protection
is installed. 這一串討論顯示，賽門鐵克的SEP軟體可能就是原因，而賽門鐵克官方的論壇上也有一篇提到暫時的解法，不過我還不確定這種解法會對SEP有甚麼影響，畢竟這是防毒軟體啊！

今日怪事：Microsoft Office Word、Excel 及 PowerPoint 2007 檔案格式相容性套件罷工

〈Microsoft Office Word、Excel 及 PowerPoint 2007 檔案格式相容性套件〉一直是我很倚賴的工具，因為許多作者都更新到Office 2007版，但我的電腦只配有Office XP，這幾個月靠著微軟提供的這套工具，讓我除了轉檔過程比較耗時外，還是可以正常工作。可是就在昨天開始，不曉得是甚麼狀況，用這套工具開啟Word 2007的檔案時，就會出現以下這個交談窗：


顯示「本軟體為預先發行版本的相容性套件，僅可用來開啟預先發行的Office 2007檔案。您要檢查是否有更新版本的相容性套件嗎？」如果按「取消」，當然就真的取消了，不會找新軟體，也不會開啟檔案；但就算按下「確定」，雖然會帶到下載頁面，但也是2007/11/19發行的版本，而且Word一樣不會開啟檔案。即使試過重新安裝相容性套件，問題一樣會產生，天啊，請問這要怎麼辦啊？

[更新]雖然透過朋友商請微軟支援工程師處理，還使用遠端連線進來操作，不過經過一個多小時的努力，還是沒有進展。今天跟MIS研究，利用Office修復功能之後，反而出現新問題，現在不論是開哪一個Office軟體，都會看到這樣的交談窗：

按下「確定」後就關閉軟體，變成甚麼檔案都開不了了。好再經過Google之後，找到了這一篇〈執行 Office 2003 顯示「目前的使用者尚未安裝 Program_name…」〉，依據該文最後的解法，終於可以正常開啟Office了！接下來還得試試Office 2007相容性套件。

GMail與CSS

如果您需要發送電子報，而且設計電子報時會使用CSS，那麼您得注意一下，GMail在顯示HTML郵件時，會將<style>元素所指定的CSS內容剔除掉。所以若是您的電子報內容會依靠CSS定位與展現特效，那麼GMail用戶收到時，可能就會看到錯亂的郵件內容。即便是郵件中以夾檔方式寄送的HTML檔案，如果以GMail提供的檢視功能，一樣會剔除掉<style>元素，在瀏覽器檢視原始碼就可以明確的看到這樣的結果。

面對這個問題，我個人僅有兩項建議，一是電子報內容一定要在醒目的位置留有連結，可以讓收件人點選後連到發報人的網站觀看正確格式的內容，這樣不論收件人閱讀郵件的環境發生任何狀況，收件人都有最終的機會可以閱讀電子報。另外，這也是迫使內容設計者遵循XHTML良好文件結構的契機，目前大多數人仍然只是將CSS視為輔助外觀設計的技術，HTML的內容中仍然會混雜一些與版面配置及外觀顯示的設定，使得在CSS失效時，HTML內容無法以良好的文件結構展示，甚至因為不同瀏覽器處理某些影響外觀的HTML標籤或屬性的差異，導致無法閱讀的窘境。

有關各Web-Based郵件服務對於CSS處理的差異，可以參考CSS support in HTML emails of Hotmail, Yahoo! Mail and Gmail。

電子書閱讀機的殺手級內容--漫畫書？

電子書閱讀機出現在市場上已經不知道多少年了，不過一直以來似乎都沒有造成太大的迴響，雖然這中間對於紙本書與電子書的戰爭也引發了許多人的猜想與推論，但我總覺得要能夠讓電子書閱讀機突破現況，總得有個殺手級內容（Killer content），讓你真的會很想隨時隨地閱讀、卻又不用帶上一大堆的書。

可想而知，這個殺手級內容決不是一般電子書閱讀機附贈的哪種甚麼經典文學、四書五經，一方面普羅大眾絕沒這麼認真，而且就算要認真起來，讀這些書時恐怕都會很想寫寫心得、記記筆記之類了，用電子書閱讀器不但無法提供前述功能，也缺少了紙張所擁有的fu啊。

直到最近一來開始嘗試用電腦看漫畫，一方面看到了這麼一篇新聞〈Computex 2008：Netronix 的 300 美元電子書閱讀器〉，其中的這一張展示畫面（圖片引用自癮科技網站）：

我想，應該就是它了，電子書閱讀器的殺手級內容--漫畫！漫畫應該是唯一一種大家會想隨時閱讀、但是冊數又很多，閱讀時也不大會作甚麼筆記的書種。如果能有一部輕巧價廉的漫畫書閱讀器，再跟漫畫出版公司推出月租型服務（當然，你也可以靠其他方法取得漫畫，是吧？），那不就是絕配？或者十大漫畫書坊之類的也有漫畫下載服務，這樣一來，在通勤時間看完一部《20世紀少年》，豈不是太方便了。等等，別看得太高興，坐過頭啊！

呵呵，朋友，你說這樣子配好不好？

翻譯名詞：render

render這個名詞在程式設計的原文書中很常出現，本來我一直想這個詞要怎麼譯才會達意，剛好譯者劉祖亮先生在翻譯《Essential WPF》一書時提供了一個好的譯法：演算上色（我不確定是否有其他地方已經這樣翻譯），覺得非常恰當，因為render通常只的並非一般的上色，而是要先經過依據特定的規則運算，來決定某一個位置的顏色，然後在將該顏色繪製到該位置上，譯為「演算上色」既簡單又明白。

編輯不可不知：「校對」源考

今天翻看《書的迷戀》一書，在p65頁提到「古人治學，首重校讎。」甚麼是「校讎」呢？就是校對的工作啦，也稱為「讎校」，「讎」也通「仇」，唐李善《文選‧魏都賦注》中說：「讎校， 一人讀書，校其上下，得謬誤為校；一人持本，一人讀書，若怨家相對，故曰讎也。」就是指讎校時需要兩個人，一個人拿個書唸，一個人對照著看正確與否，這兩 個人相對，好似仇人一般，所以稱為「讎校」。

其後根據何焯《義門讀書記》說：「一人刊誤為校，二人對校為讎，後人嫌讎字，易其名為校對，對即讎也。」也就是說，後來的人覺得「讎」字不雅，才改稱為「校對」。

原來如此，編輯當不可不知！不過突然想到，現今還能落實二人對校的，恐怕已經不多了。

書賣幾本才算好？

很多作者或是編輯都會思考這個問題，希望能夠評斷自己寫的書或是編的書到底賣的好不好？剛好同事給了我一個參考的依據，根據行政院主計處《九十二年電腦應用概況調查統計結果分析摘要》的資料顯示，民國92年時台灣資訊就業人口中，程式設計人員大概有21,646人，系統管理人員大概有20,824，如果我樂觀的假設其中有1/10的人會買我編輯的書（賣過東西的人應該不會認為目標族群的1/10是過低的期望吧？），那也就表示像是ASP.NET AJAX或是Winodws Server 2008這樣題目的書，如果能賣到差不多2000本，應該就算是不錯了。

這下子問題就來了，如果2000本就算是不錯的話，對於許多每頁單價低的書來說，可能都是賠錢貨哩？如果再把這幾年來技術人員西進大陸的趨勢算進來，會不會其實2000本都還是樂觀的期望？果真如此，也許我得好好規劃未來了，呼！

延伸閱讀

• 同一年行政院主計處自己公布的報告中，都沒有人數統計的資料，頗為奇怪？
• 93年的調查報告，一樣沒有依職務別的人數統計資料，但有退職、新進人員比率之類的數據，也許可用來推算。
• 94年的調查報告。
• 95年的調查報告。