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

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

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

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

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

像素 (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: