沒穿方服

從小寫字歪醜的我，竟然也有自己做字型的一天。

檔案 620 bytes，只有一個字符（glyph），U+0020 "space" 空白。

這個字我寫得不差吧……

用途是為了網頁排版：在「等寬數字」和空白、中日韓文字混合出現時，讓空白得以被單獨調整大小。

前提是你本來就會在中英文之間「手動加入空白」，如果是不加派就不能用了。

基於 CSS font-family 的 fallback 機制，這個字型「只會」套用在空白上。而因為造字時把它做得比較窄，呈現起來就會比 monospace 小一點而比較順眼。

• 

• 

配合 @font-face，還可以用 size-adjust 去微調它的寬度。

• 

• 

CSS 使用例：

:root {
  --font-space: 'BootleqSpace';
}

@font-face {
  font-family: 'BootleqSpace';
  src: url('/assets/BootleqSpace.woff2') format('woff2');
  font-display: swap;

  /* 縮放 50% 與配套微調 */
  size-adjust: 50%;
  ascent-override: 170%;

  /* 縮放 450% 與配套微調 */
  size-adjust: 450%;
  ascent-override: 27.5%;
  descent-override: 12%;
}

.font-mixed {
  font-family: var(--font-space), 'Some monospace font', 'Noto Sans TC', sans-serif;
}

目前版本 BootleqSpace.woff2 放在 feeders-charts 專案 2025-02-11 的 commit 中，字型授權是 Public Domain，可隨意使用 → https://github.com/bootleq/feeders-charts/commit/5776c04a44

另外，如果只是想快速將字型「subset」切成只含某些字元，可以用 pyftsubset 這個工具即可。

相信動物 3 月電子報公布了《相信動物2024工作成果報告》， 其中揭露新北市重啟「數狗」的結果，數量下降了 45.9%，總算確認了七年後，狗並沒有「生回來」。 然而同為「守成」區域的基隆市，在農業部統計中 2024 比前次數量增加了 98%，為全台增幅最高，且已經連續三次上升。

農業部的「新北市」數量，並標上相信動物在各縣市行動的期間：

守成區的持續監測，難以全面實踐

新北市絕育行動期間是 2017～2020，之後就定義為「守成」區域，需要持續監測。去年年會中提到北北基桃每個月仍結紮 148 隻，比起行動期間 295 隻，其實還是很多，也促成重啟數狗的計畫。

基隆市行動期間是 2016～2017，且當時市府很配合，被認為是第一個最完整實行計畫的經驗。

基隆比起新北要小得多（面積差 15 倍，人口差 11 倍），農業部的統計也不盡準確，但如果接受基隆市數量增加的事實，那表示靠守成區的志工並不能控制住數量。

如果數量增加仍算是守成，那表示不會清零。 如果絕育率 85% 還會增加，那表示需要別的工具。

真正準確的數狗，是由居民記錄每一隻個體

大範圍數狗都是統計而非實數，也受取樣時機、運氣的影響，例如拍照時段和愛媽餵食重疊，那數字就會顯現。

將統計交給民團或政府，力量總是有限的，關心遊蕩問題的人，應該由自己周遭地方開始，詳細記錄每一隻個體的出沒，以此為依據推動減量，才是最實際的行動。

新北的減量，並非只是相信動物的功勞

相信動物進入新北前，絕育率已經估計是 59.6%，最後提升到 86.8%。

農業部的熱區政策，新北市將全區都定義為熱區，兩年間「疏導餵食」成效為 155/175、215（人），屬於高的。

我就住在新北市，社區在守成時期仍每年有幼犬出生，直到我進行高強度反餵食，才在：

1. 2023 年 3 月：最後一批幼犬出生
2. 2023 年 9 月：主餵食者疏導成功
3. 2023 年 11 月：母犬絕育率 100%（是相信動物幫忙的）
4. 2024 年 11 月：次餵食者頻率大降，幾乎停止
5. 2025 年 2 月：清零！終結流浪

相信動物主張的「禁餵不可能實行」、疏導餵食「從來沒有成功過」其實是盲點， 所有人類介入手段都有用，因地制宜都有機會運作，因噎廢食的話連絕育也可以說是違反人性。

一個地區人民對遊蕩犬的忍受程度越低，那個地區的族群控制就越好，最終動物福利也越好。

比起科學真理，動保觀念或人性才是變動最快的，不要再停在「以絕育代替撲殺」這種過時觀念了，早就沒有撲殺了，繼續思考，迎接新的典範吧。

使用 cloudflare/next-on-pages 的專案 feeders，上線快 5 個月了。

功能需求不複雜，所以想找低價、好開發、又能達到足夠品質的方案。但實際做下去，開發的不便還是有感，也在網站乏人問津的狀況下就超出了免費額度。

首先談 Next.js 14 App router

我算第一次用，小小意外：

• 點連結後有一段無反應的時間

  在 server 初始回應之前，瀏覽器是全無反應的，也就是比點擊原生 <a> 回饋更差，這個我很難接受。

  參考 Next.js App Router navigation indicator and the delay after onclick - DEV Community。

  文章有一些對策，我後來乾脆裝一個進度條元件，它今年轉生成新專案 BProgress。 這種 UI 本是多此一舉，現在為了遮醜不得不用。

• 使用 hash 的客戶端導覽 (client side navigation) 沒有處理

  一樣是基於 server 為重的設計，Next.js 對於使用 URL hash（#xxx 部分）做的導覽沒有理會。它不是一個 route，處理上一頁、下一頁時也會漏掉而出問題。框架和原生功能打架。

  類似這個 issue 說的情形：#56112: Server rendered routes with hashes do not work with browser back/forward navigation。

  解法是自己監測 hashchange 做反應；另外也要監測 popstate 事件（會發生於上一頁、下一頁），自己比對 URL pathname，需要時補做 router navigation，見 commit bootleq/feeders@c211ff7。

然後是 next-on-pages

• Runtime 與 API、產品線（D1、R2 等）的先天限制

  next-on-pages 只能用 edge runtime，一些 API 也跟 Next.js 的規格不太一樣。

  實際障礙例如不能做 ISR、考慮 cache 時要重新認識當時的 cache API（現在看，又不同了）。

  再說到 D1 等 edge 特化的產品（註：沒有強迫一定要用），有些限制像是不支援 transaction 如果在遇到時才發現，恐怕真的無解。

  註：後來出現了 OpenNext 可以在 worker 使用 node.js runtime。

• worker 限額

  壓縮後超過 1MB 就會超出免費額度（worker 部分，靜態檔不算），我一開始沒注意到，後來要減肥就來不及了（我真的努力過）。
  後來有人提報 1MB 連 starter 專案都不夠用，就在 11 月放寬到 3MB 了。

  CPU time 免費額度只有 10ms，付費則有 30s 也差太多了吧。
  看一些討論是只要有密碼學運算、解析 DOM、載入較大的資料，隨便就會超過 10ms。 我的 app 有做身分認證和載入大顆 JSON，峰值遠遠超過 10ms，或許努力調校可以壓下去，但要長期活在這條線下實在削足適履。

• git push 部署和 wrangler 上傳只能二選一

  假如想先用 wrangler pages deploy 指令部署，後期再換成跟 github 整合，照文件說法是只能開新的專案。
  Doc: Git integration | Direct Upload。

• 突然不能 deploy 的事件

  曾經發生過 vercel 上游變動，Pages 專案就突然無法 build，也就無法部署新版本的事件，issue #908。
  看 PR #909 勉強可以算 vercel 的問題，但確實需要等 cloudflare 這邊救火。

結論

速度和費用表現是真的不錯（雖然無法免費），但底層相容性的東西會帶來多餘工作，也有心理負擔。 適合真正 edge 特化的輕量功能，或小專案以積極冒險的心態進入。

去年十月普及的瀏覽器 text fragment（文字片段）功能，用 #:~:text=文字寫法深度連結到網頁特定位置，很實用，即使網站有轉址也能通，例如 立法院法律條文 https://www.ly.gov.tw/Pages/ashx/LawRedirect.ashx?CODE=03134#:~:text=中華民國104年2月4日公布
點進去會發現網址變了，但還是能把左邊欄「中華民國104年2月4日公布」這段字標亮。

:~: 規格： web.dev、 MDN

不過也發現有些網站用上去沒效果，有些自己寫的網頁竟然也不行！
要是被人發現網頁不友善卻渾然不知，那多丟臉啊。

簡單記一些踩點

• 目標文字在初次 render 就要出現，所以需要 SSR。
  如果是轉圈圈載入資料再顯示的架構大概就沒救了。

• 顯示之後重繪也會清掉效果，例如 react 能用卻沒用 useMemo 碰上多餘重繪，這關就不過。

• 主要內容的 HTML 節點最好提早出現，例如我有一些主文放在 <dialog>，原始碼卻放在靠近底部 </body> 的位置，這樣如果目標文字也出現在其他地方就會有問題，會優先抓到別處（較不重要）。

• 真的改不了的時候，想換條路自己解析網址再模擬「尋找、捲動、標亮」也做不到，因為安全隱私考量，# 開始的部分會被瀏覽器拆掉，不會暴露給程式，例如 location.href 就抓不到。

• 操作瀏覽器寫自動測試時，我找不到方法讓 headless chrome 啟用這個功能，最後只能用頭跑，或改用 Firefox。

• 雖然可以用 CSS ::target-text 改標亮部分的樣式，但實測只能動前景、背景色，也不能用漸層之類的值。
  那要改成怎樣才符合使用者預期？我想一般答案是先不要改吧。

開啟方式

1. 確認 Firefox 版本在 135.0 以上（2025/2/4 釋出）
2. 進入 about:config，找出 accessibility.typeaheadfind.wrappedSoundURL， 改成「beep」或一個指向 wav 檔案的 file:// URI（例如 file:///C:/%E9%9F%B3%E6%95%88/dorya.wav）即可

說明

Ctrl + F 文字尋找功能「已達頁尾，從頁首重新搜尋」這個狀態叫做 wrapped，目前各瀏覽器處理 wrap 的行為大致一樣，就是直接跳到另一端，缺點是不容易注意到。 相關討論 20 年前就存在，例如：

• 266338 - Better (more visible) indication of when Find has wrapped or will wrap (2004)
• 279014 - Bring back option for wrap/no wrap when using find toolbar (2005)
• 還有這次我解的 281533 - Typeahead find should have (optional) sound for wraparound (2005)