07/26 —– 10/16

起個不容易被搜尋到的標題。總結一下轉組後的這三個月工作。出來混，多總結的好，人總會有迷茫的時候，按時按量總結對成長有好處。

07/26 ------ 08/26 

我稱這段時間為置之死地而後生。

處理問題: 實現一個類似panmap功能的Panose。

處理方法; 取最近距離的並且存在於系統的字型。

PANOSE之旅

一開始是根據panose1.0特徵來取距離，不過我的做法很單純很天真,跟cjy討論過，這中間肯定需要一條公式，而這條公式的因子是我們所感興趣的資料，經過篩選後，得出來的結果取差額最少的。由於這項工作屬於開發型的，時間緊迫，要的是結果，這個研究作罷。直接用了fontconfig的庫來做。不過fontconfig更多的是滿足於看起來相似，對於字型處理系統來說，fontconfig遠不能滿足。雖然fontconfig中weight的優先順序是比較靠前的。看了fontconfig中對匹配的實現，發現它也是做panose數優先順序的差額計算，不過中間有部分篩選演算法的代碼看得很懵懂。

瀏覽器&word----字型，排版

在這中間找資料的過程，對字型，編碼這塊，以及文字編輯軟體，瀏覽器中的字型處理都略略瞭解，可見，瀏覽器和文字編輯器其排版和I/O都有相似的地方。特別看到css中對字型處理這塊，同樣是根據計算panose距離，不同的是它搜尋得字型是在網頁伺服器上的。

貫穿三個月的困惑開始:

有些問題一直在處理，但是怎麼也無法徹底去弄通，掌握。例如fontconfig是如何?的？文檔只有函數功能描述，而無更深入的剖析，直接看代碼卻只能在外部徘徊。這個問題於自己來說並沒有徹底完了。和項目內的Panose問題一樣，由於底層的缺陷導致至今該功能對排版還是有些影響。回頭要找找隔壁項目組的人討論討論。同樣的困惑還有，項目中原有的字型處理模組也沒有徹底理解。我覺得如果其中能保留該模組所解決的問題描述對後來維護的人是最好的文檔。按圖索驥。也是從這個月開始在windows程式，linux 這幾塊跑來跑去。底層很多功能都是缺失的，例如對多語言處理這塊，多語言模組，只實現了1的介面，而無實現2的介面。這個月大概就這樣，從flex到(windows,linux)，這個轉折，挺好。後期處理文字繪製要好好把這塊總結一下。

08/26 ------- 09/26

轉正，無盡地調試。

處理的BUG:跟I/O有關的都包了。

處理方法:無盡地調試。

調試 & I/O之旅

前一個星期還是處理字型收尾工作，也就是補全了底層的多語言的實現。

自動編號

看到自動編號，我淚奔了。(沒有原因，就想淚奔，這塊是女神設計的。話說女神還設計了表格，女神像我一樣大的時候就設計了自動編號。)

自動編號這個BUG，跟編譯器，系統有關。位元組對齊，用wchar強制類型轉換字串時，前兩個位元組有有效值，第三個位元組補0，而後再取了後面的位元組填上來湊一個WCHAR，導致後面的編碼重排，結果亂碼。

rtf個格式,文本分析模式

打從進了KSO以來，接觸一些儲存格式，EMF,WMF,OOXML,RTF還有最近的pixmap,差複合文檔格式和jpg，音頻格式，視頻格式。後面幾塊比較感興趣。有個BUG和這個中的文本分析模式有關，因為一個參數的錯誤，導致分析流流向其實處理節點。還有另一個BUG，屬於編碼者粗心，把一個double型的值賦給了INT_16的值，溢出。不過vs編譯器甚是強大。把這個錯誤給改過來，所以windows上是非常安全的:)

250位元組

linux允許的檔案名稱長度為255個位元組。超過則無效，所以就導致複製網頁上的圖片到本地是無法粘貼的。這個時候，我開始了從windows程式調到底層內建函式，再到linux去，這在後來，都是常事。

utf8, utf16, CompoundText編碼 &&&&&&Chrome

終於知道自己處於一個維護軟體的行列中，調別人寫的程式，逐漸習慣了，調著調著，就過了大概2周或者3周。到了最關鍵一周。修改剪貼簿的BUG，也就是I/O中的複製粘貼。相當刺激。

說點題外話，文本是什麼，文本是編碼+字型。繼續。

utf系列都是描述unicode編碼，有點像加密，給一塊位元組頭，然後把內容包進去。而CompoundText編碼是X-Window下的通訊編碼，據說後來換成utf8來通訊，而CompoundText將逐漸被淘汰。這些對改BUG沒啥協助。CompoudText確切來說不算編碼，而是編碼大雜燴，CompoudText對內容的封裝位元組添加了控制符的標誌。至於decode或者encode這塊沒有多大瞭解。關鍵是chrome傳到自己剪貼簿資料是有CompoundText編碼，而底層對這塊編碼並沒有很好的decode，導致後來在程式記憶體中出現6個位元組描述一個中文字元。chrome的剪貼簿不足還遠不止這些。

chrome(linux) & Xclipboard

繼續描述chrome的劣行，chrome對網頁中的相對路徑並沒有很好地轉換成絕對路徑，導致粘貼到程式中時的超連結無效。所以在OO writer中式無法連結到相對路徑的地址。

Xclipboard & XSelection & OLE剪貼簿

通過chrome的瞭解，逐步瞭解到X-WINDOWS下的剪貼簿原理，以及windows的OLE剪貼簿的延遲提交。Xclipboard的原理有點類似於windows下的剪貼簿延遲提交。資料是儲存在複製方，等到有訊號過來，再傳輸資料，而程式關閉，剪貼簿資料也就隨著丟失。

BITMAP & PIXMAP

可以肯定。。x-windows處理的是pixmap格式，不過底層在轉換tymed資料時，有對global,istream,emf,就是沒有處理Bitmap的。所以這塊資料的複製粘貼是肯定無效的。

文字繪製

中秋到國慶中間這個星期就處理這個了。就是文本繪製這個函數的實現。裡麵包括了粗體繪製，豎排，臥排，控制項繪製，這塊屬於後期處理，當時並沒有深入看到整塊代碼的實現原理，其中有加鎖部分。

貫穿三個月的困惑發展:

還沒寫的時候，是挺困惑的，寫完後倍感舒暢，我缺的是對各個模組地實踐，自己寫個程式深入瞭解一番，才是把握到手中，而讓我困惑的原因是在還沒來得及消化時，又來了其他的，思維上不連貫。對於剪貼簿，文本分析模式，字型編碼每一塊都深入瞭解都會有所作為的。但事實上，我並沒有這個條件，需求，精力去達到深入。只能記錄下來，待又遇到問題後，再貫穿起來分析。

10/08 ---- 10/16

就一個星期，這段時間三個字很好形容-------易容術

任務: 對windows路徑改頭換臉，換成linux的路徑

解決方案: 調試。

前期改路徑並無太多難度，在windows程式中，把處理反斜線的函數改過來就是，但是到了後期，到了處理系統路徑，特別是底層預定義好了的路徑，就開始考慮各方面的情況，這需要對程式啟動後有哪些啟動了系統路徑，還有底層處理路徑各個模組關聯都理解。今天糾結在這裡，有點心燥，想急於解決，不過這種心態不好，於是還是做個總結，下周再處理。

ShellExecute & 字串處理 & 遠見

說說windows程式本身對windows路徑的處理，寫這個標準路徑處理函數這個人很有遠見，他是文本模組分析的作者，他在前半段已經把路徑轉成了linux了，而又用了判斷標示來分流處理是否要處理成windows，這對後期維護軟體的人來說是個福音，是個好設計。

字串處理是塊不錯的領域，I/O就是一個字串處理模組，路徑裡面也是，甚至到搜尋那處也是。挺好的一個領域。

最後是ShellExecute, 在windows程式中，通過程式啟動另一個程式調這個函數就可以了。但是在linux下，就要fork一個子進程出來，再調execv() 調個檔案瀏覽器出來，底層自己搞了一套同名的處理，不過，可能傳入參數順序不對，導致最後路徑錯誤。這塊究竟底層怎麼個錯法並沒有深究，不和諧的東西研究了對身體不好，索性直接包了execv替換了底層那個。最後順利跑起來了。挺好。

貫穿三個月的困惑結尾

困惑並沒有解決，因為我並沒有變強大起來，只是在表面蜻蜓點水般地略過，始終沒有對一塊領域有長時間地認知瞭解。最後我還是什麼都不是。而至於編碼，設計經驗那些更沒有機會去大面積，長時間實踐，就算平時抽空寫寫程式，那些也都只是小程式，不成氣候。項目越發展越是大規模，沒有長時間潛伏在大項目中，去實踐，編碼，理解，不能很好地成長起來。不過我也很感激有這次機會，維護一個系統過程，見過優秀的代碼，見過體系的構成，見過問題的解決方案。知道缺乏什麼，不過我更缺的是時間，和前輩的指導。

當務之急:
有了大量的問題域的積累，缺乏實踐，抓取任何機會去訓練自己的設計，思路。