2024-12-23 17:36:17
（圖是日本的四個季節不同版本的封面）
可能會捏到的感想！上市一陣子了，本來是想要找個好日子幫書拍照後才發表，不過實在拖的有點久了，剛好又找到上面那張圖，就決定拿來用了。
總之還是多一行警告一下XD！
其實因為宣傳關鍵字的關係，加上最近有不少日本印刷品有用到這特性（像是獵人、還有報紙廣告），我一拿到書就發現其中奧妙了，不過其實這個奧妙讓我閱讀時的體驗，也確確實實的和其他紙書不一樣，簡單的形容，就是視野內的畫面特別乾淨、明亮，不過這些形容又太過強烈，思考了一陣子，確實用「透明」來形容非常適合，甚至我覺的作者杉井光在撰寫時，文句的挑選可能也有為了呼應「透明」而下了不少功夫，結果就是這個「透明」的主軸其實延伸到各個地方：故事主軸、文章風格、出版形式、閱讀體驗都有，要稱為世界上最透明確實當之無愧。
然後仔細研究一下發現日版是一年前出版的了，所以最近常見日本的印刷出版品利用這特性或許就是這本書帶起的風潮。
回到閱讀體驗這件事上，其實在我意識到這件事情之後，我聯想起作者另外一本我剛好前陣子才在看的輕小說「樂園 NOISE」，在第一集第一段就有提到女主角當時追求的是現實上不可能存在的無雜音的音樂，男主角後來用電腦生成無雜音的音源讓女主角實際有機會聽到自己演奏出的無雜音的音樂，要知道作者描寫音樂的文字是評價很高的，但是這邊卻完全沒有無雜音音樂的形容（一部分是因為用耳機主角自己沒聽到），但是其實也給讀者一個懸念，好想聽聽看比比看所謂無雜音的音樂啊。
或許只是想太多，不過或許，世界上最透明的故事 那個奧妙的緣起其實就從樂園 NOISE 提到的那個無雜音音樂，只是他用不是音樂的方式傳達給讀者了。
最後想談談這本書本身，「光是能出版，就稱得上是奇蹟了。」這件事，要我形容的話，這本書就像是我們現在看的一些文藝復興時代的藝術品，在工藝上達到一個時代登峰造極之下的產物，未來的人看到只會覺得「太精緻，做的太巧妙了吧，難以想像用現在的人力要做出一樣的東西」一般這樣，足以作為代表紙書時代的一本書。
補一些連結：
最後列上人名 作者：杉井光 譯者：簡捷 責編：菜承歡
突然想到漏了一件事，這就一定要看過才知道了，就是那個最後那個詞，我以為是謝謝你來到這個世上之類的溫馨想法，結果看到有人說是謝謝你給我這個點子，思考一番後覺得後者比較對，因為對兩個人來說都是成立的想法，不過就比較冷血一點就是。
btw 作者收到中文版，還有確定要出續集了。
世界でいちばん透きとおった物語、台湾版の見本誌をいただきました。
-- 杉井光 (@hikarus225) October 10, 2024
完璧な形で作っていただいたこと、ただただ感謝と敬服です。 pic.twitter.com/PD2GP2eq6j
『世界でいちばん透きとおった物語2』、来年の1月末発売です。続編は今年中に出す、と各所で言っておきながら原稿が遅れまくって今年中に間に合いませんでした。申し訳ない......https://t.co/Xq3E1CJsOJ
-- 杉井光 (@hikarus225) November 25, 2024
2024-12-22 17:24:42
前兩天意外發現 blog 的資料庫（MariaDB）死掉起不來了，加上我剛好沒有新的備份，所以這兩天就花了些時間慢慢修復，總之首先，我根據一開始的錯誤訊息大概搜尋了一下，發現說可以把 /var/lib/mysql 目錄下的 ibdata1、ib_logfile0、ib_logfile1、aria_log_control 等檔案砍掉試試看（當時完全不知道是什麼），於是我簡單備份後就砍掉重啟試試看，結果 MariaDB 真的就復活了，只是我接著要跑 mysqldump 時就出現其他的錯誤：
mariadb-dump: Got error: 1932: "Table 'blog.mt_asset' doesn't exist in engine" when using LOCK TABLES
而且因為我的 shell script 太簡單，沒檢查結果，這錯誤還把我的本地備份覆蓋掉了😂，總之搜尋研究一陣子之後，發現這問題是因為 mt_asset 資料表是用 InnoDB，然後 InnoDB 有些資訊是集中在 ibdata1 的，不能只靠資料庫目錄下的 mt_asset.* 檔案來還原，結果我的作法就是把備份的 ibdata1 還原回來，試著在 my.cnf 裡加上:
[mysql]
innodb_force_recovery = 1
如果用 service 的話就要放到 [mysqld] 區段內，數值從 1 試到 6，然後 su 到 mysql 這個帳號下手動執行 mariadbd 指令來啟動資料庫，其實第一次嘗試是失敗的，到第二次試到 6 時才成功，然後趕快跑 mysqldump，結果有成功跑完，不過因為之前 mt_asset 有出過錯誤，我就認真檢查了一下 dump 出來的資料，結果果然， mt_asset 只有結構沒有資料，於是又檢查其它的 InnoDB 資料表的 dump 的輸出，結果是有的有資料有的沒有，不過由於資料本身應該還在，所以我接著嘗試用 mariadb 命令列模式進去 DB 手動 SELECT mt_asset 的資料，發現真的都還在，不知道為何 dump 會失敗，不過總之我就試試看死馬當活馬醫，用 mysqldump 匯出單一個資料表的資料：
mariadb-dump -u user_name -p db_name mt_asset > blog.mt_asset.sql
結果，竟然成功匯出了，於是就手工把每個有問題的 InnoDB 匯出，然後手工整合回去全資料庫的 dump 出來的 sql 檔案，有些資料表還是沒資料，不確定是不是本來就沒有的，不過看起來也不是重要資料，不影響 MovableType 運作，所以就不管。
然後因為我好像用不太到 InnoDB 的優點，加上發生過一次這種事情，冷備份比較簡單的 MyISAM 還是比較適合我，就順手都改成 MyISAM 資料表；同時，又想到因為我的 CHARSET 還是用 utf8，所以一直都還不能用 emoji，之前也有想過要換到 utf8mb4，只是一直沒動手，就趁機一起手工改了 mt_entry 表下的幾個相關的欄位：
`entry_title` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`entry_excerpt` text CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`entry_text` text CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`entry_text_more` text CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT NULL,
這樣大致上就把 sql 檔案準備好了，回到這次發生問題的原因，我推測是用 pacman 更新套件時，更新到 MariaDB 後，不知道為何造成 ibdata1 檔案損毀，一開始的錯誤訊息試有看到說某個檔案是 MariaDB 10.4.8 建立的，所以我是先退回 10.4.8 然後才進行上述的修正，還好上次已經操作過一次了，之後為了避免再次有太久沒更新出事，就決定也要把 MariaDB 更新一下，所以其實是先更新最後才把 sql 檔案匯入的。
更新完把 /var/lib/mysql 目錄下的 ibdata1、ib_logfile0、ib_logfile1 都砍掉，重新建立資料庫後才匯入，還好一切順利，詳細的說明其實在 MariaDB 的 Knowledge Base 也都有，最後就補上兩個我覺得很有幫助的文件：
另外補充，如果要在 MovableType 4.x 使用 emoji，除了資料庫欄位的設定外，還需要修改一點程式碼，詳見我的修改紀錄 🥳。
2024-10-19 13:17:31
在現在這個網路標準橫行的時代，要遇到還沒廣泛標準化的東西其實是越來越難了，不過我最近還是遇到了一個，那就是 autofill 的偵測。
首先要說的是，autofill（自動填入）和 autocomplete（自動補完）嚴格定義下是不一樣的，雖然都可以透過 autocomplete 來控制相關的行為，但是 autocomplete 其實只能算是 autofill 的一種，而我遇到的就是非 autocomplete 的，信用卡資料的自動填入，那問題在哪呢？
問題就是這種 autofill 發生時，瀏覽器不一定會觸發 change/input 事件，如果表單設計成自動檢查表單輸入，然後輸入都正確才讓人送出的話就會有使用體驗的問題發生，因為這種設計的欄位檢查通常就是綁在 <input> 的 change/input 事件上，結果就是如果瀏覽器自動填入，然後又沒觸發 change/input 事件，於是就不會執行到欄位檢查，表單也就會一直維持在無法送出的狀態，產生的副作用就是使用者體驗反而比按下送出按鈕才作表單檢查還要來的差。
那麼在 Web 標準中，change 事件應該何時觸發的定義是為何呢？在 HTML 4.01 是這樣寫的：
The onchange event occurs when a control loses the input focus and its value has been modified since gaining focus. This attribute applies to the following elements: INPUT, SELECT, and TEXTAREA.
按照古時候網路標準的規範，autofill 不是使用者和 DOM 之間的互動，沒有經過 focus blur，所以沒有觸發 change 事件也是合理，事實上也就是現在部分瀏覽器的行為；不過在現在的 HTML Living Standard 是這樣寫的：
The
changeevent fires when the value is committed, if that makes sense for the control, or else when the control loses focus.
觸發的時機除了失去 focus 時之外，還多了資料 commit（提交）時，變成兩種時機，而這邊的提交主要指的是像 type=color 或是 type=date 那種，瀏覽器有支援，有提供另外頁面內的小工具讓使用者方便挑選值的時候，使用者選好，瀏覽器更新值進入 <input> 的 value 的動作，那 autofill 更新值該算是 commit 嗎？其實文件內也是有講到的，就在同個章節的後面：
When the user agent is to change an input element's value on behalf of the user (e.g. as part of a form prefilling feature), the user agent must queue an element task on the user interaction task source given the input element to first update the value accordingly, then fire an event named
inputat theinputelement, with thebubblesandcomposedattributes initialized to true, then fire an event namedchangeat theinputelement, with thebubblesattribute initialized to true.
這段就是說當瀏覽器代表使用者改變 input 的值時，也是要發一個 input 一個 change 事件，這段文字的重點在於 "on behalf of the user"，就是「代表使用者做事」，後面舉的例是 prefill 時，prefill 通常發生在 帳號/密碼 欄位，發生時間點又不太一樣，可能是在 render DOM 時就發生；不過根據文字解釋其實 autofill 應該也符合 "on behalf of the user"。
雖然 HTML 標準有規範了，但是現實世界總是不會這麼美好，不然也不會有這篇文章了，那麼現實世界是怎樣呢？我遇到的狀況就是有些瀏覽器是照著舊的規範，完全沒有事件，發現問題後我就上網搜尋一番之後發現，這問題其實已經很久了，早在 2010 年，@avernet 就寫了一篇 [Autocomplete and JavaScript Change Event][]，紀錄了當年的這個問題，根據不同欄位、不同瀏覽器會有不同的行為，即使到了今天，也還是同樣情形，文章最後建議的解法也是很無奈的：
Autocomplete and JavaScript Change Event
autocomplete=off
總之就是讓人不喜歡的解法，那麼時至今日，有沒有比較好的方法呢？其實還真的有，而且蠻聰明的，Klarna 的 Tommy Brunn 在 2016 年寫了 Detecting autofilled fields in Javascript 一文介紹了這種方法，透過 CSS pseudo-class :autofill 和 CSS animation 配上 animationStart 事件，首先 CSS 這樣：
input:autofill {
animation-name: autofill;
animation-duration: 500ms;
animation-fill-mode: both;
}
@keyframes autofill {
from {
background: var(--color1);
}
to {
background: var(--color2);
}
}
然後 JS 監聽事件並確定動畫名稱沒錯，就可以做事了：
inputNode.addEventListener('animationstart', (event) => {
const { currentTarget, animationName } = event;
if (animationName === 'autofill') {
// do what ever you want, or
// trigger `change` event
currentTarget.dispatchEvent(new Event('change'));
// trigger custom event
currentTarget.dispatchEvent(new Event('autofill'));
}
}, false);
完全成為真的 event based，不用定時檢查了，不過缺點是要 CSS 搭配，不是純 JS 的方案，維護上比較麻煩一些，另外就是 Tommy Brunn 文章內用的是 :--webkit-autofill，但是現在完全可以用沒有 prefix 的 pseudo class 了。
以上的程式碼範例就可以處理好瀏覽器內建的自動填入事件，不過現實世界除了瀏覽器內建的自動填入，還有很多的第三方工具支援，像是各種 password manager: 1Password, LastPass, Dashlane 等，這些工具自動填入的行為又不太一樣，我確實有發現有其中一兩家的行為也是 value 會改變，但是不會有 input 和 change 事件，幸好這些工具都會加上各自自訂的 attribute，所以可以另外透過 observer 監看 attribute 的變化來判斷是否有相關的事件，目前我所知道有以下的 attributeName 可以檢查：
data-dashlane-autofilled Dashlane 的data-com-onepassword-filled 1Password 的chrome-autofilled iOS Chrome，超容易漏掉至於 LastPass 目前測試結果是不會有自訂的 attribute，但是會有 change 事件，所以也可以照常運作（不過相對的就完全沒有提供給使用者的視覺提示好像怪怪的）。
這篇內容大概就到這邊，雖然沒有提供很完整的程式碼，不過這些資訊應該很夠幫助其他人完成 autofill 事件的偵測了，其實這次弄信用卡資訊的輸入欄位真是費了不少心力，很多細節可以弄，也很多 domain knowledge（都靠 lib 搞定就是），真是想不到只是信用卡欄位也這麼多眉角。
2024-07-21 18:33:34
2019 年的時候，寫過一篇文章介紹了 Lab Gradient，然後就沒特別關注相關發展，直到前幾天看到勞哥的推文提到 Oklab 這個色彩空間，而且瀏覽器已經原生支援了，我才發現原來網路標準的發展有跟上來，我也趁機多惡補了一些相關的知識。
因為一些搜尋讓我今天才了解 oklch 這個色彩格式（或是色彩空間）的使用方法。這個色彩格式在 2023 年納入了幾乎所有現代瀏覽器，好奇查詢之下發現了作者的 blog 有寫為什麼要製作 Oklab 的原因與研究過程，以及詳細的討論過去 HSV 或 HSL 系的色彩空間到底有什麼問題，收穫滿滿。...
# -- 勞哥 maylogger (@may_logger) July 13, 2024
在介紹 Oklab 前，先來介紹以前提到的 Lab 吧，其實它是國際照明委員會(International Commission on Illumination，簡稱 CIE)在 1976 年提出的色彩空間定義，全名是 CIELAB color space，或是簡寫為 L*a*b*，多加 * 為了避免混淆，Lab 其實是不正確的縮寫，不過這三個字母其實就是該顏色空間的三個軸：L 代表亮度、a 代表紅色到綠色間的位置、b 代表藍色到黃色間的位置，也就是 opponent color theory（又稱對比色理論或色覺對向論）的顏色組成，這個色彩空間的重點在它的座標比較符合人類對色彩的感知。
那 Oklab 又是什麼呢？它是 Björn Ottosson 在 2020 年底發表的一個新的色彩空間定義，他在文章內有詳細的說明為什麼會想要定義一個新的色彩空間，文內也列舉了現存的色彩空間的主要問題，其中 CIELAB 的問題就是在 predict hue （預測色相）有些問題，尤其是藍色附近，其實我一開始對於這個 predict 感到很疑惑，想說到底是什麼意思，後來看到另外一篇文章 An interactive review of Oklab，文章一開始放的互動工具預設的漸層設定就是藍色到白色，然後一看就很明顯， CIELAB 的漸層色相跑一下就歪掉了變成偏紫色去了（random 按鈕可以按按看看其他色相都沒這樣嚴重），才了解到因為 CIELAB 是屬於人類感知的色彩空間，意思就是它的依歸其實是人類的感覺，所以需要從三維座標去推測人類實際上看到感覺到的顏色，數值上一樣的話就應該讓人感覺一致，而 Oklab 則是結構和 CIELAB 一樣，但是透過新的資料集來調整並解決前面提到的問題，而後在 2023，Oklab 進了 CSS Color Level 4 的草稿，主流瀏覽器現在也都已經支援。
進 CSS Color 代表什麼意思呢？第一個當然就是可以用 oklab() 函數來定義顏色了：
oklab(40.1% 0.1143 0.045);
oklab(59.69% 0.1007 0.1191);
oklab(59.69% 0.1007 0.1191 / 0.5);
除了直接定義顏色之外，現在 CSS 也支援相對顏色（relative color）了：
/* Relative values */
oklab(from green l a b / 0.5)
oklab(from #0000FF calc(l + 0.1) a b / calc(alpha * 0.9))
oklab(from hsl(180 100% 50%) calc(l - 0.1) a b)
這樣要只調整色相或是亮度都變得很簡單，或是也可以用 oklch()，這樣色相（Hue）就更好挑選。
然後就是漸層了，現在的 CSS 漸層也支援使用不同的顏色內差方式，也就是用不同色彩空間來算中間的顏色變化：
linear-gradient(in oklab, blue, red)
linear-gradient(in lab to right, #44C, #795)
在最前面加上 in <color-space> 就可以，支援的色彩空間其實不少，如果是線性漸層，那支援 srgb、srgb-linear、display-p3、a98-rgb、prophoto-rgb、rec2020、lab、oklab、xyz、xyz-d50、xyz-d65，如果是 polar 漸層，那支援 hsl、hwb、lch、oklch，其實相當夠用，而這段語法其實是叫 color-interpolate（顏色內插），除了漸層之外，會用到的地方還包括 filter、animation、transition 和 color-mix() 函數等。
前面也已經提到，現在主流瀏覽器都已經支援了，不過還是來看一下 caniuse 上的細節，Chrome 是 2022 就支援了，但是 Firefox 是到去年的 2023 才支援，如果要抓兩年的時間的話就還要再等等，當然現在也還是可以直接用，多加一組 fallback 就可以。
除了瀏覽器原生支援外，其實也不少其它開發相關的工具支援，也有不少文章在介紹，像是 Smashing Magazine 的 Falling For Oklch: A Love Story Of Color Spaces, Gamuts, And CSS 和 Evil Martians 的 OKLCH in CSS: why we moved from RGB and HSL，兩篇文章就介紹了不少工具和一些延伸的文章，工具部分像是 Figma 的 plugin OkColor 和 npm 上的 convert-to-oklch，Evil Martians 還做了一個 oklch.com ，是針對 Oklch 的 color picker 還蠻厲害的。
2024-05-16 20:19:02
照片是常滑招財貓大道的「除憂解難」。
沒想到這週這麼熱鬧，前後兩天分別發生兩件和溝通有關的熱烈討論（網路對罵？），第一件事情比較少人知道，是發生在 COSCUP 的 telegram 社群，雖然是公開社群但是因為沒有直接的公開網址所以我就不寫網路 id 了。有社群朋友（後面用 A 代稱）想要辦 BoF 需要一些硬體設備，但是因為今年的 BoF 公告還沒出來，所以他想知道大會方是不是有機會能協助（幫忙借用設備），可以的話就會提出申請，其實如果熟悉 BoF 的應該都知道大會方只有提供場地，不過我當時在開車也沒辦法馬上幫忙回，總之就有其他朋友幫忙回了，四貓作為工作人員也在幫忙釐清對方的需求，當時大概就是有位社群朋友回文時多了一句：
但如果認為大會方該要提供的話，你們預期大會方能從哪搞到這個資源呀
其實我覺得 A 一開始的文字並沒有這樣的意思，但總之結果這段文字就激起 A 的情緒了，然後就口氣變差，出現了一些情緒回文，接著就變成 A 和一些其他社群朋友開始互吵，其中心穎四貓和我其實都有想要幫忙緩和一下，不過雙邊都沒想要暫停一下，所以就一發不可收拾吵了整個下午，總之直到最後都還是有些情緒文字。
其實這件事有點讓我聯想到「精製動畫坊（HGA）」，非常早期就在台灣經營動畫模型領域的商品，年過四十小時候就有接觸動畫的人可能多少都會聽過 HGA 的大名，黃老闆其實人很好，然後店內也有一群熟客，其實很多人都在圈子內有點名氣，不過就是這群熟客其實也某種程度製造了一個 AT 力場，會讓不在圈子內的人想要進去有阻力，其實我在光顧 HGA 的幾次經驗也沒真的實際接觸到黃老闆以外的那些人，但是我還是要說那個氛圍確實是存在的，有朋友就說是「成也熟客、敗也熟客」。
當然我不是在說 A 的發言都沒錯，A 後來的幾則發言我都覺得這我也很難幫忙緩和了，所以要我說的話，在那個時間點這或許已經是一場無可挽回的難過事件了，不過我還是想說，非當事人的幫忙有時候真的是沒幫上忙啊。
然後隔天發生的另一件事，則是在推特上的「最困難的就是和工程師溝通了！有夠固執不懂變通！」炎上事件了：
這也是位年薪百萬的學員喔！恭喜恭喜！
-- Akane Lee (@akane_lee) May 14, 2024
她說，她現在不只要跨部門討論專案，還得跨國溝通，公司裡什麼樣的同事都有。
「最困難的就是和工程師溝通了！有夠固執不懂變通！」
這是第 N 位跟我抱怨工程師有夠難溝通的學員了。
（我也這麼覺得！）https://t.co/s7jjdgJ4I4
然後推特上一堆工程師就受不了了，紛紛分享出他們遇過的很瞎的溝通經驗或是他們的看法，當然也是有一些比較沒意義的酸文，不過其實有一些蠻值得一讀的，像是海總理的這串（共九則，請點過去看完整文串）：
覺得對方難溝通，大多是因為
-- 海總理 (@tzangms) May 16, 2024
「你只想得到你想要的，不想聽你不懂的」
其實這個炎上事件我覺得是屬於用詞不精確所引發的，因為 Akane 一開始的文字直接使用「工程師」，沒有加上「部分」或是「一些」之類的修飾，就直接被當成是貼標籤，其實她也有提到他有合作過很好溝通的工程師，更何況她的課程也不是溝通課，文章的受眾也不是工程師，這也讓我想到我在研究所寫論文時，有一個眉角就是不能用什麼「最好」、「全部」這種太過絕對的形容，而是要用「最好的之一」、「大部分」等比較相對一點的，因為你永遠不知道你的最好，是不是真的「最好」，或是更直接的利害關係，口試前你永遠不知道口試委員有沒有知道你沒查到的資料；當然，或許就算一開始的文字就有修飾過，也無法完全避免這件事情生，Ash 是這樣說的：
看大家討論這麼熱烈，大家在職場上真的都是傷痕累累呢。我們都是帶著過去的傷痕去跟下一段新的職涯邂逅。
-- Ash Wu (@hSATAC) May 15, 2024
有時候你覺得同事很尖銳，但他針對的可能並不是你，而是整個環境或者他的過去。
然後我才發現原來這已經是工程師的集體創傷了嗎？難怪大家反應這麼大，後來還有說到「男性說教（mansplaining）」這我就覺得不太行，不過她還提到收到的回饋是女性工程師普遍比較好溝通，所以我也實在很難說到底是什麼狀況，畢竟我不是當事人，不過確實在這個圈子要說完全沒有性別差異/問題也是不可能，只是這到底算不算是「男性說教」，我就真的很存疑了，畢竟這也沒有客觀的計量方式來判斷，畢竟我才發生過跟親近的人解釋一些事情，之後發現他完全沒聽進去，然後才了解到：「啊，我剛剛被認為是在男性說教。」
最後還是來分享點比較有趣的東西吧，Huli 趁機也重貼了一個老影片「The Expert」：
這影片其實我也很久以前就看過了，只是沒想到下面 Tzeng Yuxio 貼了另一個真正的專家完美達成上面的需求的過程：
十年前的解答我今天才看到！
同場加映：剛好昨天在 FB 的「陳名珉」粉絲專頁有這麼一篇文章，是在講傳統市場的變化，其實追根究底也是溝通的需求在哪一端的問題（海總理的那串）。
2024-05-08 17:06:12
週末帶小孩去松山菸廠意外發現到「SEE DIFFERENT 看見不同的學習風景」這個展覽，心中實在是有些想法和感觸想分享，首先先來介紹一下這個展覽吧：這個展覽其實是「第二屆教科圖書設計獎」的得獎作品，沒錯，是教科書，國中國小的教科書的設計展！而且不只是視覺上的設計，評選的範圍也包含內容的設計，展場展出的就是本屆得獎的教科書們，有一整區是可以翻閱的，只能說現在的教科書和我接觸過的三十年前左右的真的是差很多，除了更加活潑有質感的設計，還有各種清晰的圖表輔助，甚至連內文都變得很好閱讀，很像是在看科普書而不是教科書，深入了解之後，才知道這一切其實要從十年前，也就是 2014 年在 FlyingV 上的「美感細胞的教科書改造計畫」開始，其實我當年也有看到，不過我是沒什麼參與，覺得就是很理想但是很難進入體制內，沒想到，美感細胞默默耕耘十年，加上教育部推動美感教育，還真的推展開來了，教科圖書設計獎都辦到了第二屆，而美感細胞在其中的角色，除了在 FlyingV 上三季的募資計畫，後來還成立社團法人，承接一些政府合作案之外，也持續進行相關研究，發佈了不少的設計報告和參考資料，另外還有一個很重要的角色，就是作為教科書出版社和設計師之間的媒合橋樑，其實教科書的出版不是那麼容易，和一般書籍比起來限制較多，除了內容要送審之外，教育部還有印製規定。
我確實以前也是認為台灣的美感素養真的差很多，而這在各種層面上展現，從平面設計開始像是文宣、廣告設計、然後一些政府機關的公文、表單的排版字體（看過數年前香港的報稅表單，排版和字體真的是比台灣好很多）等等，更進一步到店面、商場設計（像是台北車站站前地下街 K 區的前後對比：誠品 vs 東森）、道路規劃、建築設計、年末的燈飾、街景、古蹟打燈（像是以前台北郵局）等等。台灣一來普遍不重視美感和設計，二來是設計人材也少，尤其是公部門相關的東西更是慘烈，最常被人拿出來講的大概就是國慶典禮的主視覺設計了吧，這幾年的改變確實有目共睹，終於能夠脫離千篇一律的設計風格，然後我才慢慢了解到台灣其實不是沒有設計人材，而是主政者和業主不重視，甚至可能是根據種種不能直說的原因來挑選廠商，當然這也造成了惡性循環，業主不重視、設計師沒案子、願意投入設計領域的人就少；美感細胞的三位創辦人張柏韋、林宗諺和陳慕天在十年前的教科書改造計畫第一季其實就有見到這個問題，見到這個問題的人其實應該不少，但是真的有想面對它處理它的人就少之又少，更何況三人還不是設計相關領域、還在體制之外、當時也還只是大學畢業生，實在相當讓人佩服。
另一個感觸則是體制外到體制內這件事，沒想到在這幾年內可以看到兩件事情真的這樣發生，真的是要感謝現在的主政者願意沒事找事作，這邊提到的教科書質的改變是一個，當然這只是一個手段，真正想要改變的是整體國民的美學素養，這還需要很長時間的發酵；另外一個體制外到體制內的改變，則是報稅軟體，相信這就是大家都有目共睹的了，最早是設計師卓致遠在 Join 平台上提出的，財政部注意到這個問題後也非常重視且積極，才推動了報稅軟體整個大改變，提案人卓致遠當然也不是起個頭就跑走，他也是很積極的參與協助設計改善，一些過程可以參考雨蒼在 2018 年寫的「新版報稅網站是怎麼煉成的？」，唐鳳也在其中出了些力協助溝通，當年她還是政務委員，數位發展部是到 2022 年才成立的，當然數發部的貢獻在基礎建設，所以一些新的認證方式應該也是有其貢獻才得以實現。
然後另外想提的是，美感細胞的那些研究報告內容其實都蠻不錯的，像我主業是前端工程師，但是也一直對平面設計、字體、文字排版等有些興趣，所以這些報告當中的教育字體應用指南、敎科書印製規格提議報吿、易讀設計指南 Guidebook和教材通用色彩應用指南四份我都有看過一遍，內容都蠻不錯的，都從問題和背景開始就做了很詳細的介紹，報告本身的編排和一些輔助的圖表也都弄的很清楚，可以看得出來花了不少心力要讓報告本身可以自證其述（self-hosting?）；另外還有一本在會場有展出的「翻開下一頁➝NEXT PAGE教科書風格創新趨勢研究探討」，則是以教科書近年來的變化為主題，還介紹了第一屆的教科圖書設計獎的得獎作品，這本的出版則是台灣設計研究院，也就是展覽的主辦單位，不想下載的話其實以上這幾本也都有放到 issuu 平台上，可以參考以下連結：
最後補一個 中央社 文化+ 的專題報導「聽說課本不一樣」，還有這次展覽我最喜歡的教科書封面：
