highlight.js

星期四, 10月 18, 2007

Photoshop問答:筆刷的opacity(不透明)與flow(流量)的差別?

我並不是Photoshop的使用者,不過因為剛好同仁有發生這樣的疑問,所以就想找找看有沒有答案。如果您在Photoshop中單獨設定筆刷的opacity(不透明)與flow(流量),也就是譬如說保持不透明為100%,變動流量的值;或是保持流量為100%,然後變動不透明的值,就會發現好像兩者的效果是一樣的,那麼為什麼要有不透明與流量兩種值呢?

為了解答這個問題,所以我查閱了相關的說明,終於瞭解了這兩個值的差別。這兩個值其實是以不透明為主,設定的是筆刷繪製結果的不透明度。不透明值越小,筆刷繪製的結果就越透明。那麼流量是甚麼意思呢?根據Adobe官方網站上Photoshop CS3的說明文件,流量的意義如下:

流量
設定您在某個區域上移動指標時套用顏色的速率。 當您在某個區域上繪畫時,如果按住滑鼠按鍵不放,色彩量就會依據流量速率而逐漸增加,直到達到不透明設定為止。 例如,假設您將不透明度設定為 33%,流量也設定為 33%,那麼您每移到某個區域上一次,上面的顏色就會以 33% 的比例趨近於筆刷顏色。 除非您放開滑鼠並且再次在該區域上運用筆觸,否則總和將不會超過 33% 不透明度。

講明白一點,就是在不放開滑鼠按鈕的前提下,筆刷每次經過同一區域時,該區域往不透明值前進的速度,而這個速度是以剩餘距離的百分比來表示。也就是每多經過同一區域一次,就會以該區域目前的不透明度與不透明值的差距,乘上流量所設定的比例增加不透明度重新繪製(注意,是重新繪製,也就是當成該區域之前沒有用筆刷繪製過,然後以筆刷顏色套用計算出來的不透明度繪製)。所以如果按住滑鼠來回移動筆刷,重複經過的區域就會越來越接近不透明值而顯得越來不透明,最終趨近於不透明值。

舉個例子來說,如果不透明設定為50%,流量設定為20%,那麼不放開滑鼠按鈕用筆刷經過某一個區域第一次時,該區域的不透明度(一開始就是0%)距離50%為50%,所以不透明度會增加50%*20%,也就是10%。如果再經過一次,因為現在不透明度是10%,所以距離50%為40%,所以不透明度就會再增加40%*20%,也就是8%,變成以18%的不透明度重新繪製該區域。依此類推,如果再經過一次,目前的不透明度18%與50%的差距為32%,所以不透明度就會再增加32%*20%,也就是6.4%,變成24.4%。依據這樣的推演,每次經過同一區域,不透明度就會距離50%越來越近,最終趨近於50%。也正因為流量所描述的是接近不透明值的增量,所以稱為流量。示意圖如下:


以下的圖就示範了上述的過程(請觀察多個圓交疊的部分):


多次的變化圖如下,你可以看到不透明度逐漸增加,最終趨近50%的效果:


要注意的是,滑鼠按住不放來回經過同一個區域,和在原地點點按滑鼠的效果是不同的。以下的圖仍然以不透明度50%,流量20%為例。若是在原地點按滑鼠,第一次點按時不透明度一樣為差距50%*20%,就是10%繪製。但第二次點按時,仍然是以10%的不透明度繪製,但是因為該區域的顏色已經因為上一次點按用筆刷繪製了10%不透明度的顏色,所以已經比尚未繪製前更接近筆刷的顏色,第二次繪製後,就會又更接近筆刷的顏色。依此類推,如果多次點按,最終就會趨近筆刷的顏色:


以下是多次點按的變化,你可以看到大概5次點按後就是50%的不透明度,一直點按下去,就會變成筆刷的顏色:


所以如果只是繪製一次,就完全看不出來不透明與流量的意義,甚至因為互換兩個設定值的結果看起來都一樣,使得許多人以為不透明與流量的作用相同了。

延伸閱讀:

星期三, 10月 03, 2007

GET、POST與cache的關係

在大部分的AJAX書籍裡頭,只要解說到XMLHttpRequest的open方法時,一定都會提到GET與POST的差異,不過大抵上講的都是GET會把參數直接加在URL上,使得一方面會在瀏覽器的網址列上洩漏傳遞的資料,另一方面則是會受限於URL長度的限制,而無法傳遞較大量的資料。但是GET與POST還有一個很關鍵的差異,在大部分的書上都沒有提到,就是GET的response會被cache下來,但是POST不會。

由於cache的基準是以URL為對象,如果傳遞的參數不同時,很難發現cache的存在。但如果URL相同時,就可能造成程式出現靈異現象。舉例來說,我的同事剛好在撰寫一個AJAX版本的聊天室範例,由於純屬示範性質,所以採取很簡單的作法(事實上有許多上線運作的聊天室也用同樣的方法),將參與聊天的發言不斷增補到一個文字檔尾端,而用戶端就透過AJAX機制,定時向伺服端取回儲存發言的文字檔,顯示在瀏覽器上的聊天區域。

假設這個文字檔就叫做chat.txt,你可以想像會發生甚麼事。由於我的同事使用GET方式叫用XMLHttpRequest的open方法,並且URL參數都指定為"chat.txt",所以每次取回的都是cache中的chat.txt,造成不論如何發言,瀏覽器上顯示的結果都沒有變化,好像剛剛的發言石沈大海一樣。

有些人為了解決這個問題,採用了一些小伎倆,例如將URL參數改為傳入"chat.txt?"再加上日期時間,強迫URL每次都不一樣,而使得瀏覽器不會傳回cache中的檔案。這樣的作法固然有效,不過最簡單的方法,就是將GET改成POST,就一切正常了。

GET與POST的這點差異,主要是因為GET原始設計的語意,就是單純的查詢,只要是相同的查詢條件(傳遞的參數內容),不論查詢幾次都應該傳回相同的結果。由於這樣的原因,瀏覽器端的實作就會把GET的response給cache下來。反觀POST,原本的語意就是將資料遞送回伺服端處理,所以瀏覽器就不應該自作聰明,不將資料傳回給伺服端而逕行取用cache。

GET與POST的這點差異雖然很不容易發現,但在除錯環境困難的AJAX程式開發中,卻很可能讓程式員耗費時間精力,找不出問題在哪裡。

延伸閱讀

星期四, 8月 16, 2007

日文翻譯的陷阱

日文因為使用了大量的漢字,所以對於我們來說,有了幾分的親切感。不過也正因為如此,埋藏了許多陷阱,有時候不知道對應的適當中文詞彙時,很可能就會直接用日文漢字草率了事,但實際上中文讀者看到了這個由漢字組成的詞彙時,卻無法從漢字聯想到真正的意思。我自己不懂日文,以下斗膽舉例,如有謬誤,還請指導。

有些詞彙雖然和中文不同,但還可以猜出意思的,例如「16進制」,中文通常說「16進位」。但有些詞彙單看日文,就比較難猜出意思。比方說,在CSS的書籍中,會出現「段組レイアウト」。「レイアウト」是外來語layout的日語拼音,在CSS中自然指的是版面設計,那麼「段組」是什麼呢?「段」是colunm的意思,「組」就是排版,整個「段組レイアウト」指的就是多欄版面設計。如果直接用日語譯為「段組版面」,大概就很難讀懂意思了。

當然,有些詞彙因為崇日風尚,大家習以為常,也就懂意思了。像是濫用程度最高的「達人」、「殘念」、「萌」等等,雖然如此,使用上我認為還是有斟酌之處,因為許多詞彙我們未必真的理解日文精確的含意,比方說「達人」和「玄人」是有差異的,如果人人皆稱「達人」,可就怪了,哪有那麼多「達人」?

最可怕的是那些讀起來好像完全正確,但其實意思錯誤的日文漢字,譬如說日文中橫的稱為「行」、直的稱為「列」,與中文的直行橫列相反,如果翻譯時不細心,直接照用,那就麻煩了。這特別是在資料庫或是Excel等大量出現表格的文章時最為嚴重。

你可以說我古板、或者民族情結作祟,我很不喜歡中日文夾雜,用在書名一兩個字勉強也就罷了,如果內文行文之間,充斥日文詞彙,我總是覺得渾身不舒服,讀起來腦筋不斷打結。當然,我不排除也許有些詞彙日文其實是真正保留了中國古文,而我們現代的用法才是瞎搞,這就很難說了。

星期六, 8月 04, 2007

BrowserCam:多平台多瀏覽器網頁測試服務

我的工作裡有些時候必須處理翻譯書的螢幕抓圖,尤其是一些跟網頁設計有關的書籍,常常會提到同樣的網頁在某一種平台上的某一種瀏覽器上會有什麼樣的問題,然後就秀出一張執行畫面。不過你知道事實上多數人都不可能有那麼多種機器在手邊,也不大可能還安裝有古時候的瀏覽器,所以一旦需要抓取這些圖的時候,如果只是Windows+Linux也還好,但若是需要Mac,我就沒轍了。還好,最近剛好看到BrowserCam網路服務,可以針對指定的URL抓取在多種作業系統下不同瀏覽器的多種版本的畫面。

以下就是這個網站在幾種作業系統下的瀏覽畫面:


要提醒您的是,BrowserCam是付費的網路服務,原本的用途是讓網頁開發人員測試自己所設計的網頁,以便確認不同平台上的使用者都可以看到正確的畫面。不過如果您只是需要抓幾個圖的話,可以申請24小時200張圖限制的試用帳號,利用一天的時間把所需要的畫面抓好。另外,付費使用者最大的好處就是可以透過VNC實際登入到提供服務的機器上,進行像是拉下網頁上的選單之類必要的操作後再抓圖,更是方便許多。

延伸閱讀:

星期五, 8月 03, 2007

SQL Server仍舊維持霸主地位

SD Times報導看到,依據BZ Research在2007年6月針對軟體開發經理人員進行的2007 Database and Data Access, Integration and Reporting Study調查顯示,微軟的SQL Server仍然是資料庫市場的霸主,如果單純以是否使用某種資料庫產品來回答,佔比如下圖:

你可以看到SQL Server遙遙領先,不過這裡的數字包含了過往的舊系統。如果以最近完成的專案所使用的資料庫系統來統計,就如下圖所示:

上圖中一樣把包含舊系統的數字列出來,以方便比較。你可以看到SQL Server仍然是大幅領先,而Access則明顯得落後Oracle了(我知道,拿Oracle和Access相比有點怪),MySQL就偏低了。

根據報導中所說,SQL Server勝出的原因其實大家應該都猜得到,就是簡單易用,而且和開發工具有高度的整合。因此,除非認定Oracle才是企業級資料庫業界標準的受訪者以外,大多會選用SQL Server。另外,有些受訪者認為中小型企業普遍裝置有SQL Server,而大型企業則會有Oracle,因此開發專案時就會遷就企業現有的資料庫系統。值得一提的是,部份受訪者也表示考慮用MySQL替換掉Oracle。

有趣的是當問到選取特定資料庫系統的考量因素時,熟悉度、信賴度、開發成本低、佈署成本低等自然不在話下,但是傳統觀念中的「記憶體耗用程度低」反而只有3.1%的人關注,而「容不容易得標」也只有1.9%的人會考量,可見得大多數的軟體人員最重視的還是專案能不能儘速完成哩。

書介:版面設計概念學習東西軍


如果您對於版面設計有興趣,或者是和我一樣工作上需要與美術人員溝通,想要自修一點版面設計的概念,那麼來自日本的《 設計的文法──忍不住想動手的平面設計書》與來自美國的《寫給大家的平面設計書》這兩本寫給非設計科班出身的讀者看的書應該就非常適合。

這兩本書相同的地方在於把平面設計本身無關設計天份而能規則化的部份,透過簡單扼要的歸納說明與實際的範例展示,讓讀者能夠確實的體會。而事實上,兩本書在這個部份所提出來的設計規則也極為相近,這當然不是什麼奇怪的事,因為談的是通則,而不是個別設計師的獨門創意,如果差異很大,自然無法成為大家可以依循的常規了。

雖然談的主題相近,不過兩本書還是有些不同之處。首先,《 設計的文法──忍不住想動手的平面設計書》一書的範例比較貼近實際成品,而《寫給大家的平面設計書》中的範例則比較像是單純為了說明而設計;另外,前者也包含了比較多長篇文章排版的概念,而後者焦點著重在單頁文件的設計,所以如果您有製作書籍的需求,那麼我就會比較推薦前一本書,但如果只是設計一些宣傳單、小海報,那麼後一本書就很足夠。

另外還有一點很重要的是,由於文字天生的差異,日文與中文的相似性使得第一本書對於文字處理的相關主題能讓讀者有比較直覺的理解,因此閱讀上與實際應用上會比較直接。當然,如果你預算允許,我還蠻建議兩本書都買來翻一翻,畢竟同樣的事情,未必只聽一位老師就能懂,同時接受東西方精華也不錯啊!

延伸閱讀:

星期四, 7月 19, 2007

編輯不願面對的真相:拖稿原因揭密

從事編輯一段時間後,一定會遇到的就是拖稿,你一定很想知道為甚麼,而你的主管更是需要你給的理由,於是你就會從譯者或是作者口中聽到一些說法:
  1. 「快要寫完了,晚上就會寄給你。」
    意思就是你下班後我可能就會寄給你,但明天上班時答案才會揭曉。
  2. 「已經寄出去了,你沒收到嗎?」
    別先懷疑作譯者,很可能他用的附件檔案格式被你的MIS英勇的擋掉了。
  3. 「你給我的FTP不知道為甚麼連不上去?」
    先自己連連看吧,況且作譯者未必熟悉FTP。
  4. 「我已經燒成光碟到郵局寄出去了!」
    你只好等個三天再說囉,或是急的話自己請快遞去拿,別郵寄。
  5. 「我硬碟掛點了,得等我修好重灌!」
  6. 「我中毒了,開不了機!」
    以上兩種,除了相信,你不大能做些什麼,或者你去幫他重建系統?
  7. 「我要出差,下週回來才能寫稿。」
  8. 「我家人生病,要去照顧他。」
    以上兩種,只能相信,硬要去查證是沒有必要且魯莽的行為。
  9. 「嘟..........」、「您撥的電話未開機」、「將為您轉接語音信箱」、「您撥的電話號碼是空號,請查明後再撥」
    這一種就表示你已經達到編輯的最高境界,把人給蒸發掉了,因為聯絡不上,你永遠不知道發生了什麼事,甚至想把每一份報紙的社會新聞都詳細看過,確認沒有任何意外。
對了,經過上述各種狀況拿到了珍貴的稿件時,可能還有難關等你突破:
  1. 壓縮檔打不開?
  2. 壓縮檔打開裡頭空空如也?
  3. 壓縮檔打開裡頭好豐富,但都不是你要的稿件?
  4. 果然是稿件,咦,沒寫完?
  5. 收到一張空片?
  6. 收到一張DVD電影?
  7. 收到一張無法讀取的光碟片?
  8. 收到沒有夾檔的mail?
相信我,以上這些我全部都遇過,不過我相信這都是意外,我也當過SOHO、也當過員工,將心比心。

加油啊,稿件尚未完成,大家仍需努力!