Typst 0.15：排版界的可變字型與多文件輸出終於到齊了
typst.app · 2026-06-15
Typst 0.15 在 2026 年 6 月 15 日正式釋出，這是一套以 Rust 寫成、意圖取代 LaTeX 的現代排版系統。這個版本塞進了五項功能級更新，其中任何一項單獨拿出來都夠寫一篇公告文——偏偏它們全撞在同一個版號裡。
可變字型：一個字型檔走天下
可變字型（Variable Fonts）是這次最引人注目的功能。過去要在文件裡切換粗細、寬度或光學大小，得準備多個靜態字型檔；現在 Typst 能直接讀取符合 OpenType 規範的可變字型，並依據 text() 函式的參數自動對應到對應的 variation axis。標準的 weight、width、italic、optical size 都有自動映射，進階使用者也可以透過 variations 參數手動指定自訂軸。CLI 新增的 typst fonts --variants 指令讓開發者可以快速列出字型支援哪些變體。
對於需要精細字型控制的報告或書籍排版來說，這個改動意味著字型資源可以大幅精簡。一個字型檔就能表達整份文件的所有字重變化，不再需要手動管理 Regular、Bold、Light 等多個靜態版本。
HTML 輸出終於能渲染數學式
Typst 的 HTML 輸出模式長期以來必須把數學式轉成 SVG 圖片，既無法被螢幕閱讀器辨識，複製文字時也一塌糊塗。0.15 將 HTML export 的數學渲染切換為原生 MathML，方程式變得可選取、可搜尋，瀏覽器可直接以向量方式顯示，無障礙需求也獲得滿足。這對需要發佈技術文件網站的使用者而言是真正的痛點解決。
Bundle Export：單一專案輸出多份文件
新的 Bundle Export 功能透過 document 與 asset 兩個元素，讓一個 Typst 專案能在一次編譯中輸出多個獨立檔案。舉例來說，可以同時產生 PDF 正文、SVG 圖表、以及獨立的 HTML 摘要，不必跑三次編譯流程。
document元素：將內容輸出成任意單檔格式（PDF、PNG、SVG、HTML）至指定路徑withinselector：將 introspection 範圍限縮在特定文件節點內- 需在 CLI 傳入
--features bundle旗標啟用
這個功能對多格式出版工作流程（例如同時維護印刷版 PDF 與網頁版 HTML）特別有用，單一 source of truth 一次輸出的夢想往前推進了一大步。
多份參考文獻與雙 PDF 標準並存
學術寫作者長期苦惱於 Typst 只能放一份 bibliography。0.15 原生支援多份獨立的參考文獻——引用文獻會自動找最近的後置 bibliography，若找不到則往前找最近的前置 bibliography，並以新的 group 參數控制跨 bibliography 的編號共享策略。
另一個低調但重要的更新是 PDF 輸出現在可以同時符合 PDF/A（長期保存）與 PDF/UA（通用無障礙）兩項標準，過去這兩個標準在 Typst 裡只能擇一。對於需要提交政府機關或學術機構的文件而言，這直接消除了一個常見的合規障礙。
文件本身也用 Typst 排版了
最後一個讓人莞爾的更新：Typst 的整套線上文件系統（typst.app/docs）已全面移植到 Typst 本身排版，用自己來排自己的說明書，同時也因此能輸出一份完整的離線 PDF 參考手冊。這不只是個宣傳噱頭——整套文件能跑過 Typst 編譯，本身就是一個大型的迴歸測試。
Yserver：用 Rust 從頭重寫一個 X11 Server，而且真的能跑 XFCE
GitHub (joske/yserver) · 2026-06-14
X.Org Server 的程式碼距今已超過三十年，裡面埋著大量為了相容 1990 年代硬體而存在的邏輯。Yserver 的作者決定不修改舊程式碼，而是直接用 Rust 從零實作一套新的 X11 Server，但只實作「現代 Linux 系統真正需要」的部分。
砍掉哪些東西，比留下哪些更有趣
Yserver 刻意移除了一批 Xorg 背負已久的包袱：多螢幕（multiple screens）、非 TrueColor 的顯示模式、間接 GLX（indirect GLX）、DDX 驅動 ABI、以及對 big-endian 客戶端的支援全部不在計畫內。「不支援」本身就是一種設計決策——省去這些邊緣路徑，程式碼的複雜度和安全攻擊面都同步縮小。
留下來的部分同樣不馬虎。Yserver 目前實作了 19 個主要 X11 extension，包含 Composite、DRI3、GLX、RANDR、RENDER、SHAPE、XFIXES、XKEYBOARD 等。GLX_EXT_texture_from_pixmap 在 AMD、Intel、Asahi Linux（M1/M2）、Qualcomm 平台上均已支援，這讓 Compiz 等需要將視窗內容當材質貼圖的合成器也能正常運作。
已確認能跑哪些桌面環境
光說「能跑 X11 程式」說服力不夠，Yserver 的 README 直接列出了通過測試的完整桌面環境：
- 桌面環境：MATE、XFCE、Cinnamon
- 視窗管理器：FVWM3、e16、wmaker
- 測試硬體：AMD Ryzen/RX580、Intel Kaby Lake iGPU、NVIDIA GTX 1050（專有驅動）、Snapdragon X1、Apple M1/M2（Asahi Linux）、virtio-gpu 虛擬機
- 作業系統：Linux 及 FreeBSD
快速啟動只需要幾個步驟。以 Arch Linux 為例：
sudo pacman -S just gcc seatd libxshmfence libxkbcommon libinput shaderc
just startx若要整合 lightdm 等顯示管理員，執行 just install 後將 X server 指令改為 /usr/local/bin/yserver 即可。
Rust 重寫 X11 的意義是什麼
Wayland 已經存在超過十年，理論上應該要逐漸取代 X11——但現實是大量遊戲、舊版應用程式、遠端桌面工具仍然依賴 X11 協定。Xwayland 作為橋接方案雖然可用，但繼承了 Xorg 的複雜度與潛在的安全問題。Yserver 提供了另一條路：保留 X11 協定相容性，但用更現代的語言與更乾淨的架構重新實作。專案目前以 MIT 授權釋出，測試套件使用 X.Org 的官方 xts5 與 rendercheck，回歸保護有一定基礎。距離取代 Xorg 還很遠，但作為一個概念驗證，它已經跑起了完整的桌面環境。
Kage：把任意網站打包成離線可執行檔，連 JS 都幫你拔掉
GitHub (tamnd/kage) · 2026-06-14
網站的離線保存從來不是一件簡單的事——wget --mirror 會拿到一堆殘缺的 HTML，瀏覽器的「另存新檔」對動態渲染的頁面束手無策。Kage 換了一個思路：先用 headless Chrome 把頁面完整渲染完，再把 JavaScript 全部剃掉，最後把所有資源本地化——「磁碟上的結果看起來像活的網站，但完全不執行任何程式碼」。
pipeline 怎麼運作
Kage 在內部同時維護兩個 worker pool：一個負責驅動 Chrome tab 做頁面渲染，另一個負責抓取 CSS、圖片、字型等靜態資源。URL 會確定性地對應到本地檔案路徑，這讓連結重寫可以在資源下載完成之前就先進行，不需要等待所有資源就緒再做後處理。輸出結構把 HTML 放在根目錄，所有本地化的樣式表、圖片、爬取狀態則統一放在保留的 _kage/ 子目錄。
爬取指令支援幾個實用旗標：
--max-pages、--max-depth：控制爬取規模--scroll：觸發捲動以載入 lazy-load 內容--refresh：對已存在的鏡像重新渲染- 自動尊重
robots.txt與sitemap.xml
本地預覽則用內建的靜態伺服器：
kage serve ./my-mirror/打包成三種格式，包括自執行 binary
Kage 最特別的功能是把爬下來的鏡像打包成三種格式。自執行 binary 是其中最具工程趣味的一個：整個靜態網站會被嵌入單一可執行檔，執行後直接在本機起一個 HTTP server 供瀏覽器打開，不需要任何外部相依。另外兩種是 ZIM 格式（相容 Kiwix 生態系，適合知識庫保存）以及原生桌面應用程式。
這三種格式可以從同一份鏡像跨編譯到不同作業系統，讓「在 Linux 上打包一個給 Windows 使用者用的離線文件包」這類需求變得可行。
幾個讓人安心的工程細節
中斷爬取並不會讓進度泡湯——Kage 會把狀態存到 _kage/ 目錄，重跑指令會從中斷點繼續。相同內容不論透過哪個 URL 抓到都只下載一次（以輸出路徑為 key 去重），避免重複抓取鏡像資源。打包時採用內容衍生的 UUID，所以相同的鏡像每次打包都會產生 byte-for-byte 相同的 ZIM 或 binary，方便做完整性驗證。
安裝方式支援 go install 或直接下載預編譯 binary，也提供已內建 Chromium 的 Docker image，免去手動安裝瀏覽器的麻煩。截至 2026 年 6 月，專案在 GitHub 上累積了約 1,500 顆星，MIT 授權。
原始來源：GitHub — tamnd/kage