[專業涵養] 像素、點、其他長度單位，以及觸控目標尺寸（下篇）

前情提要：本文意圖在盡量簡要說明在不同情境中的像素、點、其他長度單位，也趁此機會加以討論觸控目標尺寸要怎麼設定比較理想。

註：因為篇幅太長了，所以拆成上、下兩篇。上篇主要討論各種長度單位的定義及換算，下篇（本篇）主要討論觸控目標尺寸的建議。

……文長未完，敬請撥冗閱讀《像素、點、其他長度單位，以及觸控目標尺寸（下篇）》全文。

[專業涵養] 像素、點、其他長度單位，以及觸控目標尺寸（上篇）

像素 (pixel, px) 是個很常被誤解的度量衡單位，在不同的情境代表不同的意思，實際上這裡的 1 像素跟那裡的 1 像素並不相等；光是這樣已經夠讓人頭疼，但是事情還可以更混亂複雜，點 (point, pt) 在不同情境也有不同的意思，這裡的 1 點跟那裡的 1 點不相等，這裡點跟像素的換算比例跟那裡的也不同……。

討論觸控目標（能夠經由觸按操作產生效果的區域範圍）前，若不先把這些單位搞懂，直接把各種規範裡的尺寸數值抓出來比較，勢必一頭霧水。最近我收到一個疑問：為什麼〈TS3 觸控目標尺寸〉的測試程序定義到 48 × 48，比〈SC 2.5.5 Target Size (Enhanced)〉要求的 44 × 44 還大？簡短來說，因為這兩處使用的單位不同，實際上若分別以各自的參考標準設備來測量，前者規範的物理尺寸 48dp 比較小（屬於比較寬鬆的規範，因為同樣的顯示空間裡可以塞進更多觸控元件）、後者規範的物理尺寸 44px 比較大（比較嚴格），提問者沒有注意到數值的單位差異，才產生這樣的疑問。

我覺得帶出這個問題，正好提供一個很棒的討論機會，讓我用本文盡量簡要說明在不同情境中的像素、點、其他長度單位，也讓我們趁此機會加以討論觸控目標尺寸要怎麼設定比較理想。

……文長未完，敬請撥冗閱讀《像素、點、其他長度單位，以及觸控目標尺寸（上篇）》全文。

[黑客人生] 助聽器選配調整軟體檢查更新

與本文相關的腳本源碼下載、說明、議題回報等，請移駕至 JediLin/Hearing-Aids-Fitting-Software-Update-Checkers 源碼倉儲。

電腦桌面上有 35 個應用程式啟動捷徑圖示，包含 19 個廠牌的助聽器選配軟體及更新檢查軟體，以及 NAL-NL2 與 CAM2 處方公式的官方軟體

因為工作或研究需求，而安裝眾多廠家助聽器選配調整軟體的夥伴，必然遭遇管理這些軟體版本的困擾。主流大廠的助聽器選配調整軟體（以下簡稱選配軟體）多半具備線上檢查更新、下載相關媒體庫等功能，這些功能可能要先執行選配軟體後從功能選單裡執行，或者要另外在電腦背景執行「更新檢查軟體」。一旦檢查確認軟體版本更新，這些選配軟體也能自動下載更新所需的檔案，提供安裝之餘也讓使用者能夠另存這些檔案的副本，以便布署到其他電腦上。

然而對於電腦安裝眾多軟體的情況，逐一執行這些軟體顯得不是很有效率，在背景執行所有更新檢查軟體也顯得太耗費電腦資源；又或者因為安全考量，不想把執行選配軟體的電腦接上網際網路，因而無法使用相關的檢查更新功能。有沒有什麼辦法，可以更容易地檢查選配軟體更新、甚至把更新要用到的檔案直接下載呢？

……文長未完，敬請撥冗閱讀《助聽器選配調整軟體檢查更新》全文。

[廚餘瑣碎] Dukto: 區域網路檔案傳輸的第一把交椅

「我想要快速地把這堆檔案從這個設備傳輸到那個設備」，如此簡單的需求，令人訝異地難以實現。十幾年前，行動通訊邁入 3G 時代，每個人手邊開始常態地攜帶多個電腦設備（包括智慧型手機），在設備之間傳輸檔案也成為日常生活的一部分。這個看似簡單的需求，隱藏著許多挑戰：

跨平台
不是每個人都願意把自己鎖在特定廠商打造的生態環境。舉例來說，我曾經同時擁有 Windows 電腦、Linux 桌面設備、mac 電腦、Android 行動電話、Android 平板電腦、iPod、iPad、Symbian Belle 行動電話，意味著光靠著微軟、蘋果、榖歌等廠商提供的解決方案，都沒辦法涵蓋我手上所有的設備。
傳輸速度及檔案大小
也許一口氣需要傳輸幾千個檔案，也許需要傳輸幾十甚至幾百 Gigabytes 的檔案。我需要盡量快的傳輸速度，為此我可以犧牲一些安全性，意思是我不需要傳輸過程中的加密解密。
資料夾
有時候需要連同資料夾以及子資料夾結構一起傳輸。當然可以先把資料夾壓縮再傳輸，但是這樣往往花費更多空間、時間，操作上也更麻煩。
區域性
只是要把檔案從自己的某個設備傳輸到另一個設備，我不希望這個過程中還需要先把檔案交給另一方（例如各種雲端服務）；除了不想過多暴露自己的隱私之外，也希望減少外部依賴，以免網際網路異常或任何雲端服務商因故暫停服務時，就無法順利傳輸檔案。
臨時性
我只想在有需要傳輸檔案的時候才傳輸檔案，不希望為了這種任務還要特地先在各個設備上架設檔案伺服器；換句話說，這個機制應該要很容易開關、設定組態應該極簡。

我在 2012 年產生這樣的需求，當時已經有個很合適的開放源碼解決方案：Emanuele Colombo 開發的 Dukto。很快地，Dukto 進入我的生活。

然而 Dukto 在 2013 年推出 R6 版本之後，不再繼續維護開發；Dukto R6 使用 Qt 4，這個 Qt 版本在 2015 年年底已經終止維護，我手上陸續更新的設備開始遇到無法安裝或執行 Dukto 的挑戰，然而接下來十年，市面上所有號稱「Dukto 接班人」的解決方案通通無法真正取代 Dukto 的性能與便利。

拜開放源碼所賜，仍有其他開發者接手分支，讓 Dukto 至今仍然能夠繼續傳承下去：

Xu Zhen
xuzhen/dukto-qt5 專案把 Dukto 移植到 Qt 5 及 Qt 6，可在新版的 Android、Linux、macOS、Windows 等系統上編譯安裝，並提供預先編譯好的 Android (arm64-v8a_qt6, armeabi-v7a_qt6, multiabi_qt5, x86_qt6, x64_qt6) 及 Windows (x86_qt5, x86_qt6, x64_qt6) 安裝套件，以及適用於 Ubuntu 的 PPA (Personal Package Archives)。
Kafabih Rahmat
kafabih-kr/dukto 專案也提供適用於 Linux 及 Windows 的執行套件。
Trọng Phạm
Tian Media Transfer 是與 Dukto 相容的 Symbian^3 應用程式，比原始 Dukto for Symbian 更為穩定。
Davide (Dede)
Dukto Pro 似乎是唯一存在的 iOS/iPadOS 版本分支，不過此刻似乎已經無法購買或取得了？我自己有幸在多年前購入，目前在 iPad mini (5th Generation) 還能夠使用。

更古早以前

jedi.org: