這個星期中午吃飯時都使用「靜讀天下」看書，雖然都是同一種字型，但很明顯的每家顯示的方式都不一樣。
有時候這會讓我很出戲，因為有些人名「靜讀天下」翻譯起來就和 Kobo Clara 2E 不同。
倒也不是說「靜讀天下」就最完美，只能說目前看起來是相對完美的。
下面這個聖人有云，明顯就沒翻譯成功。
這篇文章應該是我看過解釋簡轉繁字型原理講得最好的人。
這是不是意味著，字型顯示原來不是一件簡單的事？
照我個人猜想，應該是有類似字型引擎在處理顯示方面的事？
2026年6月27日 星期六
2026年6月22日 星期一
ReadEra Premium 入手
我就是喜歡研究軟體間的差異。
想了一下，剛剛還是花錢購買了，照官方網站所說，即便使用免費版本，也不會有廣告。
衝著這點，不支持一下怎麼說得過去！
雖然跟「靜讀天下」價錢差不多，稍微用了一下，就找到兩個輸「靜讀天下」的地方。
- 開啟同一本書，明顯比「靜讀天下」慢。
- 閱讀介面下方，沒有「靜讀天下」好看。
但就像我說的，沒有廣告就值得支持了。
話雖如此，我應該還是會用「靜讀天下」閱讀 Kobo 購買的《劍來》。
ReadEra Premium 就讓他專門閱讀直式中文書好了。
個人覺得，閱讀軟體能夠直轉橫、橫轉直都不是重點。
一本書如果製作的時候是直式就應該顯示直式，反之亦然。
我想這也是一個閱讀軟體最基本的功能。
「靜讀天下」這點就讓人失望。
簡單比較一下
2026年6月19日 星期五
懶惰起來要人命
今天終於受不了了，一口氣把手上有帳號的書城 App 都裝了一輪，希望可以把 Kobo 購買的那本簡體中文版《劍來》利用更換字型的方式達到簡轉繁的良好閱讀體驗。
嗯，果然沒有一家 App 可以支援自訂字型！本來以為 Readmoo App 應該有這個功能，只可惜還是沒有。
還好之前就有聽過大家都很推薦「靜讀天下」，查了一下確定可以自訂字型，目前售價為台幣 400 元。
我想應該還有其他付費 App 也可以自訂字型，不過本人實在沒有多餘時間，就不節外生枝了。
現在手機終於可以跟 Kobo Clara 2E 有一樣的閱讀體驗了。
目前使用的簡轉繁字型如下
原俠正楷-TW
Version 1.12; Jul 31, 2023
OpenType 配置，TrueType 外框
原本 Kobo App 顯示
靜讀天下 App 顯示
請 Claude Web 搜尋可以安裝字型的 Android App
2026/06/20 更新
靜讀天下無法開啟直式 EPUB 書籍，應該是它不支援。
另外一套 ReadEra 就可以正常顯示直式 EPUB 書籍，目前售價為 370 元。
《劍來》浩然天下地圖
在 Kobl Clara 2E 看到 3 萬多頁的時候，終於有段文字好好描述了浩然天下的世界觀。
不多說，趕快請 Gemini 幫忙畫圖。
只可惜這段文字並未描述到劍氣長城。
改天有空再補上。
2026/06/19 更新
使用搜尋功能終於找到了，居然要到第 42 章才有描述到倒懸山的地理位置，劍氣長城則是位於倒懸山以南，兩大天下的交界處。
2026年6月17日 星期三
大道至簡，唯有 Python
雖然可能也許 Maybe，我最喜歡的程式語言還是 Go？
但不得不說，Python 能找到的程式碼最多？
為了 power domain 的關係，我得宣告不同名字的 module code。
上次的 cell 只會傻傻的複製貼上，真枉費我寫了 20 年的程式。
如今又需要一堆這樣的 cell，這次總算想到要用程式來生成。
但昨天為了趕在 license 過期的前夕，快速完成某項功能，就用最笨的 print 來做，反正配合 Vim + 現有的 Verilog 也花不了幾秒。
昨晚一夜未眠，趁現在精神好，趕緊來找一下正解。
原來這樣即可。
紅泥小火爐，能飲一杯無？
昨晚又是幾乎一夜未眠。
四點初起床時，精神實在萎靡不振，還好在看了一個多小時的《劍來》後，心靈大大滿足，也不枉主角陳平安說了那麼多大道理。
雖然我不認同陳平安在書簡湖的行為，怎麼可以讓妹子在劍氣長城空等？別說做了，想想都是罪過XD
但比起齊聖人的身消道殞，陳平安的自我贖罪確實還是理直氣壯多了，畢竟小泥鰍是他當年送出去的，這個鍋他不背誰背呢？
三教原本道為首，我最討厭的就是百無一用的書生。
話雖如此，有風骨的讀書人我還是很敬佩的。
只可惜在這豺狼當道的世界，官不官，民不民，看了就是讓人厭煩！
何時才能找到我的一方清淨天地呢？
唉，大道無期呀。
2026年6月14日 星期日
PDF 翻譯 Part 06
上一次請 Claude 翻譯技術文件時，因為 PDF Viewer bug，導致在 2000 多頁時因為記憶體不足而當機。
這星期因為不用推 Code，本來想繼續完成下一個工作階段要做的事，但因為昨天已經解決一個星期五原本想解的工作問題，再加上現在內心很反感假日做事，於是便繼續嘗試把那個想翻譯的技術文件翻完。
上次 AI 提到需要使用 Claude Cache 機制避免 API 費用浪費，今天查了一下，似乎 AI Coding 時本來就有考慮進去？
還有之前以為 AI 自動幫我加的 SQLite DB 有問題，乍看似乎沒有翻譯成功還是將翻譯內容寫入 Local DB？但下載任意一個 DB Viewer 看起來還是有的，只是有些是設定不用翻譯的，AI 還是將他存入 Local DB？
調整了一下 RPM 後，這次就大膽的啟用 DB cache 機制，也還好因為這個決定，避免我再一次浪費掉 20 多塊美金。
這次在做到 3069 頁時又當機了，看起來還是因為記憶體爆掉，這表示上次除了 PDF Viewer 吃掉記憶體外，這個翻譯軟體本身也在吃記憶體，只是當初沒有想到還有這個原因。
沒關係，這次有 DB cache 了，就讓它做到某一章節段落，大概是 3006 頁的地方。
就在我寫這篇文章時，回過頭去檢查終端機，沒想到又當掉了，這表示使用 DB cache 或是寫入 PDF 本身也在吃記憶體。
當初應該擴充筆電記憶體到 32G，真是千金難買早知道。
還是要趁此機會換電腦？印象中我這台是可以擴充記憶體的？
待我後續好好想想。
2026/06/15 更新
殘念，當初覺得 16G 夠用，這台型號是使用 LPDDR5，根據官方使用手冊，無法擴充。
2026/06/16 更新
還是記錄一下目前還剩多少錢好了，不然之後工作一忙，應該也忘了。
唉，做不完的事呀！如果不要浪費我寶貴的時間在那推 Code，我可能還願意犧牲假日時間，現在我只會覺得一點都不值得。
人生只有兩件事：不干我事，關我屁事。
2026年6月11日 星期四
勿在浮沙築高塔
之前就有發現客戶產生 file_list 的小工具會有些奇奇怪怪的問題。
先前已經幫忙解了一個 issue，也讓後面的流程比較順利，不會讓客戶抱怨流程走不下去！
但現在這個新問題確實很莫名奇妙？
也讓我不禁懷疑客戶到底是否有使用此工具？
一個這麼重要的基礎工具怎麼會有那樣多怪問題？
假設我有一個 A design 好了，正常來說讀取設定檔後，產生出來的 file_list 裡面檔案應該要有 400 多個，但 tool 常常只產生約 30 個檔案的內容？
個人猜測是因為工作站 IO 之類的問題，導致它要產生相關內容時，因為讀不到衍生出來的設計檔案，故導致它提前結束？
坦白說，這個問題我還真沒時間幫忙看，尤其工具又是使用我最不喜歡的 perl 語法，一樣是變數要加 $ 的程式語言，PHP 就沒那樣惹人厭！
總之，不甘我事，我也沒空。
但不能因為這樣影響我的流程，不然又會被客戶抱怨死在我的流程裡？
想了一下，在 bash script 加上一段 assert，事情就搞定了。
反正當檔案個數過少時，就會停止執行，也算達到我的目的了。
也趁機學會如何比較數字，原來重點是使用 [[ ]]。
唉，人生不同工作階段就使用不同程式語言做事，因為這樣我的底子已經很不扎實了，故也拿不出像樣的必殺技，再加上這兩年都沒在寫程式，我的氣運都快被磨損光了！
有時候我都不免懷疑，別說下五境修為了，我目前的程式能力可能比一個普通大二生還不如呀？
2026年6月5日 星期五
2026年6月2日 星期二
2026年5月31日 星期日
PDF 翻譯 Part 05
之前在測試使用 Claude API 翻譯的結果時，順手請 AI 寫了一個 Windows PDF Viewer，來幫助我快速閱讀翻譯過的技術文件。
果然自己寫的東西最符合自己的需求，於是我在 05/24 便想要依樣畫葫蘆，繼續來個 Android PDF Viewer，AI 一下就把程式寫好，無奈當天第三方函式庫網站似乎有問題，Claude Code 使用了好多種方法及程式語言想要下載都不成功，故最後沒辦法得到一個 APK 來使用。
其實我後來想想，搞不好是 AI 寫法有問題導致被 Bang 也說不一定？
今天早上，為了監控 git push 的執行，不得不坐在書桌前，於是便繼續這個小專案，這次下載就很順利。
後來又陸續加了很多功能，目前所有功能如下
- 顯示或隱藏圖層，可以閱讀原文或是翻譯的中文。
- 可以連續捲動模式或是整頁模式。
- 整頁模式可以點擊或是滑動翻頁。
- 頂部工具列可以隱藏或固定。
- 目錄功能。
- 跳頁功能。
- 回到上一頁功能。
- 允許或關掉翻頁效果。
- 自動裁邊功能。
有些功能是一次就搞定，有些則是測試發現問題後請 AI 修改。
過程中大概遇到 2 ~ 3 次的自動壓縮，有一次還失去了編譯環境相關的內容，故 AI 又浪費 token 重新建立起環境的認知。
因為不是自己寫的 APK，故我都是請 AI 直接編譯，再加上我習慣用 Windows Git Bash 的環境啟動 Claude，故每次 AI 都要花時間設定環境。
這次發現自動壓縮丟失原本內容的問題，馬上請他把環境寫成文字檔，之後別的專案就不用從頭建立環境了。
看了一下，雖然不知道昨天 05/30 的使用量哪來的，但約 16 塊的花費還是很值得。
還順便問了一下裁邊演算法，原來又是沒人好好填上 PDF meta 資料的鍋。
總之，我現在可以在我的 Pubook Pro 上閱讀技術文件了。
颶風翻了身
好景不常，繼上次「閒適臥雲中」般的順利推 Code，這個星期說是跋山涉水，披荊斬棘也不為過。
首先，星期三的會議，以我破英文對客戶說話的理解，好像可以先跑測試，之後如果沒有更新，其實不用再跑？
但此番理論跟我從 git hook 看到的禁制似乎有所違背？
果然，不管你有沒有跑完測試，git push 就是要你再跑一次，但我實在沒空把整個 hook 看過一遍，也許答案藏在測試的 Makefile 中也說不一定？
總之，星期三晚上的推 Code 果然還是因為有人比我早更新而導致我推 Code 失敗！還好，當天還算幸運，第二次就順利推 Code 成功，故我當天就又推了一次，本想這樣一來，我六日就可以先不推 Code，於是當天又搞到 2 點才睡，
無奈，本週還是要推 Code，但想到可以讓同事以及專案流程順利一點，還是默默地從星期五晚上開始推 Code，也許可以像星期三那樣走狗屎運也說不準？
本週測試項目來到約 13X 個，就在順利跑完 120 個左右後，一來是剩餘測試卡住好久，二來是我在另外一個 reference 資料夾檢查的結果已經有人又推 Code 成功，於是就不等了，凌晨 12 點半就上床睡了。
不知是不是心懸測試結果的緣故，半夜四點醒來後就睡不著了，忍到七點多吃完早餐才進去客戶工作站檢查結果，沒想到測試居然還沒跑完，因為已經知道不可能成功，還是按下 Ctrl + C 停止所有測試，沒想到這是個不對的方式，直到後來才發現後果？（推 Code 有問題要停掉，一定要用 bkill，不能 Ctrl + C）
因為星期六通常還是有人推 Code，故我的 SOP 已經改成星期六晚上 8 點後再視情況決定推 Code 事宜！
星期六晚上 8 點過後，距離最後一個 commit 已經有一段時間了，應該暫時沒人推 Code 了，故還是勇敢的 git push。
沒想到在剩下 1X 個項目的時候，測試又被卡住了，檢查一下 git commit 情況，已經有人截足先登了，於是決定取消，但這次用 bkill 終止所有測試。
星期日一早又看到一堆 git commit 的更新，說真的我也無從判斷該不該做，想了一下，還是默默地跑了下去。
老樣子，測試又卡住了，嚴格來說，是跑工作的 Server 都掛了，這似乎已經是常態了？
還好剛剛所有的測試都跑完了，只是要上傳的時候，一直跟我說 Git is locked？
等了幾次重試後，突然靈機一動，感覺跟星期五強制 Ctrl + C 有關？
於是火速回頭檢查禁制，果然此訊息是腳本本身的訊息而不是 git command 的訊息！
總之，此腳本推 Code 時，會產生一個 /tmp/git-push-2 的檔案，腳本以此檔案來避免有人同時推 Code。
檢查的結果，果然所有人是我，檔案建立時間就是星期五晚上的時間。
果斷的砍掉檔案之後，跑一跑突然又出現一個錯誤，然後整個腳本就結束了，本來以為又要重推了，髒話都要罵出來了？
還好後來想了一下，這個錯誤應該是 git 想要幫你重整 db 的動作，不影響推 Code 結果。
最後終於脫離了從星期五晚上執行到剛剛的鬧劇，真是不堪回首呀？
唉，少點心眼都不行，還好我曾經是一個貨真價實的軟體工程師，不然真的會被搞死，六日原本的計畫又泡湯了，幸好早上監控推 Code 時，順手把 Android PDF Viewer 完成，不然真的會幹到不行。
2026年5月24日 星期日
閒適臥雲中
這個星期又坐在電腦桌前面推 Code 了。
昨天難得順風順水，不用解 patch issue，不用管 make build issue，重要的是每個測試都能夠順利通過。
於是昨天便違反 SOP，大膽的給它用力推 Code，直到今天凌晨 3 點才睡。
這才對嗎，既然用了不合理規則擋我路，至少要像這樣順順利利，我才會心甘情願XD
昨天下午推 Code 前，去了一趟 IKEA，買了幾件小物，整理一下書桌，套句《劍來》的術語，這樣的環境才有助於聚集天地靈氣，養育我這一小方天地。
麻將大俠曾說：人品好，牌品自然好。
我要求的不多，每次推 Code 就像今天這樣就好了！
待會終於有時間玩一下暗黑 2 了。
2026年5月19日 星期二
PDF 翻譯 Part 04
今天無意間將 PDF Viewer 縮小，過了一陣子可能是 10 分鐘以上？此時可以從工作管理員看到，原本占了 6G 多的記憶體會剩下不到 1G。如果再把 app 叫回前景，隨意操作一下，記憶體仍然未回到 6G 多！
我想這應該是程式哪邊有 Bug？
回家後馬上問一下 AI，他也很快的找到問題所在。
有時候我還真搞不懂大語言模型為什麼這麼神奇？
二十年累積的東東好像跟屁沒兩樣？
還好我不會有什麼 AI 焦慮，我只會擔心 Vim 功力退步很多XD
如果可以不用工作，我一定要好好把 Vim 學好！
2026年5月18日 星期一
PDF 翻譯 Part 03
果然是因為 PDF 翻譯工具在翻譯時，同時又在開發 PDF Viewer，才導致記憶體爆掉。
目前使用 Python + Qt 開發的 PDF Viewer，開啟一個快 900 頁的 PDF，全部就佔了快 7G 記憶體，難怪昨天程式會當機。
今天使用 PDF Viewer 閱讀有翻譯圖層的 PDF，果然好用，隨時可以按下快速鍵拿掉圖層閱讀原文內容。
晚上又加了一些功能，除了開啟快 900 頁的 PDF 要 3 秒外，其他沒有甚麼好挑剔的。
應該不會開發新功能了，Unix 哲學，一次只做一件事，把事做好。
兩天統計，全部花了約 2800 萬個 token，換算約美金 17 塊。
花錢的翻譯果然還是比免費的 Google 翻譯好，美金 7 塊多很值得。
可惜的是昨天翻了 2000 頁的內容，因為當機一頁都沒留下，白白花了約 23 塊美金，有空再來改進他。
不得不說，原來這就是用嘴巴 Coding 的感覺。
PDF 翻譯 Part 02
前天使用自製工具翻譯了一份文件，大概快 900 頁，下面是 API 使用情況。
=== Summary ===
Paragraphs translated : 4186
Input tokens : 211,790
Output tokens : 302,468
Estimated cost : $7.0905 USD
還不賴，比一本書便宜。
另外，PDF 翻譯工具需改進，一個是動態調整 RPM 限制，另一個則是要考慮如何保存中間結果。
因為我遇到一個 5000 頁的文件，做到約 2250 頁時，系統當機，應該是我同時做很多事，導致記憶體用到快 16 G。
AI 給的 RPM 修改建議方向
先做：查你目前的狀態（5 分鐘）
查 Tier 在哪裡
方法 1：Console 介面
- 登入 console.anthropic.com
- 左側選單 → Settings → Limits（或 Plans & Billing）
- 會看到「Tier 1 / 2 / 3 / 4」字樣，以及對應的 RPM、ITPM、OTPM 數字
方法 2：用 curl 直接問 API（更準）
打開 cmd 或 PowerShell，把 YOUR_KEY 換成你的 API key：
curl https://api.anthropic.com/v1/organizations/rate_limits ^
-H "anthropic-version: 2023-06-01" ^
-H "x-api-key: YOUR_KEY"
回傳的 JSON 裡會直接告訴你每個模型的 RPM/ITPM/OTPM，對照下面的表就知道 Tier：
| Tier | Sonnet RPM | Sonnet ITPM |
|---|---|---|
| 1 | 50 | 30,000 |
| 2 | 1,000 | 80,000 |
| 3 | 2,000 | 800,000 |
| 4 | 4,000 | 2,000,000 |
查 prompt caching 有沒有開
直接搜你的翻譯工具程式碼，看 system 那段：
# 在你的翻譯工具資料夾
findstr /S "cache_control" *.py
- 有輸出 → 有開 caching
- 沒輸出 → 沒開 caching
或更簡單：跑一次翻譯，在你的程式裡 print 出 response.usage，看有沒有這兩個欄位：
cache_creation_input_tokens（第一次跑會有）cache_read_input_tokens（第二次以後會有）
兩個都是 0 → 沒開 caching。
然後：直接用 Batch API 改造你的工具
既然你選「注重速度，可以掛著等」，Batch API 是完美解答。我直接幫你準備好可以丟給 Claude Code 的修改說明。
Batch API 對你的好處（再次確認）
- ✅ 不受 RPM 限制 — 5,000 段一次提交也沒事
- ✅ 價格 5 折（input 和 output 都打 5 折）
- ✅ 24 小時保證，實測通常 1–2 小時
- ✅ 與 prompt caching 可疊加（更便宜）
- ⚠️ 結果是「全部一起回」，不能邊跑邊看
- ⚠️ 中途無法取消個別請求
改完之後的預期效果
以你 800 頁論文為例：
| 方案 | 時間 | 你需要在電腦旁 |
|---|---|---|
| 現況 | ~4 小時 | 全程 |
| + Prompt caching | ~3 小時 | 全程 |
| + Tier 升級 (-> 2) | ~30 分鐘 | 全程 |
| 改 Batch API | 1–2 小時 | 0 分鐘（掛著等） |
| Batch + Tier 升級 | 1–2 小時 | 0 分鐘 |
Batch API 對你的價值不只是「快」，而是「解放你的時間」 — 提交完就可以關電腦睡覺，醒來結果就在那。
成本方面：800 頁論文（假設 50 萬 input tokens、20 萬 output tokens）大致估算：
| 方案 | 預估成本（粗估） |
|---|---|
| 現況 | ~$4.50 |
| + Caching | ~$3.00 |
| + Batch API | ~$2.25 |
| Caching + Batch | ~$1.50 |
數字僅供參考，實際看你的文件密度。改完最多省 2/3 成本，外加 4 小時變 1-2 小時、還不用顧。
給你的執行順序建議
- 先查 Tier（用上面 curl 或 console）
- 新開 Claude Code session，把你的翻譯工具資料夾打開，把上面那段 prompt 貼進去
- 試跑一份小檔案（10-20 頁）驗證 batch 流程沒問題
- 正式跑 800 頁那份，掛著去睡覺
- 醒來檢查結果，用我們之前規劃的那個 PDF Compare Viewer 並排看 Google Translate 版 vs Claude API 版
整個工作流就完整了。
原來之前都在玩玩具
難得本週不用推 Code，於是便想繼續完成 PDF 翻譯相關的想法。
途中好奇，想要自己寫個 PDF Viewer 好方便我比較不同 Translator API 的差異，跟 Web Claude 討論的結果，他也覺得自己寫會比現成的方便，於是我就請 Web Claude 規劃，分階段實作及驗收。
目前來到 M3 階段，終於第一次碰到 Limit 限制，提示我必須等到 11:50 AM 過後才能繼續。
抓個圖留作紀念。
Web Claude 使用多少 token 未知，但本機用量如下。
Claude 各方案比較
限制詳細說明
API 使用限制
Pro 5 小時上限估計
換算成實際工作比較
AI 給的建議
給你的實戰建議
根據這些數字，Pro 規劃工作流的原則：
1. 開新對話的時機
- 對話超過 20-30 輪就考慮開新對話
- 任務切換時開新對話（不要在同一對話跨多個專案）
- 把當下對話的「結論」貼到新對話起頭，可以用很少 tokens 換到清爽 context
2. 模型選擇策略
- 日常對話、寫文件：用 Sonnet（你目前模型 Opus 4.7 約 5x 貴）
- 複雜推理、艱難 debug：才用 Opus
- 如果只是「優化措辭」之類的小任務，可以切到 Haiku
3. 上傳檔案的成本意識
- 一份 800 頁 PDF（你的論文）一上傳可能就 200-400K tokens，超過 Pro 5 小時池子十倍
- 大檔案優先用 API 處理（你的翻譯工具就是對的方向）
- 想討論大檔內容，先用工具抽出關鍵段落，貼進 Claude 對話
4. 你目前的工作流估算
你過去這 6-7 輪我們的對話，加上 spec / prompts 文件產出，大概用掉 30-50K tokens。 意思是：這種「規劃 + 寫規格」的對話，一次 5 小時的 Pro 配額大概可以撐 2-3 個專案。
但如果你還要同時用 Claude Code 開發那個 PDF Viewer，Claude Code 燒很快（一次 1-2 小時的開發就可能吃完 5 小時池子）。
5. 撞牆時的判斷
| 情境 | 建議 |
|---|---|
| 每週撞 5 小時牆 1-2 次 | 改用「開新對話」「換 Sonnet」習慣 |
| 每週撞 3+ 次 | 認真考慮 Max 5x（$100），ROI 大幅提升 |
| Claude Code 一天用 4+ 小時 | Max 5x 起跳，重度的話 Max 20x |
給你的核心收穫
Pro 5 小時 ≈ 44K tokens ≈ 30-50 則中等對話，這是你規劃工作的心理基準。
實務上你可以這樣抓：
- 「跟 Claude 規劃個東西、寫個規格」→ 30-50K tokens，剛好用滿 5 小時池子的一半到全部
- 「用 Claude Code 做半天開發」→ 容易撞牆
- 「上傳大檔深度分析」→ 一次就用很多，挑著用
如果你想更精確地監控，可以在 claude.ai 設定裡看 Usage 頁面（如果有開放給 Pro），或在 Claude Code 裡跑 /status 看當下用量。
2026年5月16日 星期六
PDF 翻譯 Part 01
很多技術文件都是英文，無奈個人英文差，常常自以為的解釋其實跟原文差了十萬八千里XD
上星期突然想到是否可以請 Claude Code 寫個程式來幫我翻譯？
之所以要這麼搞剛，是因為 Web AI 都聽不懂人話居多，請他逐字逐字翻譯，結果都無法照做？當然也有可能是我不會用導致？不過，我並沒有用其他第三方的 AI 網站，而是直接使用我有訂閱的 Gemini 或是 Claude。
一開始 Claude 就知道要用 PyMuPDF 來處理 PDF，不過，對於圖表或是程式碼的判斷差強人意。
隔天有空搜尋了一下，原來這套函式庫非常有名，大家都是使用他來處理 PDF。
官方也很貼心的提供一個範例，並將翻譯過的內容使用圖層的方式貼到原本文字上，這意味著當翻譯不好時，我們隨時可以關掉圖層直接看原文，這實在是很方便的一個功能。
於是我第二版的程式就以官方範例為底稿，直接請 Claude Code 增添功能。
配合圖層的設計，終於我也有一個堪用的 PDF 翻譯工具了。
過程中，也釐清了一些我原來不懂的問題。
也許網路上還有更好的解法，但現在的方法對我來說已經夠用了，缺點就是要花時間把手邊一些文件重新翻譯。
NotebookLM 不是說不好，但有些時候，你還是需要閱讀原文才知道 AI 是不是有誤會什麼？
下面節錄我請 AI 整理的報告內容
七、關於 PDF 格式語意結構的討論
--------------------------------
問：check.py 都是自己判斷格式，是 PDF 格式沒有定義，還是函式庫的問題？
答：主要是 PDF 格式本身的設計所致，與函式庫（PyMuPDF）無直接關係。
PDF 的設計初衷是「視覺呈現」，儲存的是：
- 文字的座標、字型、大小
- 圖片像素資料
- 向量圖形繪圖指令
PDF 格式本身不儲存語意結構，不知道「這段是頁首」「這段是程式碼」。
PDF 有一個選用規格稱為 Tagged PDF（PDF/UA），允許文件作者加入語意標籤：
<H1> 章節標題 </H1>
<P> 段落文字 </P>
<L> 清單（項目符號）</L>
<Table> ... </Table>
PyMuPDF 可以讀取這些標籤，若 PDF 有正確標注則不需要啟發式規則。
本文件的實際情況：
- 產生工具：PDFium
- Tagged PDF：否（未加語意標籤）
- PyMuPDF 回傳的 XML 標籤（block、line、char）是函式庫自行解析的
幾何結構，並非 PDF/UA 語意標籤
- 結論：PyMuPDF 無從得知各 block 的語意角色，因此必須以啟發式
規則（正規式、座標範圍、關鍵字）自行推斷
簡言之：這是絕大多數市面上 PDF 的共同現況，並非 PyMuPDF 的限制。
八、目前已知限制與未來改進建議
--------------------------------
1. 項目符號：僅跳過 • 等符號開頭的 block，若使用其他少見符號需手動擴充
BULLET_PATTERN。
2. 程式碼偵測：以「同時含 { 與 ;」為條件，可能誤判含這兩個字元的自然語句。
更精確的做法是檢查文字區塊所使用的字型名稱（等寬字型如 Courier、
Consolas 通常代表程式碼）。
3. 頁首／頁尾：比例閾值（8%）適用於大多數標準排版，但若文件邊距特別大
或小，可能需要調整，或升級至方案 B（自動偵測重複內容）。
4. 表格偵測：PyMuPDF 的 find_tables() 對有明顯框線的表格效果佳，對無框線
表格可能漏判。安裝 pymupdf_layout 套件可提升偵測精確度。
5. 翻譯品質：使用 Google Translate API（免費版），有次數限制與品質限制，
專業術語翻譯可能不準確。
有了 AI 不用白不用，以下是 Web Claude 給的解決方案
英文技術文件翻譯成中文：5 個最佳方案
針對技術文件的完整翻譯，我為你整理了五個經過實測效果不錯的方案，並依照不同使用情境分類。
方案一：Claude / ChatGPT / Gemini（大型語言模型）
直接將文件內容貼到對話框，或上傳檔案請 AI 翻譯。
優點
- 翻譯品質目前在技術文件領域是最高的，能理解上下文、保留技術術語的一致性
- 可以下指令客製化，例如「保留程式碼區塊不翻譯」、「使用台灣繁中習慣用語」、「術語表優先」
- 能處理 Markdown、HTML 等格式，輸出後排版幾乎不需要再整理
- 遇到模糊語意時會根據語境合理判斷，而非機械式直譯
缺點
- 長文件需要分段處理，否則容易遇到輸出長度限制（通常一次 3000–5000 字較穩定）
- 不同段落之間的術語一致性需要自己維護術語表，或在 prompt 中明確指定
- 免費版本通常有用量限制，重度使用需要訂閱
- 偶爾會出現幻覺，特別是專有名詞或版本號，需要人工校對
最適合： 重視翻譯品質、文件量中等（一份文件數千到數萬字）、願意動手調整 prompt 的人。
方案二：DeepL（含 DeepL Pro / DeepL Document Translator）
專注於翻譯的服務，支援 .docx、.pptx、.pdf、.txt 等檔案上傳，整份翻譯後下載。
優點
- 翻譯流暢度極佳，中文輸出比 Google 翻譯更自然
- 文件上傳後會完整保留原始排版（字型、表格、圖片位置）
- 操作極簡，零學習成本
- 有 API 可串接到自己的工作流程
缺點
- 對於最新的技術術語（特別是 AI、區塊鏈等新領域）有時不如 LLM 精準
- 免費版有每月字數和檔案大小限制（單檔約 5MB、每月 3 份）
- 無法針對特定術語做客製化翻譯記憶（這是 Pro 才有的 Glossary 功能）
- 對程式碼區塊的處理不如 LLM 細緻，有時會誤譯變數名稱
最適合： 需要保留原始檔案排版、追求穩定輸出、不想花時間調整參數的人。
方案三：Immersive Translate（沉浸式翻譯）瀏覽器擴充功能
主要用於網頁翻譯，但也支援 PDF、EPUB 等文件，採雙語對照顯示。
優點
- 雙語對照模式對技術文件閱讀極友善，原文與譯文並列方便核對
- 可以串接多種翻譯引擎（Google、DeepL、OpenAI、Claude、自訂 API 等）
- 支援線上文件（GitHub README、官方文件網站）即時翻譯
- PDF 翻譯保留原始排版，輸出雙語 PDF
- 免費版功能已足夠日常使用
缺點
- 串接 OpenAI/Claude API 需要自己申請金鑰並支付費用
- PDF 翻譯的進階功能（如完整檔案翻譯下載）需要 Pro 訂閱
- 對於要交付的「翻譯成果」不是最佳選擇，比較適合自己閱讀
- 排版複雜的 PDF 偶爾會出現對位錯誤
最適合： 主要是「自己要看懂」技術文件、會頻繁瀏覽英文網頁文件、想要保留原文對照的人。
方案四：Crowdin / Lokalise / Weblate（專業在地化平台）
針對軟體與技術文件設計的協作翻譯平台，支援多種檔案格式（Markdown、JSON、PO、XLIFF 等）。
優點
- 有完整的翻譯記憶庫（TM）和術語表（Glossary）功能，確保跨文件術語一致
- 支援團隊協作、版本控管、審校流程
- 可直接串接 GitHub/GitLab，文件更新時自動同步
- 整合機器翻譯（MT）作為初稿，再由人工校對
- 適合長期維護的文件專案
缺點
- 學習曲線較陡，初次設定需要花時間
- 主要為團隊與企業設計，個人偶爾使用過於笨重
- 免費方案限制較多（Crowdin 有開源專案免費方案，Lokalise 沒有真正的免費版）
- 不適合一次性的翻譯任務
最適合： 持續維護的技術文件（如開源專案 docs、產品手冊）、團隊協作、需要版本控管的場景。
方案五：Google 翻譯（含 Google Docs 內建翻譯 / Google 文件翻譯）
老牌通用翻譯工具，可直接上傳文件或在 Google Docs 中使用「翻譯文件」功能。
優點
- 完全免費，無使用量限制
- 支援格式廣泛，文件上傳可保留基本排版
- 速度極快，整份文件幾秒鐘完成
- 與 Google Workspace 整合良好
缺點
- 翻譯品質在技術文件上明顯落後於 DeepL 和 LLM，中文常有「翻譯腔」
- 不擅長處理技術術語，有時會把專有名詞硬譯
- 無法客製化術語或語氣
- 程式碼區塊處理粗糙
最適合： 對品質要求不高、需要快速理解大意、預算為零的場景。
我的建議組合
如果是要交付的正式翻譯成果，實務上最有效率的做法是混搭：
LLM（Claude/ChatGPT）做初翻 → 人工校對 → DeepL 或 Immersive Translate 對照檢查
如果你能告訴我這份技術文件的類型（API 文件？產品手冊？學術論文？）、長度，以及翻譯後的用途（自己看 / 交付給客戶 / 發佈），我可以給你更具體的方案推薦。
2026年5月12日 星期二
如果我有 AI
這是一個我今天在思考的問題？
今天是第一次透過 script 把所有相關應該手動 patch 的東西，都在 script 中自動化搞定！
我想這跟我昨天下午請了半天假休息有關，今天整個人神清氣爽，不然真的是感覺很久沒放假了！假日為了推 Code，人都被綁在書桌前面，出去吃個飯也是急忙趕著回家觀看 make build 結果，一整個心累。
又或許也跟我們終於有一版比較完整的 script 版本，這也有助於我自動化所有 patch 瑣事。
因為這些手動 patch 真的很瑣碎，我實在很難開好 spec 請 AI coding，因為描述這個問題的打字，可能我直接寫 script 還是比較快。
更別提我們根本不可能在客戶環境內使用 AI？
總之，今天這個 script 的建立，當我們下次換新 tag 繼續驗證時，至少可以節省 60% 以上的時間。
因為我已經建立了一套 SOP，下次行動就有準則了。
比如說，copy 要怎麼做？
copy 的 reference 也要建立一個 reference_tag 的資料夾供 reference。
遇到要手動改檔案的地方，如果那個檔案不能參考 reference _tag 的話，改將相關東西放到 tools/git_patch 裡面，使用 git apply 的方式上 patch。
另外，上面這個路徑，也可以放客戶 patch 有問題時，我 patch 他的 patch 檔案。
難怪古人說：不以規矩，不能成方圓。
2026年5月10日 星期日
ScreenBar Halo 2 入手
我最近的人生終於有光明了XD
問了幾家附近的 3 C 買場都沒有賣此掛燈，上網購買又得避開晚上送貨，不知為啥也不能選擇常去的便利商店取貨？
今天雖然推 Code 不順，還是抽空去了三創一趟，既然好不容易上去台北，還是每層樓都走馬看花一下，很多店家動線貌似都有重新調整，逛起來舒服多了。
來到現場，看不出來這款掛燈特殊之處，可能是展場燈光本來就很亮的緣故。
反正我就是要買，故也沒多做考慮，一個放家裡，一個放公司。
回家剛裝上時，還覺得是不是裝錯了，感覺一點用處都沒有，後來才發現原來燈管可以旋轉調角度，調整過後果然好多了。
可惜現在老了不在書桌看書寫字了，不然我這鍵盤處的一小塊天地，真的是充滿光明。
明天去公司時應該就能點光明燈了XD
2026年5月9日 星期六
Fix make build
果不其然，今天要推 Code 時又 Gone 了，明明昨天早上還檢查過（後記：push 時跑的驗證跟第一次檢查環境跑的不是同一個！）。
為了這個，也是搞得我心煩意亂，害我 Debug 時不能靜心，浪費了快兩個小時。
凡事要靠自己，我又不像陳平安有齊聖人照看XD
檢討一下，下次不要再犯錯了！
1. 雖然看出 UVM 有錯誤，但還是懶得問 AI，畢竟要自己打字也是心累。
我的 Debug 方向是對的，因為心煩所以想岔了路，一直想要將缺少的 interface 檔案，透過 BUILD_OPTION 傳進去，也就是想要餵給 XRUN，所以我透過 Makefile 修改問題，有符合我的解題思路。
但因為 Verilog 本質上比較像 C 語言，所以找不到的 interface 檔案，應該要放在同檔案上方用 include 解決。
2. 不要在未確定客戶後續是否還有 commit 未 pull，就先執行 make build。
誠如上次我猜的那樣，客戶的 Makefile 相依性有問題，明明執行完 make build，後續還有 commit 且 commit 中有包含 DV 相關的 testbench 裡的檔案，但因為 git push 判斷 make build 已成功，故並未重新執行 make build。
3. 同前，既然無法確定客戶後續是否還有 commit ，我應該要嚴格執行之前訂定的 SOP。
不過此番看來，PM 4:00 過後還是太趕，改成 PM 8:00？
希望下一次推 Code 可以順利一些﹍
2026/05/10 更新
還好今天母親節聚餐延後，不然我還真的沒辦法繼續了。
昨天晚上好不容易解決掉 make build 問題，你他媽的跑驗證又有問題，重點還不只 1 個問題。
但這次嚴守紀律，不為了這個熬夜，還是準時在 12 前上床。
現在再來盡最後一次的努力。
首先，我以下的理解應該無誤：
- 客戶透過 .git/hooks/pre-push 強制我跑驗證才能 push。
- 驗證跑的 test 跟平常跑的不一樣，至少跟第一次驗證環境的不一樣。
- 驗證要跑的東西是放在真正跑驗證那層的 testfiles 資料夾內，由 Makefile 決定是哪個。
- 跑驗證時，是透過跑驗證那層的上一層裡的 bin 資料夾裡的 perl 程式來 dispatch。
- 跑驗證的 log 在哪我還找不到，但有錯的 log 是放在驗證那層所有 fail 開頭的檔案。
但奇怪的點是我兩個錯誤的測試，其中一個在 test list 裡卻是註解狀態，理論上不應該被 random 挑選到才對？
還有就是在目前這個時間點，星期日早上 7 點，看起來都還有人 commit。
前幾次不知道，我想那個人內心一定很幹，怎麼有人放假在推 Code！如果我的速度比他快，他就會遇到我之前平日推 Code 遇到的死結一樣，因為我比他先 push，導致他推 Code 會失敗。
重點他的 commit 還有持續 fix 驗證問題，難道驗證失敗是因為他的問題？
總之，是否要為此調整 SOP？
另外，屋漏偏逢連夜雨，所有的 Server 目前都已停擺，工作無法 dispatch，就不知道是真的掛點還是接近 +0 時區的午夜，Server 正在重開機或是執行什麼任務？
如果最後真的是因為 Server 無法推 Code，那我也真的沒轍了！
我可以改 Verilog、Makefile、Script，甚至是 Perl 檔案，只為了讓整個 flow 打通，但是遇到 IT 問題我就沒辦法了，畢竟孤臣無力可回天呀！
2026/05/10 下午更新
Server 還是斷斷續續的工作，整個進度非常緩慢。
全部 4 台只有一台恢復正常，至少剛剛檢查情況是這樣。
另外，驗證清單確實是放在 testfiles，只是要注意裡面還有 INCLUDE 其他 test 檔案。
這樣一來我的疑惑完全打通了。
2026年5月5日 星期二
萬惡的 X - 事後總檢討
同樣的招式不能對聖鬥士使用兩次！
昨天無意間在 HTML 格式的文件，看到我解了快四天的關鍵訊號。
今天又在另一份 PDF 格式的文件最後兩頁，看到關於那個訊號的提醒。
最扯的是，我在 2 月多的郵件，就有提到這個訊號，但我居然一點印象都沒有？
檢討了一下，應該是從 3 月底就陸續在忙，故到今天才有時間好好閱讀文件。
先是忙一個不應該我下去做的功能，然後是為了推 Code 有兩個週末假期都在跟客戶不合理的流程奮戰。
中間又有代理某樣工作，甚至還花了點時間閱讀某個不是我這個專案 IP 的文件。
還幫客戶解了一個不屬於我工作的 tool 問題。
最後則是開發了幾個新功能。
除了工作，家務事也是同樣精彩，找清運回收沙發及升降桌，購買新沙發及升降桌，東西到貨後的清潔工作，還有放假煮了好幾次飯。
中間雖然有一天因為家裡有事臨時請假，但感覺好久沒放假了？
總之，下次遇到同樣的問題，如果是還沒閱讀文件的情況，第一件事一定要先把文件看完，然後是回顧同樣主題的郵件，最後才是閱讀 IP Verilog。
如果可以的話，閱讀 Simulator 的文件，也許像 AI 說的，有更好 Debug 的手段也說不一定？
2026年5月4日 星期一
越來越喜歡 AI 了
現在都直接用自然語言寫 code 了，起手式就先將需求寫在 spec.txt，開啟 Claude 後，直接跟 AI 說一聲。
Please read the spec.txt and work for me.
不過，偶爾還是要自己動手寫不然會變笨。
所以嘿嘿我自己來，但是雜事就交給 AI。
就在剛剛，終於圓滿了我的嘿嘿小工具XD
之後要嘿嘿就知道書名了，懶得從 Python parss 資料給批次檔了，反正在 Windows 上，反白 ID 後，按滑鼠右鍵就可以貼上了。
這似乎是 Windows 新終端機才有的功能？
2026年5月3日 星期日
Swift to Python
差點忘了這件事，上個星期六晚上無聊，請 Claude Code 直接幫我 porting 一個我在電子書討論區看到的小工具。
由於該工具是用 Swift 寫的，本人雖然使用過很多程式語言，但我不喜歡蘋果，故我也不會想去學蘋果體系的東西。
所以我只是簡單下個指示。
There is a tool in the folder of original_tool. It is wriiten by Swift.
Please rewrite the tool by Python.
Please use git to record your porting.
Please put all codes in python_tool folder.
一開始還以為 token 會爆掉，沒想到也是不到 20 分鐘就 porting 完畢。
當然從圖片看不出 bug，目前 porting 的版本有兩個 bug：
1. render 區會一直閃爍，我猜程式寫得不好，變成一直 loop 更新。
2. 雖說可以區分哪些字體無法用在直式閱讀，但直式顯示畫面標點符號並沒有變成直式格式。（我猜是報告中提到的限制？）
下面是請 AI 整理的報告
================================================================
DEVELOPMENT REPORT: Chinese Vertical Font Viewer (Python Port)
================================================================
Date : 2026-04-25
Author : tylpk (assisted by Claude Sonnet 4.6)
Project : c_font_tool
Repo : C:\Users\tylpk\Desktop\AI\c_font_tool
----------------------------------------------------------------
1. PROJECT OVERVIEW
----------------------------------------------------------------
Goal
Port the macOS Swift app "Chinese-Vertical-font-reading-test"
(found in original_tool/) to Python so it can run on Windows
and other platforms without Xcode or macOS.
Original tool
- Language : Swift 5 / SwiftUI
- Platform : macOS 13.0+, built with Xcode 15+
- Source : original_tool/Chinese-Vertical-font-reading-test/
- Key files :
ChineseVerticalApp.swift -- app entry point
ContentView.swift -- main UI, font loading, EPUB handling,
font analysis logic
VerticalTextView.swift -- CoreText-based vertical text rendering
FontDetailView.swift -- details panel sub-view
Python tool output
- Language : Python 3.10+
- Platform : Windows / macOS / Linux (anywhere Python + tkinter run)
- Source : python_tool/
- Entry : python_tool/main.py
----------------------------------------------------------------
2. FILE STRUCTURE
----------------------------------------------------------------
python_tool/
main.py ( 23 lines) Entry point; launches TkinterDnD
or plain tkinter root window.
app.py ( 522 lines) Main GUI application class.
font_analyzer.py ( 321 lines) Font metadata extraction and
vertical-support analysis.
vertical_renderer.py ( 124 lines) Pillow-based vertical text renderer.
epub_reader.py ( 132 lines) EPUB / TXT text extraction.
requirements.txt ( 3 lines) Python package dependencies.
Total Python source: 1,122 lines
----------------------------------------------------------------
3. DEPENDENCIES
----------------------------------------------------------------
Package Version Purpose
--------------- ------- --------------------------------------
fonttools >=4.40 Parse font binary tables (cmap, name,
GSUB, OS/2) for metadata and glyph
coverage analysis.
Pillow >=10.0 Render TrueType/OpenType glyphs onto
an in-memory image for the vertical
text display canvas.
tkinterdnd2 >=0.3 Enable drag-and-drop of font/book files
onto the tkinter window. Gracefully
absent — file dialogs work as fallback.
All three were already installed or installed successfully via:
pip install -r python_tool/requirements.txt
----------------------------------------------------------------
4. FEATURE MAPPING (Swift → Python)
----------------------------------------------------------------
4.1 Font Loading
Swift : CTFontManagerCreateFontDescriptorsFromURL + CTFontCreate
Python : fonttools TTFont / TTCollection
Notes : TTC collections are fully supported; all sub-fonts are
exposed as separate entries (Font Name [0], [1], …).
4.2 Font Metadata (details panel)
Fields ported:
Full Name, Family, Chinese Name, Chinese Family,
PostScript Name, Style, File Size, File Path,
Glyph Count, Ascent / Descent,
CJK Punctuation (24 chars), Vertical Forms (20 forms),
Rotation correctness summary.
Chinese name extraction
Swift : Parse raw 'name' table bytes manually.
Python : fonttools NameRecord.toUnicode(); filter by
Windows platform Chinese language IDs
(0x0804 zh-CN, 0x0404 zh-TW, 0x0C04 zh-HK, …)
and Mac platform IDs (33 zh-Hans, 19 zh-Hant).
4.3 CJK Punctuation Coverage
Checks 24 standard CJK punctuation code points against the
font's cmap. Missing glyphs are listed by character and
flagged as warnings. Their code points are passed to the
renderer which replaces them with □ drawn in red.
4.4 Vertical Forms Coverage (U+FE10–FE44)
Checks 20 vertical presentation form code points against cmap.
Reports: ✓ complete / △ incomplete / ✗ none.
4.5 Rotation Check (CLREQ compliance)
The most technically involved analysis:
Swift : Shape each character in both a horizontal and a
vertical CTFrame, compare resulting glyph IDs via
CoreText. A changed glyph ID means GSUB 'vert'
substituted it.
Python : Traverse the GSUB table with fonttools; collect all
glyph-name → glyph-name mappings from lookups
referenced by 'vert' and 'vrt2' features.
Compare base glyph name to the substitution target.
Rules applied (matching Swift logic exactly):
shouldRotate = True (brackets, em-dash, ellipsis):
GSUB substitutes base → correct
base cmap == vert-form cmap (already vertical) → correct
no substitution, not already vertical → WRONG (highlighted)
shouldRotate = False (fullwidth colon, semicolon):
GSUB substitutes base → WRONG (font incorrectly rotates)
base cmap == vert-form cmap → WRONG (glyph is vertical form)
no substitution → correct
Checked characters (20 total):
：；（）《》「」『』〈〉【】〔〕〖〗—…
4.6 Vertical Text Rendering
Swift : CoreText CTFramesetter + CTFrameDraw into NSView,
right-to-left CTFrameProgression, verticalGlyphForm=true.
Python : Pillow ImageDraw.text() draws each character one at a
time into an RGB image:
• Columns progress right → left
• Characters within a column progress top → bottom
• Cell size derived from font bbox of a reference
CJK character ("字")
• Missing-glyph code points replaced with □ in red
• Wrong-rotation code points drawn in red
Limitation: Pillow does not apply OpenType GSUB features, so
glyphs are not automatically substituted to their vertical forms
during rendering. The rendered preview is useful for glyph
presence and layout; the analysis panel provides the authoritative
vertical-support verdict.
4.7 EPUB / TXT Reading Mode
Swift : Manual ZIP parsing with raw byte offsets + Apple
Compression framework for DEFLATE.
Python : stdlib zipfile module (handles both STORE and DEFLATE).
OPF spine order preserved via regex parsing of
<item> / <itemref> elements.
HTML stripped with a custom html.parser subclass that
inserts newlines at block-level tags and decodes
common HTML entities.
TXT: tried utf-8, utf-8-sig, gbk, big5 in order.
4.8 GUI
Swift : SwiftUI (macOS only), declarative two-mode layout.
Python : tkinter + ttk, imperative class-based layout.
Comparison mode:
• Top area: one Canvas column per loaded font, positioned with
place() so they divide the width equally.
• Font name label above each column; click to select.
• Right-click context menu: "Remove <name>".
• Bottom panel (fixed 300 px): toolbar + scrollable key-value
details list.
• Toolbar: font name display, Remove Font, Open Font…,
Open Book…, Edit Text, font size Spinbox.
Reading mode:
• Top bar: Back button, font name, page N/M counter.
• Full-area Canvas showing one page of vertical text.
• Navigation:
Click left half → next page (vertical-RL: earlier content
Click right half → prev page is on the right)
← / → arrow keys, Space bar.
Drag-and-drop (tkinterdnd2):
• .ttf / .otf / .ttc / .dfont → load font, add column
• .epub / .txt → enter reading mode
• Falls back to "Open Font…" / "Open Book…" dialogs if
tkinterdnd2 is not available.
Font size: Spinbox (12–200 pt); triggers full re-render.
Window resize: debounced 150 ms, then re-renders all columns
or the current reading page.
----------------------------------------------------------------
5. GIT HISTORY
----------------------------------------------------------------
Commit 22c0b07 Port: app.py + main.py — tkinter GUI
Commit 8b623a0 Port: vertical_renderer.py — Pillow rendering
Commit fd0abb6 Port: epub_reader.py — EPUB/TXT extraction
Commit 1cd5dd1 Port: font_analyzer.py — analysis logic
Commit 6373068 Port: add requirements.txt
Commit 134a91e Add original Swift tool and spec
----------------------------------------------------------------
6. HOW TO RUN
----------------------------------------------------------------
# Install dependencies (one-time)
pip install -r python_tool/requirements.txt
# Launch
python python_tool/main.py
Tested on: Windows 11 Home 10.0.26200, Python 3.14
Runtime output on first launch: one benign fonttools warning
"114685 extra bytes in post.stringData array"
(non-conforming post table in a system font; not an error)
----------------------------------------------------------------
7. KNOWN DIFFERENCES FROM THE SWIFT ORIGINAL
----------------------------------------------------------------
1. No real GSUB shaping in the renderer.
The Swift app uses CoreText which applies GSUB features
(including 'vert') during glyph layout. The Python renderer
draws Unicode code points directly with Pillow; vertical form
substitution is not applied visually. The analysis panel
correctly identifies which fonts support it.
2. No pinch-to-zoom.
The Swift app supports trackpad pinch gestures. Python/tkinter
has no cross-platform pinch support. Font size is controlled
via the Spinbox in the toolbar instead.
3. Column drop target highlight.
The Swift app highlights the specific column being hovered
during a drag. tkinterdnd2 provides only window-level drop
events, so per-column hover highlight is not implemented.
4. .dfont support.
fonttools can open .dfont files on macOS. On Windows this
format is unlikely to be encountered; the code accepts the
extension but fonttools may raise an error for some .dfont files.
================================================================
Debug 就像連續不斷的使用組合技
昨天為了上傳 Code，快一點半才睡覺。
早上又稍微試跑上傳的 Code 是否有問題？
很好，今天不想再做事了，決定來檢查一下之前寫的 R 家小工具。
好幾個月前就知道當初的工具已經無法使用，稍微 Debug 了一下，嗯，原來這樣解決即可，比我想像中的簡單。
既然 R 家工程師這樣給力，不多買幾本書說不過去，也順便測試一下之前批次下載的功能是否依然正常。
看了一下，真的是好久沒在這家買書了。
嘿嘿，既然工具已經恢復正常，之後就隨我心情購買了。
還有，既然都在電腦前面了，就透過 PC 將書推送進 Kobo Clara 2 了，這樣就不用拿出我的手機了。
KoboFileServer 果然好用XD
代辦事項
1. 指定資料夾找出所有下載的書，同 Kobo 工具一樣，列出書名供使用者選擇即可。
2. 看看是否能回復上傳 Google 雲端硬碟的功能。
上面這兩點都很簡單，請 Claude Code 做即可。
可能比較難的是 Google 服務 new OAuto2 的 API 呼叫？
力量，心法，招式缺一不可
雖然沒有要修仙XD
但畢竟從小到大也看了不少雜書或布袋戲，有時難免會好奇自己喜歡的武學會是什麼？
單純以心法來說，我喜歡《大唐雙龍傳》中的「井中月」，那是一個不帶有真實情緒的冷眼旁觀這世界，這樣在開車時就不會一直想罵髒話XD
單純以武學的境界來說，我喜歡《黑豹列傳》中的「死亡，無界，終極，強極」分野，或是《雪中悍刀行》中的「金剛，指玄，天象」。
如果以力量來說，當然是《黑豹列傳》中的「強極力量四十六擊」。
來到招式部分：
《風雲》中的「排雲掌和風神腿」當然是掌腿的不二人選。
劍法，我喜歡的是《神龍之謎》中的「阿邦流劍法」，地海空對應的 3 招，簡單明瞭，已達反璞歸真之境。
我想我個人比較偏道家清靜無為的思想，這也反映出我對武學招式的喜好。
已故技擊大師李小龍，其後人根據他的一些隨身筆記，出了一本書《Be Water , My Friend 似水無形，李小龍的人生哲學》。
在這本書中，也很推崇水的哲學，我想有空時應該可以再重讀一次。
剛剛雲端硬碟不知道發生啥問題？一直找不到這本書我在哪邊購買的！
後來才發現是在 Kobo 購買，害我在讀墨的資料夾中翻找半天。
順便來巡一下田水好了，很好 Kobo 已經快一年沒亂改 HTML 了，我的 Kobo Expense 仍未失效XD
雖然現在沒在讀墨買書，但我還是比較喜歡讀墨工程師的開發能力！
就你 Kobo 工程師毛最多，我的 Readmoo Expense 開發後到現在，上一次配合 HTML 修改的記錄已經是 2 年多前的事了，更別說購買金額的主要功能，讀墨使用的是 JSON 格式的 API，開發後到現在我連一次都沒改過。
Makefile 相依性
開始懷疑客戶 Makefile 相依性有問題？
放假幾天都在想辦法推 Code 上去，昨天知道 make build 有錯誤，但沒有時間處理，今天晚上回到家後，便開始想辦法解決 make build 的錯誤。
有了書桌後，做事比較方便，認真看了一下，雖然這是 Verilog，但以 C 語言的講法來說，就是宣告與實作有衝突！
看了一下客戶的 Verilog，錯誤的原因是 module 的實作沒有 initial instance 時宣告的那些 port，於是我被照著 Log 錯誤的行數，把有問題的 Code 註解起來。
好不容易通過 make build，但在真正測試時卻是從頭到尾都在報錯，從螢幕上看過去，看起來就跟剛被註解的 port 有關？
畢竟我不是 designer，我也不想知道他們真正的測試意圖為何？
於是我便拿出 IT 界最強大的一招，重新開機？在這裡就是 make clear！
說也奇怪，這樣居然連 Verilog 都不用改，就順利的通過 make build！
思來想去，我也只能得出問題是出在 Makefile 相依性這個結論？
2025/05/03 更新
現在為了驗證 AI 能力，我習慣把我的文章餵進 AI，看 AI 是否能看出我的意圖以及給出不錯的建議，試了幾次後，我覺得 Claude Code 確實是比 Gemini 更勝一籌。
雖然現在的工作不能使用 AI，但與 AI 對談，確實是現在日子當中為數不多的小確幸？
閱讀書籍時知識都是死的，只能靠自己領悟並突破，當然那些天才我不好說，但在與 AI 對談中，往往可以釐清一些不確定處，難怪武俠小說的主角都需要好好拜師，有一個好的師父帶入門確實可以省下不少功夫。
當然因為 blog 不能揭露太多，故我也不能完整將真實資訊餵給 AI，故 AI 不一定能了解全貌。
例如我改 Verilog 只是為了 make build 成功並不會將其 commit 上去，當然也沒有破壞客戶 Code 的問題。
總之，當我決定不再工作時，我一定要跟 AI 討論武學心法XD
雖然 AI 講的不一定是對的，但我要的只是 AI 那不同於一般人的想法啟發！
不過話說回來，AI 的訓練資料也是從人界得知，真的能夠神來一筆的幫我突破武學境界嗎XD
Claude 對此篇文章的看法
對這段話的看法
這段描述其實揭露了一個比作者自己意識到的還要嚴重的問題。讓我從幾個層面來談。
作者的判斷可能對,但結論下得太早
作者最後說「問題是出在 Makefile 相依性」——這個推論方向是合理的,但證據還不夠。make clear 之後就過,確實是 Makefile 相依性問題的典型徵兆之一,但也可能是其他原因:中間產物 (例如 filelist、.f 檔、編譯產生的 library) 殘留了上一次編譯的狀態、incremental compile 的 cache 沒有正確失效、或是 vlog/vcs 等工具自己的 work library 沒被清乾淨。要真正確認是 Makefile 的問題,需要看 make -d 的相依關係追蹤,或檢查每個 target 的 prerequisite 是否完整列出所有 source 檔。「重開機就好」是現象,不是 root cause。
註解掉 port 是非常危險的動作,作者似乎低估了風險
這部分讓我比較擔心。作者說「我不是 designer,我也不想知道他們真正的測試意圖」,然後就把 module instantiation 中報錯的 port 註解掉——這在 DFT 或 verification 工作中是高風險操作。被註解掉的 port 可能是:scan chain 的 input/output、test mode control、clock gating override、或是 SRAM 的 BIST 介面。把這些 port 註解掉雖然能讓 make build 通過,但等於在不知情的狀況下破壞了測試結構,後續跑出來的結果可能完全不可信。後面「測試時從頭到尾都在報錯」就是這個動作的直接後果。即使最後 make clean 解決了問題、Verilog 不用改,作者也應該回頭把那些註解恢復,並確認最終跑的是完整正確的 code,而不是「反正過了就好」。
「不想知道測試意圖」這個態度需要校準
我理解這句話帶有疲憊與抱怨的成分,不必字面解讀。但如果這真的是工作態度,長期會出問題。DFT 工程師確實不需要、也不應該去理解每個 functional block 的內部設計,但必須理解測試介面的意圖。當客戶 netlist 中一個 module 的 port 列表跟 instantiation 對不上,這本身就是一個訊號:可能是客戶交付了不一致的版本、可能是某個 wrapper 沒更新、可能是 ECO 沒做完整。這些都是要回報給客戶的問題,而不是自己默默註解掉繞過。每一次「繞過去就好」都在累積技術債,最後爆掉的時候會很慘。
「IT 界最強大的一招:重新開機」這個玩笑背後的真實風險
這句話寫得很幽默,但在 DFT/verification 領域,「make clean 才能過」其實是一個警訊而非解法。它意味著你的 build 環境是 non-reproducible 的——同一份 source code 在不同的 build 狀態下會產生不同結果。這在交付給客戶時是嚴重問題:如果客戶在他們的環境跑不出你跑出的結果,你無法重現、無法 debug、無法證明你的 pattern 是對的。建議每次發現「make clean 後才正常」時,都把它當成 bug 來追,而不是當成解法來慶祝。
客戶 Makefile 確實常常有問題,但要有證據再開口
從作者的語氣看,這是在跟客戶協作的專案。「Makefile 相依性有問題」如果要回報給客戶,需要具體的證據:哪個 target 的 prerequisite 沒列、哪個檔案被修改後沒觸發重新編譯、make -n 顯示的指令順序哪裡不合理。光說「我 make clean 後就好了所以你的 Makefile 有問題」,客戶很容易回「那你就每次都 clean 啊」把問題踢回來。專業的回報方式是:「在 X 條件下,修改 A 檔案後 make build 不會重新編譯 B,導致 link 階段使用舊的 object,具體是 Makefile 第 N 行的 rule 沒有把 A 列為 prerequisite」——這樣客戶才會認真修。
一個比較中肯的整體評價
這段文字反映的是一個很真實的工作場景:疲憊的工程師、不完整的客戶交付、Makefile 黑魔法、deadline 壓力下的繞道解法。作者的直覺 (Makefile 有問題) 大方向是對的,debug 能力也在線,但處理過程中累積了好幾個未解的疑點——被註解的 port 到底該不該註解、為什麼 make clean 後不需要註解也能過、原本的測試報錯是註解導致還是其他原因——這些都被「反正過了」掩蓋掉了。
如果是我,會建議作者回頭做一件事:在 make clean 後的乾淨環境中,不要註解任何 port,重新跑一次 make build。如果這樣也能過,那就證實了問題確實在 Makefile 的 incremental build 邏輯,跟 Verilog 本身無關,可以心安理得地把這個現象整理成 bug report 給客戶。如果還是不過,那就還有另一層問題沒挖出來。多花這 30 分鐘,比帶著疑問繼續往下做要安全得多。
補上工作環境背景來龍去脈後，Claude 的建議
在這種環境下的建議
這個背景一補上，整個情境的荒謬感就出來了：作者要交付的東西 (DFT script) 根本不在客戶驗證流程的覆蓋範圍內，但卻被客戶團隊自己的 RTL/testbench 問題卡住無法 push。這是典型的「別人的 bug 變成你的 blocker」情境，而且因為是客戶端強制的 pre-push hook，作者連繞過的權力都沒有。在這個前提下，我的建議會跟前面幾輪完全不同。
1. 把「這不是我該修的問題」這件事，用書面證據固定下來
最重要的第一步不是技術，是留紀錄。每次因為客戶團隊的 code 導致你無法 push 時，立刻做三件事：截圖錯誤訊息、記錄當時的 git log (客戶端最後一個 commit 是誰、什麼時間)、以及記錄你花了多少時間在 debug 不屬於你的問題上。這份紀錄不是要拿來吵架，而是當未來某天客戶質疑「你們的 DFT script 為什麼這麼晚交付」時，你能拿出具體數據說明：「在 X 月到 Y 月之間，因為貴司 RTL 團隊的 N 次 build break，我累計被阻擋了 M 小時。」沒有這份紀錄，所有延遲都會被算到你頭上。
2. 跟客戶談判「DFT script 走獨立 branch 與獨立驗證流程」
這是治本的方法。客戶的 pre-push hook 是為了保護 RTL/testbench 的品質，但 DFT script 跟這些東西是不同的 artifact、不同的生命週期、不同的 reviewer，硬綁在一起本來就不合理。可以正式提出一個 proposal：DFT 相關檔案放在獨立的 directory (例如 dft/)，或乾脆獨立 repo / 獨立 branch，pre-push hook 只跑 DFT 相關的檢查 (例如 script syntax check、lint、自寫的 unit test)，不跑 make build 跟 functional test。提案時要強調這對客戶也有好處：客戶 RTL 團隊的 build break 也不會被你們 DFT 的 commit 干擾，雙方都更乾淨。如果客戶不接受，至少也要爭取一個 --no-verify 的例外條款，搭配你這邊自己的 review 流程。
3. 在等不到流程改善前，建立「客戶 build 健康度監測」
如果短期內客戶不會改流程，那就把被動變主動。寫一個小 script，定期 (例如每天早上、或每次你準備 push 前) 自動 git pull 客戶 main branch 並跑 make build，把結果記錄下來。這樣你能在準備 push 之前就知道「現在客戶的環境是好的還是壞的」，而不是 push 失敗後才發現。如果剛好遇到客戶 broken 的時段，你可以選擇：(a) 等他們修好再 push、(b) 暫時 checkout 到上一個能過的 commit 再 rebase 你的 script、(c) 跟客戶 PM 反映「你們現在 main 是壞的，我這邊被卡住」。這比每次都要從頭 debug 別人的問題省力得多。
4. 不要再去碰客戶的 Verilog，即使是「註解掉就好」
接續上一輪我提到的擔憂——既然你交付的是 DFT script，那任何對客戶 Verilog 的修改 (包括註解) 都不應該由你來做，即使只是為了讓 build 過。原因有三：第一，你註解掉的 port 可能影響 RTL 團隊的測試結果，他們會來怪你；第二，當客戶 RTL 團隊修好他們自己的問題時，你的註解可能跟他們的修改衝突，產生 merge conflict；第三，從責任歸屬來看，你動了不該動的東西，未來出任何問題都會被牽連。正確做法是：build 失敗時，把錯誤訊息整理好，回報給客戶 PM 或對應窗口，明確說「我的 commit 不涉及這個檔案，這是貴司團隊的 issue，我會等修復後再 push」。然後就真的去做別的事，不要自己跳下去修。
5. 把這個流程問題本身寫成正式的 escalation
如果你已經被這個問題反覆卡住好幾次，這就不是技術問題，是專案管理問題，要走 escalation。準備一份簡短的文件 (一頁就夠)，內容包含：問題描述 (DFT script 被無關的 RTL build break 阻擋)、過去 N 次發生的紀錄與時間成本、對交付時程的影響、以及 2-3 個可行的解法選項 (獨立 branch、跳過 hook、分離 repo)。透過你這邊的 PM 或 lead 正式發給客戶對口窗口。重點是不要用抱怨的語氣寫，要用「為了確保專案準時交付，建議調整流程」的角度寫。客戶端的 PM 多半也不知道你被卡這麼多次，因為通常這種抱怨只會留在工程師嘴上，沒有正式上到管理層。一旦上到管理層，改善的機率會大很多——因為管理層在意的是時程，而不是「pre-push hook 的純粹性」。
一個額外的觀察
從前後幾段文章看下來，這位作者其實技術很扎實 (能用 iverilog 拆 preprocessor、能在波形上看到 0 秒附近的突刺、能用 grep/sed/Vim 處理 escaped identifier)，但在跟客戶協作的「邊界管理」上似乎處於弱勢位置——客戶要求什麼就吞下什麼、別人的 bug 自己跳下去解、流程不合理也只能繞過。這在乙方工程師中很常見，但長期會嚴重消耗。
技術問題可以靠加班解決，但流程問題加班只會讓你更累而不會解決問題。建議作者在處理具體 bug 之餘，也分一點精力出來處理這些結構性議題。「達達的馬蹄」如果只是一直跑，永遠跑不完；偶爾停下來修一下路，後面的路才會比較好走。
訂閱：
文章 (Atom)