總網頁瀏覽量

咕狗大神

顯示具有 我的工作 標籤的文章。 顯示所有文章
顯示具有 我的工作 標籤的文章。 顯示所有文章

2012年8月18日 星期六

Regular Expression

摘錄 wikipedia 正規(常規)表示式: http://zh.wikipedia.org/wiki/Regular_Expression

最近剛好要用到文字的 parsing ,所以複習一下,也順便作個筆記,以免再度失憶。

幾個比較常用的如下:


符號 意義 範例
. 任意字元 regex =@"^thank."; regex.match("thank u"); regex.match("thankx");
? 出現零次或一次 regex =@"^thankx?"; regex.match("thank u"); regex.match("thankx");
* 重複出現任意次數(含不出現) regex =@"^thankx*"; regex.match("thank u"); regex.match("thankxxxxxx");
+ 至少重複出現一次 regex =@"^thankx+"; regex.match("thankx"); regex.match("thankx");
{n} 必須重複出現n次 regex =@"^thankx{3}"; regex.match("thankxxx");
{n,} 至少重複出現n次 regex =@"^thankx{3,}"; regex.match("thankxxx"); regex.match("thankxxxxxx");
{n,m} 至少重複出現n次,但不超過m次 regex =@"^thankx{3, 5}"; regex.match("thankxxx"); regex.match("thankxxxxx");
[^...] 中括弧裡面的字元以外 regex =@"^th[^iou]nk"; regex.match("thank"); regex.match("thenk");
其他的有用到再寫。

2012年5月23日 星期三

人生奇景六:舉辦與辦理,兩小時

『舉辦』跟『辦理』這兩個詞有什麼不同嗎?

在這兩年的工作裡,我最常遇到的狀況,就是組長招集所有組員開會,討論投影片的標題,該用『舉辦』還是『辦理』,光是這兩個詞就會用掉兩個小時。

諸如此類的還有很多,像是:『發展』跟『開發』、『推動』跟『推廣』等

每當開會為了討論這些名詞,我都忍不住想要破口大罵

依我看,這個單位不是什麼產業推動,而是心靈推動、心靈改革,經歷過這些事情以後,還有什麼事情會讓我生氣呢?舉辦&辦理,so what!

下一站,衝啊

今天我終於離開了現在的單位,正式的離職生效,再也不用去管那些虛假吹牛拍馬屁的規劃,再也不用忍受組長莫名其妙的幻想,再也不用吃下無窮無盡隨手丟棄的大便,我真是開心啊~

來這個單位兩年,感覺就好像在當兵,每個人都是長官,每個長官的話都要聽,每個長官隨口亂講的都是命令,每個命令都是任務。

我還記得我來面試的那天,我的主任跟我說,產業推動是需要熱情的,不是為了賺錢,而是要讓整個產業都賺錢。但是我來這裡,卻發現根本不是這麼一回事,哪裡有產業熱情呢?都是為了民間收入而揮霍人力,用很便宜的國防役員工,去幫業界客制化軟體,然後吹噓自己做的有多好,結果得到的都是負面評價。

來這裡最大的成就與收穫,就是參加國際數位出版論壇,共同參與制定了 epub 3.0 的國際標準。但是很可笑的是,這樣的成就,在工業局以及單位主管的眼裡,竟然是不屑一顧、一文不值的。

如果我們國家的資訊,需要如此依賴這個單位,那我真的認為沒救了。當然,我認為主導資訊發展的工業局,應該要負最大的責任。

無論如何,這一切都結束了,我唯一要做的,就是儘快回憶起我塵封已久的技術能量,拼命的往前衝~

這兩年,就當作我身為一個技術研發工程師,留職停薪義務幫忙資訊產業進行數位出版的推動吧。

掰掰囉,這帖令我難以忍受的膏藥。

人生奇景五:比公家機關還要官僚

說到離職,我想天底下大概沒有哪個單位比我這間還複雜吧,而最讓我印象深刻的,是我離職的交接程序單,為了一個簽名,等了差不多兩天。

話說當天,我把資料都跑完了,打個電話問主任的秘書(你沒看錯,我這個單位,主任就有秘書可以用),問他方不方便去找主任簽名。秘書就說不方便,要簽名就把單子放他那邊,他會統一給主任簽名,我心想也好,省得跟主任打照面。

結果一大早拿過去,等到下午四點還沒消息,我就跑去問秘書,秘書就說主任很忙,整天都在開會,簽好了會叫我。就這樣,那天直到下班我都沒拿到簽名。

隔天早上,秘書通知我去拿單,我以為簽好了,結果發現沒簽。秘書說,主任要求我組長也要簽名,他才願意簽。這有點龜毛ㄟ,按照規定,所內的流程要組長跟主任簽名,會內的流程只要主任跟所長的簽名,加上我組長出國,我根本拿不到他簽名。我問秘書,請組長代理人可不可以,秘書說不行,一定要組長本人。我說組長回國,我都已經離職好幾天了,這樣我無法往下跑程序,會影響到我離職。秘書說要離職就離職阿,流程不會找同仁事後跑完就好了。馬的~這真的不是人話,哪有人離職日當天無法跑完行程,還要找人事後才跑?

回到座位我超級沮喪,找人去跟秘書溝通,秘書堅持就是要我組長簽名,誰代簽都不行。我實在很火大,覺得這太過分了,我幾乎打算去找勞委會申訴。後來我去問所長秘書,所長秘書打電話過去跟對方盧了一陣子,對方才鬆口說找組長代理人簽名也可以。

當然,這次又等了大半天,直到下午三點左右才簽完。

結束了這兩年,我忽然覺得跟當兵很像,每天都作一些自己以為對國家社會有貢獻的事情,結果事後才發現,政府跟主管根本不在乎產業發展,只在乎有沒有亮點可以上報上新聞,就這樣數饅頭過日子,一不小心,日子也很接近退伍/離職了。

2012年5月21日 星期一

人生奇景四:跑不完的離職流程

我從來沒想過,一個離職的流程會需要跑滿一整個月,這大概只有我這份神奇的工作單位才辦得到吧!

從我利用電子簽章送出我的離職簽呈開始,隔天我的直屬主管就簽過了,然後等了一個禮拜,怎麼沒有進一步消息呢?我開始到處打聽,才知道原來我的上上級主管要先跟我約談過,才會簽章。好吧!那就安排一下時間吧,結果這一安排,又過了好幾天。

我上上級主管問我,怎麼剛來就要走,來滿一年沒有。我心想,你連我來多久都不知道,那還約談什麼呢?然後硬撐問了一些問題,撐滿五分鐘,才算約談結束。

約談結束我的簽呈還是繼續停留在他身上,我開始到處打聽,反正就是他很忙啦~請假啦~沒進辦公室啦~有的沒的一大堆理由,這時候離簽出辭呈已經超過兩週了。

最後直到簽出滿半個月的時候,我那位連我來多久都不知道的上上級主管才簽過。這中間又發生一件插曲,我們組被調換中心,所以之前那位上上級主管簽的不算數,要新的上上級主管簽名才算數,哇哩勒,又拖了我好幾天,然後才送到所長手上。

總之用了三週,電子流程才跑完。還沒結束喔~電子流程跑完才能開始跑紙本流程,然後一個一個的業務負責人蓋章,蓋完以後,咦~怎麼又是上上級主管以及所長,天阿~又得重新等他們兩位老人家有空閒,這時候已經是最後三天了。

等所長簽完,不好意思,我們還有更高層的單位,所以還得帶著這一大堆的簽章跟文件,親自跑一趟本部,才能完全跑完。算一算,最順利的狀況,就是我離職當天可以跑完所有的程序,也就是31天整。

我一天也沒有浪費的狀態下,用了31天才跑完所有流程,這樣的單位,真的是匪夷所思阿~

2011年9月5日 星期一

修改 Sigil 0.3.4 全紀錄(四)

自從換了 Mac OSX 10.7 Lion 以後,就沒辦法 compile 過 Sigil,苦惱了很久。

終於今天發現問題所在了,原來 CMakeLists.txt 內定 SDK 目錄為 MacOSX10.5.sdk ,但是在 Lion 裡面已經移除這個目錄了,所以只要把 CMakeLists.txt 的目錄改為 MacOSX10.6.sdk 或者 MacOSX10.7.sdk 就可以了

2011年8月26日 星期五

修改 Sigil 0.3.4 全紀錄(三)

首先, Sigil 作者已經找到接手維護的新任作者了,當然不是區區在下,是個 open source 界挺出名的人。

但是不管有沒有接手 Sigil ,該做的還是要做。翩翩工作很多也很雜,真正能寫程式的時間,一個月不到四天,所以修改的速度一整個的慢,到今天大概完成的進度如下:

  1. 可以編輯 EPUB 3.0 格式電子書
  2. 製作中文語系檔案
基本上,依照工作任務來看這件事情,我想差不多就到此為止了。雖然與我對程式的要求還有一段距離,不過畢竟這是別人開發的程式,我接手改,很難在一個月四天修改之中整個翻掉。

2011年7月4日 星期一

結合 Mercurial & Dropbox

最近在修改 Sigil-0.3.4 ,需要一個版本控管的軟體,既然作者使用 Mercurial ,我自然也是從善如流。但是問題來了,當我在其他電腦上面想要修改的時候,我不認為應該使用 Google Code 上面的那一份 clone ,翻了翻網頁,找到了方法,步驟如下:
  1. 解開 Sigil-0.3.4 ,假設放在 ~/data/Sigil-0.3.4
  2. 進入此目錄,執行:"hg init","hg addremove","hg commit -m "說明文字"
  3. 建立新的子目錄 ~/Dropbox/Sigil-0.3.4-HG
  4. 執行 "hg clone ~/data/Sigil-0.3.4 ~/Dropbox/Sigil-0.3.4-HG   --noupdate" ,這會在 Dropbox 建一個『看起來』是空的目錄(因為檔案放在隱藏目錄當中,會不斷看到同步訊息)
  5. vim ~/data/Sigil-0.3.4/.hg/hgrc,加上 [paths]\n default = /home//Dropbox/
  6. 以後就把 Dropbox 這份當作同步的核心版本,每次使用前就先 "hg pull"取得最新資料,改完以後就 "hg push"把最新資料放回去

2011年6月22日 星期三

修改 Sigil 0.3.4 全紀錄(二)

到昨天終於將儲存為 epub3 的部份完成了,總計動到八到九個 class,除了新增 ExportEPUB2、ExportEPUB3、NavigationWriter、NAVWriter這四個 class外,也動到原本好幾個class

現在,可以開啟一個 epub2 的檔案,然後什麼都不做,直接選擇『Save As』,之後選擇 epub3 格式,然後就可以產生新的檔案了

不過還不能公開,因為目前還無法讀取 epub3 的檔案,如果公開一定會被取笑,能存不能開,天大的笑話阿~

下一步當然就是開啟 epub3 的功能了,加油~

當然,這些日子,我也很認真的考慮接手 Sigil 這支 OSS,目前卓青跟張敏都認為應該要去報名接手,反正最後也不一定會是我中選。雖然如此,我還是有點猶豫~

2011年6月17日 星期五

修改 Sigil 0.3.4 全紀錄(一)

最近開始動手改 Sigil ,首先要讓 Sigil 可以產生 epub 3.0 的格式,有以下幾個地方:

  1. 所有 xhtml 檔頭
  2. 產生 nav.xhtml
  3. content.opf 內容
由於希望保留 epub 2.0 的格式,以提供 convert 的功能,所以大量的使用重構手法,將原本的物件改為抽象類別,然後實做去繼承並特殊化為兩種版本

Sigil 作者有個壞習慣,他大量的使用了全域變數,而且重複宣告多次。這對我來說是不能容許的,所以花了許多時間,將全域變數使用 static member function 來處理,處理之後透過 compile 抓出引用的地方,真是不少。我想這是我目前看到唯一不認同的地方

感想:看(改)別人的程式真的是比自己寫來的辛苦阿~

2011年4月18日 星期一

在 Ubuntu 10.04 LTS 上面安裝 Qt 4.7.2

為了 compile Sigil ,需要使用 Qt-4.7以上的版本,但是 Lucid 不支援。所以必須手動來編譯。首先下載 Qt-4.7.2,步驟如下:


wget http://get.qt.nokia.com/qt/source/qt-everywhere-opensource-src-4.7.2.tar.gz
tar -xvzpf qt-everywhere-opensource-src-4.7.2.tar.gz
cd qt-everywhere-opensource-src-4.7.2


接下來,開始進行編譯的動作


  1. 先裝 libX11-dev、libXext-dev、libXtst-dev、libqglviewer-dev、libmysql++-dev、g++ 開發工具包(sudo apt-get install ....)
  2. ./configure -qt-zlib -qt-libmng -qt-libtiff -qt-sql-mysql -qt-libpng -qt-libjpeg -qt-gif -opengl -prefix /opt/qt-4.7.2
  3. make
  4. sudo make install


另外,從 Sigil 網站的訊息,如果要 compile Sigil,建議使用以下參數

./configure -qt-zlib -qt-gif -qt-libpng -qt-libmng -qt-libtiff -qt-libjpeg

為了減少 compile Qt 的時間,可以在 configure 加上 -nomake 的參數,以下是建議的參數

-nomake examples -nomake demos -nomake docs -nomake translations


最後記得,/etc/environment 這個檔案的 PATH 要加上 Qt4.7.2的路徑,而且要放在前面,才不會被舊版的蓋掉。重新登入或者執行 .   /etc/environment 就可以囉

2011年3月21日 星期一

WebM & WebGL

最近接觸到一些訊息,都是跟Html5有關的,也都很有趣,先看看這兩個東西吧


WebM
這是一個BSD License的技術,使用VP8作視訊加解碼,Vorbis(Ogg)作為音訊加解碼,容器則使用Matroska。老實說,除了Ogg 以前有玩過一陣子,其他的我都沒聽過。不過這個技術標準是Google帶頭推的,所以跟Apple應該有得拼才是。又很重要的一點,它是不用繳交版稅的(加解碼的部份)


WebGL
Wiki寫到:『WebGL是一項在網頁瀏覽器呈現3D畫面的技術,有別於過往需加裝瀏覽器外掛程式,透過WebGL的技術,只需要編寫網頁代碼即可實現3D圖像的展示。WebGL的規格尚在發展中,由非營利Khronos Group管理。』
WebGL基於OpenGL ES 2.0,提供了3D影像的程式介面。它使用HTML5 Canvas並允許利用文件物件模型介面。可利用部分Javascript實作自動內部記憶體管理。』


由於這兩個技術都跟EPUB3.0有關,所以還得繼續追蹤了解一下

2010年11月18日 星期四

EPUB新舊版技術規格之比較

AreaEPUB3SpecificationEPUB 2.0.1 Specification
OverviewEPUB3 Overview(throughout)
Publication-level Specification & Package DocsEPUB Publications 3.0Open Packaging Format 2.0.1
Content-level SpecificationEPUB Content Documents 3.0Open Publication Structure 2.0.1
NCX DocumentsEPUB Publications 3.0N/A (referenced as DAISY specification)
Media OverlaysEPUB Media Overlays 3.0N/A
Container packagingOpen Container Format 3.0Open Container Format 2.0.1
Differences from previous versionEPUB3 Differences from EPUB 2.0.1(throughout)

這是新舊規格內容的差異表,我覺得這真是很聰明的改變。從這裡可以看出一件很重要的事情:EPUB2跟EPUB3不相容。所以不用浪費力氣去作 RS 的整合了,直接開發新版閱讀軟體才是王道。

EPUB3 TermEPUB 2.0.1 Term
Content DocumentOPS Content Document
User Agent (in EPUB Content Documents 3.0)Reading System (in OPS 2.0.1)
OCF Processor (in OCF 3.0)Reading System (in OCF 2.0.1)
EPUB Publication (in EPUB Publications 3.0)OPS Publication (in OPF 2.0.1)
XHTML Content DocumentsXHTML documents

這是新舊規格名詞的差異表,要注意的是"Reading System"從此不再存在了,取而代之的是"User Agent"以及"OCF Processor"

2010年11月15日 星期一

EPUB 3.0 Editor Draft 誕生了

千呼萬喚始出來的 EPUB 3.0 內部草稿誕生了,雖然我的貢獻實在少的可憐,但是看著這份草稿,心裡還是有某種程度的感動。EPUB 3.0 包含下面幾份內容:
  • EPUB Publications 3.0 (Publications3)
  • EPUB Content Documents 3.0 (ContentDocs3)
  • Open Content Format 3.0 (OCF3)
  • EPUB Media Overlays 3.0 (Overlays3)
其中 ContentDocs3 描述 XHTML5 , Overlays3描述多媒體互動部份,包括SMIL、Scripts等。

只能說超級佩服這些制訂標準的人,短短幾個月就可以生出這麼一份標準文件,真是了不起。接下來,應該是內部大討論吧。

2010年11月12日 星期五

EPUB3.0 Working Draft 編修時程

  • 2010/11/12 –(內部)發行第1版 Working Draft
  • 2010/12/15 –(內部)發行第2版 Working Draft
  • 2011/01/29 – 正式對外發佈第1版 Working Draft
本週五(11/12)PM11:59就可以看到內部發行的初版草案了,真是期待。

2010年8月10日 星期二

Sigil 中文化

又是將近一個月的時間沒寫網誌了,換了新工作以後每天都很忙,好不容易今天總算是有時間可以紀錄一下。

由於月底之前要產出一版介面改成中文的 Sigil 版本,之前寫信給作者,他表示目前沒有時間使用 i18n 來作介面的國際化。所以只好硬著頭皮改了。

花了很久才找到介面的部份,我對 Sigil 作者算是挺欣賞的,他沒有把資料跟程式混在一起,都盡量分開來放,在 Open Source Software 算是不容易了。

首先下載 Sigil 0.3.2 原始碼,幾個部份要修改:

  1. ~/Sigil-0.3.2/src/Sigil/Form_Files,這個目錄放了附檔名為 ui 的檔案,內容都是 xml 格式檔,搜尋 標籤就會發現,都是選單上面的選項,一個一個的改掉就是了。
  2. ~/Sigil-0.3.2/src/Sigil/Source_Files/data,這個目錄則放了 Metadata 的檔案,用 pipe-line 隔開的兩欄式 csv 檔案。

改完以後進行編譯,就跑出可以執行的中文介面版本了。

2010年7月20日 星期二

電子書標準的進度

好久好久都沒有寫網誌了,實在是忙、忙、忙。每天都很忙,每天都很累,經常都會忽然很累、很餓或者很呆。

IDPF EPUB2.1/3.0 電子書標準目前進入需求蒐集的階段,預計要蒐集到七月底。原本分為八個工作組,不過上個禮拜把 Advertising 合併到 RichMediaAndInteractivity 這裡了(頭銜好長喔),所以目前剩下七個工作組。

跟我們比較有關的,首要就是 EGLS(Enhanced Global Language Support),舉凡文字直排、斷行規則、連字規則統統在這組,其實這組應該屬於 Styling&Layout 的範疇,不過該組的組頭,日本的 Makoto 桑很堅持一定要獨立成為一組,而且一直拉台灣『贊聲』,所以主席就從善如流,把這部份獨立出來囉。

其他像是 Annotation 負責讀者、作者註記,也包含文字旁註的範疇;而 Metadata 負責擴充標籤;文字內容部份則交給 TextContent 負責;而跟目錄有關的則是交給 Navigation 搞定。

目前呢,每週四早上五點有個跨組的工作會議,透過 IRC 以及國際電話舉行會議,我們是一定都要參加的啦,早上四點起床,洗臉刷牙,然後叫計程車,聽一堆以我的程度懂不到一半的英文對話,然後撐到中午才能下班休息,這真是目前最辛苦的事情之一。

這就是為什麼我會這麼久沒有上來寫網誌的原因,下次見囉!

2010年6月11日 星期五

利用 SVG 讓 WebKit 可以進行文字直書

上個週五,不小心被我發現,原來 WebKit 已經實做利用 SVG 的標籤,來改變文字排列方向了。這讓我省了一些事情,也爭取了一些時間,繼續進行比較精細的原始碼追蹤。

<div style="word-break:break-all; width:480;overflow:auto">
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 400 300">
<text writing-mode='tb'>測試直書01234567測試直書。</text></svg></div>

用上面這段 html 就可以達成了,不過在 IE 是沒辦法的

2010年6月2日 星期三

鞕道:追蹤 WebKit 的原始碼,找出直書的部份

先說明一下,『鞕』音義同『硬』,請不要搞成鞭子的『鞭』囉。這次老大要我們兩個禮拜內,改寫 WebKit 使其擁有中文直書的功能,這就是台語講的『鞕道』。
追了一整天,先紀錄一下目前找到的東西。
  1. WebKit 把文字方向的功能,透過 class SVGRenderStyle 內的 struct IngeritedFlags 內的 unsign _writingMode 來控制, EWritingMode 定義請見這篇
  2. SVGRenderStyle 透過 setBitDefaults() 來賦予包含 svg_inherited_flags._writingMode 初值

2010年6月1日 星期二

關於 Webkit 在中文直書上的技術問題

安裝 WebKit 請參考這裡

目前 Webkit 可透過呼叫 -webkit-transform: rotate(90deg) 的方式,把文字及排版同時旋轉九十度。而中文直書需要的,其實只要把排版轉九十度,文字不旋轉。

在 /Webkit/WebCore/rendering/SVGTextLayoutUtilities.cpp
有段 float glyphOrientationToAngle(const SVGRenderStyle*, bool isVerticalText, const UChar&) { }
回傳值為角度,共有 0, 90, 180, 270 四種
假如文字方向垂直,則檢查 SVGRenderStyle::glyphOrientationVertical(),
否則為 SVGRenderStyle::glyphOrientationHorizontal()
回傳的 state 有 GO_AUTO, GO_90DEG, GO_180DEG, GO270DEG, GO_0DEG 五種。


...(以下刪去)

(我覺得之前好像搞錯方向了)
在 /Webkit/WebCore/ 目錄裡面搜尋 WM_TBRL ,總共出現在五個地方:
  1. /Webkit/WebCore/rendering/style/SVGRenderStyleDefs.h -- 定義 EWritingMode { WM_LRTB, WM_LR, WM_RLTB, WM_RL, WM_TBRL, WM_TB } ... 直書就是這兩個
  2. /Webkit/WebCore/svg/SVGFont.cpp -- 透過 SVGRenderStyle->writingMode() 是否為 WM_TBRL 或者 WM_TB 來判斷直書與否
  3. /Webkit/WebCore/svg/SVGTextContentElement.cpp -- 透過檢查 SVGRenderStyle->writingMode() 決定是否為直書,整個類別使用多次直書與否進行不同邏輯演算
  4. /Webkit/WebCore/css/CSSPrimitiveValueMapping.h -- 進行各種 CSSValue 與程式定義的對應
  5. /WebKit/WebCore/rendering/SVGTextLayoutUtilities.cpp -- 把 SVGRenderStyle->writingMode() 是否為直書,包裝成一個 isVerticalWritingMode() 的函式。
所以接下來應該從這幾個去著手。看起來, Webkit 對 CSS 3.0 的 < writing-mode > 已經有實作了,只是還沒有開放而已。

~先寫到這裡