諸君之疑，於此一覽

若您的 EPUB 含 DRM（如 Adobe ADEPT、Apple FairPlay 等），本系統因法律與技術因素無法處理。請先以合法管道移除 DRM 後再上傳。

本站只限制「轉換時間」，不限制書的大小。伺服器的 CPU 是大家共用的，如果讓一個大檔一直佔著，其他人就只能乾等；設了時間上限，大家才能輪流使用，讓更多人可以同時轉檔。
同一本書有時轉得完、有時轉不完，這是正常的。時間上限是固定的，但同時在線的人數不固定：用的人一多，每個人分到的 CPU 時間就變少，同一本書要花的時間就變長，超過上限就會中斷。所以伺服器越快、同時使用的人越少，轉得就越快；本站也已經盡量把程式效率提高了。深夜等離峰時段，比較有機會轉完大檔。
哪些因素會影響能不能轉完？
・檔案大小：其實不太影響。檔案大小不等於要處理的份量。EPUB 裡有圖片，檔案本來就大，但文字不一定多；就算同樣是 TXT，也有 Big5、GBK、UTF-8、UTF-16 等不同編碼，同一本書存成不同編碼，檔案大小就不一樣；DOCX 這類格式就更不能只看大小了。
・頁數：有影響，但跟一般想的不一樣。一本書有幾頁，是由字級決定的：同一本書用 8pt 排出來的頁數，比 22pt 少很多。PDF 要一頁一頁排版，頁數越多越花時間，所以字級越大，越有可能轉不完。（EPUB／MOBI／KEPUB 不需要預先分頁，沒有這個問題。）
・沒有章節的書：轉不完是很正常的。本系統是一章一章處理的；整本書不分章，就等於一章有整本書那麼長，得一次處理完，輕則超時，重則記憶體不夠，程式直接中止。這不是本站才有的限制：Kindle 等電子書閱讀器也是一章一章載入的，完全不分章的書對任何閱讀器都很吃力，Kindle 的製書規範甚至限制了單章的篇幅。很多人把大型 TXT 直接丟進 Kindle，結果白屏、重開機，多半就是檔案太大，或是碰到無法處理的亂碼。
轉不完的時候，可以這樣試：
・確認章節抓得到：原稿最好有「第○章」「第○回」這類標題，或是上傳前自己用 Markdown 標題（#、##）標好（請參考「為何轉檔後章節抓不對？」）。
・分成上下集：以 TXT 為例，用文字編輯器打開，把後半部選取、剪下，貼到新檔存起來，就切成兩個檔了。分兩次轉，成功率高很多。
・把字級調小（僅限 PDF）：頁數變少，花的時間就短。
・換個時間再試：深夜等離峰時段同時在線的人少，分到的 CPU 時間比較多。
如果都試過還是不行，可以在失敗畫面下載「轉換紀錄」，連同狀況到「留言板」回報。

所有原稿與處理過程中之中介檔案，皆儲存於本伺服器之 tmpfs（記憶體磁碟），以達成最高效能處理；下載連結逾 3 小時後檔案亦同時銷毀。

本系統可輸出 PDF、EPUB、KFX、MOBI／AZW3、KEPUB 與 Markdown 數種格式，各有所長。選擇前不妨先問自己：所求為長久「保存」、權且「瀏覽」，抑或日後「再編」？依此而擇，大致如下：
・PDF（最宜久藏）：版式定影封存，無論經年累月、跨越各種軟體、電子書閱讀器、手機或平板，呈現始終如一；縱使日後更換新機，亦不與原稿走樣。最適合長久保存與隨時翻閱，惟字級於排版當下即固定，無法於閱讀器縮放。
・EPUB（亦堪典藏）：響應式格式，可隨裝置縮放字級、調整行距。各家閱讀器與軟體對 CSS 之解讀略有差異，呈現或有出入；所幸 EPUB 生態進步神速，於 Android 上隨時可挑選稱手之 App，故仍不失為適合保存之格式。本站輸出者為 EPUB 3 並附「NAV＋NCX」雙目錄，新舊閱讀器皆能正確開啟（詳見後文 EPUB 版本與相容性二則）。
・KFX（新典範・宜暫覽）：Kindle 目前最新之格式，對直排之支援較 AZW3 完整，並可使用 Page Flip 翻頁預覽、於直排內文劃線加註。惟與 MOBI／AZW3 同屬 Amazon 專有格式，支援與否隨 Amazon 政策而變，宜於 Kindle 上暫覽，不宜倚為長久保存之用。須以傳輸線拷入 Kindle 之 documents 資料夾，並選用 Publisher Font，詳見後文 KFX 相關各則；轉製請至「直書 KFX」。
・MOBI／AZW3（舊式經典・宜暫覽）：專為 Kindle 而設，呈現會隨閱讀器型號與韌體版本而異；直排有時未必依原稿之式成列。較適合於 Kindle 上暫時瀏覽，不宜倚為長久保存之用；新一代 Kindle 若直排未能生效，建議改用 KFX。本站實際輸出者為 KF8（副檔名 .azw3），詳見後文「MOBI 與 KF8」相關各則。
・KEPUB（Kobo 專用）：Kobo 閱讀器之專屬增強型 EPUB，於 Kobo 裝置上有最佳之翻頁、進度與顯示體驗；然其專屬之 koboSpan 標記對其他閱讀器（Kindle、Apple Books、讀墨等）並無作用，徒增體積。若您慣用 Kobo，此為首選；餘者用標準 EPUB 即可。
・Markdown（存原稿・便編輯）：以純文字保存，結構清晰、體積輕巧，跨平台且永不過時，最適合作為原始檔案長久留存，或留待日後再行編輯修改，亦便於重製為其他格式。
一言以蔽之：欲長久保存，首選 PDF，EPUB 次之；欲於特定裝置隨身瀏覽，依機擇 KFX（新一代 Kindle）、MOBI／AZW3（舊款 Kindle）或 KEPUB（Kobo）；欲保留可再編輯之底稿，則取 Markdown。各格式更細之異同，詳見以下諸則。

PDF 版式凝固，於各裝置上呈現一致，惟字級無法調整；適用於檔案分享、列印。EPUB 為響應式，可隨裝置縮放字級，惟需閱讀器支援直排（如讀墨、KOReader、Apple Books 等）。

直排時，標點之擺位因語系而異：繁體中文（台灣）慣將句號「。」、逗號「，」、頓號「、」等置於字格正中；而簡體中文與日文之原生排版，則多將其偏置於字格之右上一隅。對習於台式排版之讀者而言，後者每每顯得突兀、難以適應。
故本系統提供「標點置中」選項，預設開啟：
・開啟（預設）：將句號、逗號、頓號等標點一律調整為置中呈現，契合台灣讀者之閱讀習慣。
・取消：保留原稿標點之既有位置，依簡體／日文原生樣態排列，不加更動。
此選項僅影響直排版面中標點之視覺位置，不更動文字內容本身。

章節辨識依文中「第○章」「第○回」「第○節」等關鍵字。若您的原稿不採此規格，可關閉「自動章節」，並於上傳前自行以 Markdown 標題（#、##）標註之，系統即依此分章。

「段落重整」用於處理「散行文字」——即每行皆以硬斷行作結、未以空行劃分段落之原稿（常見於部分 TXT、PDB、DOCX、HWP 來源）。其行為依勾選與否而異：
・不勾選（預設）：採 AUTO 自動模式。系統會自行偵測原稿之斷行樣態，若判定為硬斷行之散行文字，即自動接續為完整段落；若原稿本已分段得宜，則維持原樣、不加更動。
・勾選：強制啟動斷行接續。無論偵測結果為何，一律將行尾之硬斷行接合，以空行為段落分界重整全文。適用於 AUTO 誤判、未能正確接續之情形。
此選項僅對散行文字有意義；EPUB、MOBI 及 Markdown 等來源本已是結構化段落，故上傳此類檔案時該選項會自動隱藏。

EPUB（Electronic Publication）為國際數位出版論壇（IDPF，後併入 W3C）所訂之開放電子書標準。其骨幹實為一只 ZIP 壓縮檔，內含 XHTML 內文、CSS 樣式、圖片與描述書籍結構之元資料。歷來主要有二代：
・EPUB 2.0（2007）：內文採 XHTML 1.1，目錄以 toc.ncx（NCX，DAISY 規範之導航檔）描述。其時尚無原生直排、嵌入字型之完整規範，亦缺乏語意化標記與 SVG／MathML 等支援，於中日韓之直書排版多須仰賴閱讀器各自擴充。
・EPUB 3.0（2011，現行 3.3 為 W3C 正式標準）：內文升級為 HTML 5 + CSS 3，目錄改以 nav.xhtml（Navigation Document）描述；正式納入直排（writing-mode）、嵌入字型、Ruby 旁註、固定版式、SVG、MathML、有聲書（Media Overlays）等現代特性。本系統之直排、字型內嵌、注音等功能，皆賴 EPUB 3 之規範方得實現。
本站輸出者為 EPUB 3，且為「NAV + NCX」雙目錄版本。亦即：以 EPUB 3 之 nav.xhtml 為主目錄，同時額外保留一份 EPUB 2 之 toc.ncx。如此既得享 EPUB 3 之全部現代排版特性，又能向下相容於僅識 NCX 之舊式閱讀器，兼顧新舊、萬無一失。詳見下一則「相容性」之說明。

本系統輸出之 EPUB 同時內含 nav.xhtml（EPUB 3 之 Navigation Document）與 toc.ncx（EPUB 2 之 NCX 目錄），故新舊閱讀器皆可正確讀取目錄與閱讀順序：EPUB 3 相容之閱讀器（如 Apple Books、讀墨、Thorium、koreader 新版）會優先採用 NAV；僅支援 EPUB 2 之舊式閱讀器（如部分 Kindle 工具、舊版 ADE）則回退使用 NCX。換言之，輸出檔為「雙目錄」結構，向下相容無虞。

目前不建議，請改用 KFX 或 AZW3。Amazon「Send to Kindle」（電郵／App／網頁推送）近日政策又有更動，直排 EPUB 經其推送後又告出問題，直書版式已不可靠。本站雖曾就此微調直排 EPUB、一度得以推送（見七月之公告），然此路全繫於 Amazon 雲端轉檔器之行止，對方一改，前功即廢，非本站所能左右。欲於 Kindle 上讀直排書，請改轉 Kindle 專用格式，以傳輸線側載，不經雲端轉檔：
・KFX（新版 Paperwhite 請優先採用）：KFX 乃 Kindle 目前最新之格式，直排之呈現較 AZW3 穩定完整，並可使用 Page Flip 翻頁預覽、於直排內文劃線加註。手持新版 Paperwhite 等新一代 Kindle 者，請優先選用，至「直書 KFX」轉製即可（匯入方式詳見後文「轉出之 KFX 該如何匯入 Kindle？」一則）。
・AZW3（舊款 Kindle，或 KFX 無法開啟時）：本站輸出之 AZW3（KF8）業已內嵌直排字型與完整版式，至「直書 MOBI」轉製後，以 USB 將 .azw3 檔直接拷貝至 Kindle 之 documents 資料夾即可（詳見後文「轉出之 AZW3 該如何匯入 Kindle？為何不宜用 Calibre 或 Send to Kindle？」一則）。
・改用 PDF：PDF 為固定版式，字型與直排皆已凝固入頁，於各裝置呈現始終如一，最為穩妥省事。
字型設定：KFX 與 AZW3 匯入後，皆須於「Aa」→「Font」→「Font Family」選定「Publisher Font」，直排方能正確生效；其畫面與步驟，詳見後文「AZW3 匯入 Kindle 後，如何讓直排（直書）正確生效？」一則所附之圖。
※ 附記：Send to Kindle 乃 Amazon 自家開發之雲端服務，改版頻仍、行為時有更迭，本則所述係近時實測所見，日後或有增損。倘諸君所遇與此有異，敬請至留言板見告，當即更新。
籲請聲援：Send to Kindle 之於繁體中文直排，時好時壞、反覆無常，獨繁體中文直排市場受害尤深。懇請諸君不吝撥冗，致函 Amazon（Kindle 客服／意見回饋），具陳直排 EPUB 經 Send to Kindle 推送後無法正確呈現之問題，籲其重視繁體中文市場、穩定支援直排。人多則聲大，唯眾口齊呼，方促其正視改善。

KEPUB 是 Kobo（樂天旗下之電子書平台與閱讀器廠商）為其自家裝置量身打造之增強型 EPUB。其本質仍是一只標準 EPUB 3 容器，故與一般 EPUB 同源；差別在於 Kobo 於內文 XHTML 中另行注入專屬標記，以驅動 Kobo 韌體之進階功能：
・KoboSpan 切分：Kobo 會將內文逐句、逐段以 <span class="koboSpan" id="kobo.x.y"> 細密包覆。此乃 KEPUB 最顯著之特徵，藉以實現精準翻頁、閱讀進度百分比、停留統計、書內全文搜尋等原生體驗。
・渲染與翻頁最佳化：於 Kobo 裝置上，KEPUB 之翻頁較標準 EPUB 更流暢，分頁計算亦更準確。
・副檔名慣例：常作 .kepub.epub（藉雙重副檔名令 Kobo 以增強模式開啟，同時仍是合法 EPUB）。
與一般 EPUB 之別，及取捨：KEPUB 專為 Kobo 而設——於 Kobo 機上能發揮上述全部優勢；然其專屬之 koboSpan 標記對其他閱讀器（Kindle、Apple Books、讀墨等）並無作用，徒增檔案體積，部分裝置甚至無法正確開啟。故二者之擇，端視讀者所持裝置：用 Kobo 者宜選 KEPUB，餘者用標準 EPUB 即可。
本系統之偵測器會辨識上傳檔是否帶 koboSpan／kobo.js 等特徵而判別其為 KEPUB；含 DRM 者（KEPUB-DRM）同樣須先以合法管道解除方能處理。

Kobo 雖屬同門，然其電子紙閱讀器（Clara、Libra、Sage、Elipsa 等）與 Android 版 Kobo App 所用之排版引擎實不相同，對規格之支援遂有落差：
・Android 版 Kobo App（較新）：底層倚仗行動裝置之新式網頁排版引擎，對 EPUB 3 支援相當完整——CSS 3、直排（writing-mode）、嵌入字型、Ruby 旁註等，大抵皆能如實呈現。
・Kobo 電子紙閱讀器（較舊）：韌體內建之排版引擎年代較遠，僅較完整支援舊式規格，於 EPUB 3 之新特性則只作部分支援；若干較新之 CSS 寫法每每略過不理，致版面與 App 所見有所出入。
・UTR #50 支援不全：直排時，某字元究應「正立」抑或「旋轉九十度」，係依 Unicode 技術報告第 50 號（UTR #50，Unicode Vertical Text Layout）所定之直排方向屬性判別。Kobo 閱讀器雖已實作，惟尚不完整——部分標點、符號與拉丁字母、數字之方向判定未必合乎規範，遂有該正立者橫躺、該旋轉者不轉之憾。
本站之折衷：此二者若各自最佳化，勢必顧此失彼——專為 App 調校者，於閱讀器上必見走樣；專為閱讀器遷就者，又不能盡展 App 之長。本站既欲一檔兼容兩端，遂於輸出 KEPUB 時取其折衷：凡直排方向易生歧異之處，寧明示其式，而不倚賴閱讀器自行依 UTR #50 判斷；樣式亦盡量採兩代引擎皆識之寫法，不逞新規之能。
如此處置，於 App 上或略損些許美觀（若干處未能盡展新引擎之長），然差距甚微，肉眼幾不可辨；所換得者，乃同一份 KEPUB 於 Kobo 閱讀器與 Android App 上皆能正確呈現，毋須為二者各備一檔。

本系統可解析兩代 Amazon 行動書格式：
・MOBI（MOBI 6 / PalmDOC 系）：源自 Mobipocket，以 PalmDOC 容器封裝 HTML 3.2 子集，僅支援基本 CSS、不支援嵌入字型與固定版式，亦無法表現直排、ruby 等進階排版。常見於早期 Kindle 機種（Kindle 1–3）。
・KF8（Kindle Format 8，又稱 AZW3）：2011 年 Amazon 推出之第二代格式，內核改為 HTML 5 + CSS 3 子集，支援嵌入字型、浮動排版、固定版式、直排與部分 ruby；副檔名常為 .azw3，但仍以 PalmDB 容器（BOOKMOBI 標頭）封裝，故檔頭判別與 MOBI 同源。
兩者於本系統皆可上傳，惟含 DRM 之檔案（PalmDOC 加密欄位 enc_type ≠ 0 或 MOBI header DRM Count 有效）將被擋下，請先以合法管道解除 DRM。

皆可——無 DRM 之 KFX 業已開放上傳；本站亦能將書稿轉為直書 KFX 輸出（見文末）。KFX（Kindle Format 10，或稱 KF10）乃 Amazon 於 2015 年前後所推之第三代 Kindle 格式，今之新式機種與 Kindle for PC／App 所下載者多屬此類。
・血統迥異於 MOBI／KF8：KFX 以 CONT 為檔頭之容器封裝，內載 Amazon Ion 二進位序列化資料；而 MOBI／KF8 則為 PalmDB 容器（BOOKMOBI 標頭）＋HTML 子集。二者結構全然不同，故不可以解 MOBI 之法解之，本站遂另備一支還原器。
・排版資訊較 AZW3 完整：KFX 原生記載直排（vertical writing）、縱中橫（tate-chu-yoko）、ruby 旁註與強調點等欄位。本站還原為 EPUB 3 時將此類欄位一併映射回標準 CSS／HTML，直排版式不致於中途走失。
・兩種包裝兼收：其一為 .kfx 單一容器（Kindle for PC 下載者每每逕存為 .azw）；其二為 .kfx-zip（DeDRM 等工具輸出之 ZIP 包，因檔案挑選器不收，常有人改名為 .zip）。本站不看副檔名，只驗檔頭，縱經改名亦不誤判。
・不能處理者：KPF／KDF（Kindle Previewer 之 SQLite 中間檔）並非 KFX 容器，無從解析；含 DRM 之 KFX（整檔以 DRMION 包裝，或容器 bcDRMScheme ≠ 0）於瀏覽器端即被擋下，本站不支援、亦不會破解 DRM，請先以合法管道解除。
轉檔之路徑：凡偵測為 KFX 者，先還原為標準 EPUB 3，其後與「EPUB 輸入」完全同路——最佳化／正規化二式、繁簡轉換、自動章節、直排化俱同；輸出 PDF、EPUB、KFX、MOBI／AZW3、KEPUB 皆無不可。
輸出 KFX：除上傳之外，本站今亦能將任一書稿逕轉為直書 KFX，請至頂端「直書 KFX」轉製。所出之 KFX 為 Kindle 目前最新之格式，直排之外，並可使用 Page Flip 翻頁預覽、於直排內文劃線加註；新一代 Kindle 若 AZW3 直排未能生效，建議改用之。匯入方式與字型設定，詳見後文「KFX 是什麼？較 AZW3 有何優點？」以下諸則。

本系統輸出之 Kindle 格式檔案為 KF8（Kindle Format 8），依 Amazon 官方慣例採用 .azw3 副檔名以資識別。KF8 較舊式 MOBI 6 多出 HTML 5 / CSS 3 子集、嵌入字型、直排版式與較佳之中文排版支援，故能完整保留本系統之直排、字型族系等樣式。
使用方式：
・新版 Kindle（Paperwhite 以後、Oasis、Scribe 等）：請以 USB 連線，將 .azw3 檔直接拷貝至 documents 資料夾；切勿透過「Send to Kindle」郵件／網頁上傳，以免 Amazon 於雲端再轉檔致直排版式走樣（詳見下則）。
・舊式 Kindle（Kindle 1–3、Touch）：因僅支援 MOBI 6，未必能完整呈現本系統之直排樣式，建議改用 EPUB 搭配第三方閱讀器。
・第三方工具：Calibre、KindleGen／kindlepreviewer 雖可開啟 .azw3 預覽，惟 Calibre 之匯入或轉換會重新解析、另行產檔，將丟失本站之直排與內嵌字型；欲保留原樣，仍以「原檔拷貝」為宜（詳見下則）。

本系統輸出之 AZW3（KF8）業已內嵌直排字型與完整版式，務請以「原檔」直送 Kindle，方能原樣保留本站轉出之直排、標點與字型族系。
正確做法：以 USB 傳輸線將 Kindle 接上電腦或手機（於手機轉檔者，以傳輸線或 OTG 轉接頭將 Kindle 直連手機即可，毋須再經電腦），把 .azw3 檔直接拷貝至 Kindle 之 documents 資料夾即可，毋須再經任何工具中轉。
不宜之途：
・Send to Kindle（電郵／App／網頁）：Amazon 收檔後常於雲端自動再轉檔為其自家格式（如 KFX），過程會重新排版、改採其內建字型，致直排版式、標點位置與內嵌字型盡與本站原輸出走樣不符。
・Calibre 匯入或轉換：Calibre 之轉換引擎會重新解析並另行產出檔案，同樣會丟失本站精心處理之直排版式與內嵌字型。
一言以蔽之：欲完整保留本站之直排成果，請「原檔拷貝」至 documents 資料夾，切勿假手 Calibre 或 Send to Kindle 再轉一道，以免轉檔後與本站所出者不同。

本系統輸出之 AZW3 已內嵌具備完整直排特性之字型，惟須令 Kindle 採用書內之「出版商字型」(Publisher Font)，直排方能正確生效。步驟如下：
一、於 Kindle 開啟本書，輕觸畫面上方叫出選單，點選「Aa」進入字型與排版設定，切換至「Font」分頁。
二、檢視「Font Family」一列，若右側已顯示「Aa — Publisher Font」（如下圖），即表示正採用書內字型，直排已生效，毋須再動。

三、若未顯示 Publisher Font，請點進「Font Family」，於清單中選擇最末之「Publisher Font」，令其呈選取狀態（如下圖），返回後直排即正確呈現。務求與下圖一模一樣。

※ 切勿自行安裝客製字型。坊間自訂字型未必具備標準之直排字形旋轉（OpenType vert／vrt2）規範；一旦套用，標點與字形或無法正立、版面盡亂。判別之法：於上方第二圖中，若「Publisher Font」之下另顯示有字體名稱，通常即表示已安裝客製字體，請改回 Publisher Font。

部分 Kindle 機種或韌體對 AZW3（KF8）之直排支援尚有缺陷——縱已依前則切換為「Publisher Font」並確認無誤，仍可能整書回退為橫排。此非本站檔案之過，實乃機端韌體所限。若窮盡前法猶不得直排：
・新一代 Kindle：改用 KFX（建議）：KFX 乃目前 Kindle 最新之格式，對直排之支援較 AZW3 完整。本站可將同一書稿逕轉為直書 KFX，毋須另裝任何工具；其優點、匯入與字型設定，詳見下方 KFX 各則。
・改用 PDF（最省事穩妥）：PDF 為固定版式，直排已凝固入頁，於任何 Kindle 機種上呈現皆一致，絕無回退橫排之虞。但求直排無誤、不計字級可於閱讀器縮放者，此為上策。
・向 Amazon 反應（治本之計）：上述二者皆權宜繞道，真正癥結在 Kindle 韌體對 AZW3 直排之支援未臻完善。懇請諸君撥冗致函 Amazon（Kindle 客服／意見回饋），具陳 AZW3 直排回退橫排之 Bug，籲其重視繁體中文市場、儘速於韌體修正。人多聲眾，唯眾口齊呼，方促其正視改善。

於「轉 MOBI／AZW3」之設定中，相容輸出備有「標點修復」一檔，專為矯治舊版 Kindle 韌體直排時標點錯位之老問題。
問題根源：約於 2019 年以前，Kindle 對中文直排（直書）之支援尚不完備——無論隨附字型，抑或排版引擎之直排功能，皆有殘缺，獨少完整之「直排字形旋轉」能力。其結果是：本應隨直排立起之標點，竟被原樣保留為橫式，形同躺平、錯位 90 度；其中尤以冒號「：」與分號「；」最為顯著刺目。新版韌體已修正此弊，直排標點皆能自行正確呈現，故無此擾。
修復原理：勾選「標點修復」後，系統會將內文之冒號「：」、分號「；」逐一以特製樣式包覆，強制其於直排中正立，不再仰賴閱讀器韌體自行旋轉，藉此繞過舊機之缺陷。
如何選擇：
・舊機（2019 年以前之韌體，如初代 Paperwhite 等）：請選「標點修復」，冒號、分號方能正立顯示。
・新機（較新韌體）：直排標點已能自行正確呈現，選「正常」即可，毋須額外修補。
若不確定機齡，可先以「正常」輸出試讀一則；倘見冒號、分號橫躺錯位，再改選「標點修復」重轉即可。

KFX（Kindle Format 10，或稱 KF10）乃 Amazon 繼 MOBI、AZW3（KF8）之後所推之第三代格式，亦即目前 Kindle 最新之格式；今之新式機種自 Kindle 商店下載之書，多屬此類。本站所出之直書 KFX，較 AZW3 有下列優點：
・直排支援較完整：KFX 由 Kindle 之新一代排版引擎呈現，原生記載直排、縱中橫、ruby 注音與強調點等欄位；於新一代 Kindle 上，直排較 AZW3 穩定。
・Page Flip（翻頁預覽）：縮圖總覽前後各頁、跨章跳轉而不失原位（詳見下方「KFX 支援 Page Flip 嗎？」一則）。
・劃線與筆記：直排內文可逕行劃線、加註（詳見下方「KFX 直排內文可以劃線、加註嗎？」一則）。
如何取捨：新一代 Kindle 建議優先採用 KFX；舊機若無法開啟 KFX，再改用 AZW3。KFX 之字型設定與匯入方式，亦詳見下方各則。

新版 Kindle，強力推薦 KFX。二者皆為 Kindle 專用之格式，然 KFX 乃 Amazon 目前最新之格式，近年之 Kindle 機種與韌體多以之為本：直排之呈現較 AZW3 穩定完整，並可使用 Page Flip 翻頁預覽、於直排內文劃線加註。故凡手持新版 Kindle 者，請逕選「直書 KFX」。
AZW3 無法觀看時，也請改用 KFX。部分機種或韌體對 AZW3（KF8）之直排支援尚有缺陷——縱已選用 Publisher Font，仍可能整書回退橫排、版面錯亂，甚或無法正常觀看。遇此情形，毋須再三調整設定，請直接改轉 KFX。
何時仍用 AZW3：舊款 Kindle 若無法開啟 KFX，方以 AZW3（「直書 MOBI」）為宜；兩者皆不能正常呈現者，可改用 PDF（詳見「AZW3 於 Kindle 上始終呈橫排、直排怎樣都不生效，該如何補救？」一則）。
二者共通之事：皆請以傳輸線拷入 Kindle 之 documents 資料夾，並選用 Publisher Font。KFX 不收於 Send to Kindle，僅能以傳輸線側載。

支援。Page Flip（翻頁預覽）乃 Kindle 之快速瀏覽功能：閱讀中叫出選單，即可以縮圖總覽前後各頁，或切換為多頁一覽（如下圖），並可拖曳進度條跨章跳轉；關閉預覽即回原閱讀位置，不致失其所在。此功能為 KFX 所獨有，AZW3 側載書無之。

可以。直排內文可直接以手指拖選，選取範圍順直行延伸；選定後即可劃線（Highlight）、加註（Note）或搜尋（如下圖）。

本系統輸出之 KFX 已內嵌直排字型，須令 Kindle 採用書內之「出版商字型」(Publisher Font)，方能正常顯示。若改選 Kindle 內建之宋体、黑体、圓体、楷体等，即棄書內字型不用，標點位置與字形遂與本站所排者不符。
設定方式：於 Kindle 開啟本書，輕觸畫面上方叫出選單，點選「Aa」進入字型與排版設定，於「Font」分頁點進「Font Family」，選取清單最末之「Publisher Font」，令其呈選取狀態（如下圖）。

※ 切勿自行安裝客製字型。其理與 AZW3 同：坊間自訂字型未必具備標準之直排字形旋轉（OpenType vert／vrt2），一旦套用，標點與字形或無法正立（詳見上方「AZW3 匯入 Kindle 後，如何讓直排（直書）正確生效？」一則）。KFX 之匯入方式，詳見下方「轉出之 KFX 該如何匯入 Kindle？」一則。

KFX 僅能以 USB 側載：以傳輸線將 Kindle 接上電腦或手機——於手機轉檔者，毋須再經電腦，以傳輸線或 OTG 轉接頭將 Kindle 直連手機即可。待 Kindle 於電腦或手機之檔案管理中顯示為外接儲存裝置後，將 .kfx 檔直接拷貝至 Kindle 之 documents 資料夾，安全退出後即可於書庫中見之。
不可之途：Send to Kindle（電郵／App／網頁）不收 KFX 檔，無從推送。
匯入後，請依上方「KFX 匯入 Kindle 後，為何務必選用「出版商字型」(Publisher Font)？」一則，將字型設為 Publisher Font。

Amazon 之製書工具（KindleGen 及其後身）於產出 MOBI／AZW3 時，會悄悄將整份原始稿件一併塞入檔內——此即 SRCS 記錄（連同存放編譯資訊之 CMET 記錄）。所謂 SRCS，乃 source 之略，內容是建構此電子書所用之原始來源檔（HTML／EPUB 之壓縮副本）。
為何可以移除？因 SRCS 純為製作端之留存，與閱讀毫無干係：Kindle 裝置呈現內文時，只讀已編譯之正文記錄，從不觸及 SRCS。其存在僅供 Amazon 內部重新轉檔、或作者回溯原稿之用。對一般讀者而言，這份夾帶的原始碼形同贅物。MOBI 標頭中另有 SRCS 索引與計數兩欄位，移除時將之歸為「無」（哨兵值 0xFFFFFFFF），閱讀器即視同未含，絲毫不影響顯示與功能。
瘦身之用處：由於 SRCS 幾近完整複製一份來源，其體積往往與正文相當——換言之，未瘦身之 MOBI 動輒虛胖近一倍。剔除 SRCS／CMET 後，檔案常可縮減三、四成乃至過半，傳輸更快、佔機身儲存更省，而閱讀體驗一無所損。Calibre 之 KindleStrip 外掛、modify_epub 等工具皆行此道。

系統會自動偵測純文字檔之編碼，無須使用者指定。支援之編碼涵蓋：
・Unicode 系列：UTF-8（含 BOM 與無 BOM）、UTF-16BE／UTF-16LE（須含 BOM）、UCS-4BE／UCS-4LE（須含 BOM，即 UTF-32）。
・中日韓區域編碼：BIG5（繁體中文）、GBK（簡體中文，相容 GB2312）、Shift-JIS（日文）、EUC-KR（韓文）。
偵測流程先以 BOM 判別 Unicode 系列；其次驗 UTF-8 合法性；再以「高頻字雙位元組加分制」於 BIG5／GBK／SJIS／EUC-KR 之間擇優；最後回退至 Windows-1252／Latin-1。若檔頭符合 # 書名：、# 作者： 之 Markdown 元資料樣式，將自動以 MD 格式處理。建議仍以 UTF-8 為首選，以避免特殊字元於跨平台間出現轉碼瑕疵。

本系統之輸入端支援 .docx（Word 2007 以後之新式格式），不支援舊式 .doc（Word 97–2003）。其故有三：
・DOCX 乃公開標準：DOCX 屬 Office Open XML（OOXML）之列，本質為一只 ZIP 壓縮檔，內含以 XML 描述之文件結構；規格公開在案（ECMA-376／ISO/IEC 29500），任何程式皆可依其規範堂堂正正地解析，無涉授權之虞。
・DOC 為專有之二進位格式：舊式 .doc 係微軟自訂之二進位複合檔（OLE2／CFB 容器），內部結構原不公開，坊間解析器多賴逆向工程方得其門而入；此於版權與授權上頗有疑慮，本站不願涉險。
・逆向所得亦不完全：縱有現成之逆向實作，其對格式之涵蓋亦殘缺不全——DOC 版本繁多（Word 6／95／97–2003 各異），樣式、清單與編碼之處理每每失準，中文尤易亂碼。所得既不可靠，與其勉強收下而轉出殘篇，不如明白謝絕。
若手上僅有 .doc，該如何？請先以任一文書軟體另存為 .docx 再行上傳，最為省事：
・Microsoft Word：開啟後「檔案 → 另存新檔」，存檔類型選「Word 文件（*.docx）」。
・LibreOffice／WPS（免費）：開啟後「檔案 → 另存新檔」，類型選「Word 2007–365（.docx）」。
・Google 文件：上傳至雲端硬碟開啟後，「檔案 → 下載 → Microsoft Word（.docx）」。
倘原稿版面單純、無圖無表，亦可逕行「另存為純文字」（.txt，編碼請選 UTF-8）後上傳，同樣可為本系統所處理。

分兩點說明：
・「EPUB 轉 TXT」即今之「EPUB 轉 Markdown」：Markdown 本質仍是純文字，可視為「強化版 TXT」——同為 UTF-8 純文字，僅多了 #、** 等輕量標記。故昔之「轉 TXT」未失，只是更名為「EPUB → MD」並更為通用；且該工具之輸出格式仍可逕選「純文字（.txt）」，所得即無標記之純 TXT 檔。
・此工具僅抽取原文、不做繁簡轉換：「EPUB 轉 Markdown」只依原書原樣抽取文字。若您欲將抽出之 MD／TXT 作繁體 ↔ 簡體互轉，請改用專門之 天火轉碼；流程為先以本工具轉出 MD／TXT，再貼入或上傳至天火轉碼互轉即可。（註：本站其他格式之轉檔——PDF、EPUB、MOBI／AZW3、KEPUB——仍內建繁簡轉換，不受影響。）

Markdown 是一種輕量級標記語言，2004 年由 John Gruber 提出。其要旨在於：以最簡素之純文字符號，標註文件之結構與樣式——如 # 表標題、**字** 表粗體、- 表清單、> 表引用。書寫者無須離手操作滑鼠、無須仰賴特定軟體，於任何文字編輯器中皆可成文。
Markdown 之好處：
・純文字、人機兩讀：原始檔即便未經渲染，肉眼亦可順暢閱讀；既利於人，亦便於機器解析。
・跨平台、永不過時：本質為 UTF-8 純文字，不繫於任何專有格式或軟體版本，數十年後仍可開啟，無「檔案打不開」之虞。
・輕巧而利於版本控管：檔案極小，且因係純文字，得與 Git 等版本工具完美協作，逐行比對修訂瞭如指掌。
・專注內容、形式分離：書寫時只須關注文字與結構，樣式（字型、版面）留待轉檔階段統一賦予。
為何以 Markdown 為「正規化中轉格式」？本系統需處理多種輸入（EPUB、KEPUB、MOBI、KFX、DOCX、TXT、PDB…）並輸出多種目標（EPUB、PDF、MOBI／AZW3、KEPUB…）。若令每種輸入各自直通每種輸出，則須維護 N × M 條轉換路徑，繁瑣且易生歧異。本系統遂取 Markdown 為樞紐中介：先將任一輸入正規化為結構清晰之 Markdown，再由此單一中介轉出各式目標。如此 N × M 之難題化為 N + M——輸入端只需「轉入 Markdown」，輸出端只需「自 Markdown 轉出」，兩端各司其職、互不糾纏。Markdown 之純淨與結構性，正是擔此中樞之不二之選；繁簡轉換、章節重整、標點規範等加工，亦皆於此中介階段一併施行，確保最終各格式輸出之一致。

要訣只一句：一個井號（#）為元資料，兩個井號（##）為章節。先看一份完整範例：

# 書名：天火藏書
# 作者：無名氏

此處為簡介。書名、作者二行之後、
首個 ## 之前的文字，皆自動歸入「簡介」，列於書前。

## 第一章　緣起

正文第一段……

正文第二段……

## 第二章　燎原

正文……

規則細節：
・元資料（檔頭）：以 # 書名：○○○、# 作者：○○○ 二行起首，冒號用半形「:」或全形「：」皆可，井號後之空格有無不拘。
・多語標籤：標籤依語系而異，系統將依所用之標籤自動偵測語系：

語系	書名	作者
繁體中文	# 書名：	# 作者：
簡體中文	# 书名：	# 作者：
日文	# 書名：	# 著者：
韓文	# 서명：	# 저자：

・簡介：書名／作者行之後、首個 ## 之前若有文字，將自動歸為「簡介」，列於書前；不寫亦可，逕接章節即是。
・章節：各章以 ## 章節名 起首，遇 ## 即視為新章。章名不拘格式，「第一章」「卷一」「楔子」「後記」皆可。
・目錄：若欲於書中手動列出一頁目錄，可置 ## 目錄 一節（簡中「目录」、日文「目次」、韓文「목차」、英文「TOC」亦可）；不置亦無妨，本系統仍會依各 ## 自動生成閱讀器之書內目錄。
・子標題：### 至 ###### 為章內之子標題（h3–h6），不另起新章。其餘可用之標記，詳見後文「支援哪些 Markdown 語法？」一則。

轉檔器支援之 Markdown 標記如下：
・標題：# 為元資料行；## 為章節分隔；###～###### 為子標題（h3–h6）。
・段落：以空白行分隔。
・強調：**粗體**、*斜體*。
・清單：- 或 * 為無序清單；1. 為有序清單。
・引用：行首加 >。
・程式碼：以 ``` 三反引號包覆。
・表格：| 欄一 | 欄二 | 加分隔行 |---|---|。
・水平線：------（六個以上連字號）。
・圖片：![說明](images/檔名)，僅 ZIP 模式內含圖片時有效（.md／.txt 中之圖片標記將被忽略）。
・連結：[文字](網址)，內部連結會自動對應到同名章節。
・注音／振假名：青空文庫格式 ｜漢字《ふりがな》，僅當注音為日文假名時生效（中文書不影響）。

若欲上傳含封面、插圖之 Markdown 書稿，須將正文與圖片打包為 ZIP 一併上傳。檔案結構如下：

book.zip
├─ book.md          ← 正文（檔名建議用 book.md；放於根目錄）
└─ images/          ← 圖片資料夾（固定名稱「images」）
   ├─ cover.jpg     ← 封面（檔名 alt 為 cover 即視為封面）
   ├─ fig01.png
   └─ fig02.jpg

規則細節：
・正文檔：副檔名須為 .md 或 .txt，置於 ZIP 任意位置（建議根目錄）。檔頭前兩行須為 # 書名：○○○ 與 # 作者：○○○（或對應之簡中／日文／韓文標籤）。
・圖片資料夾：須命名為 images/（小寫），位於 ZIP 根目錄或正文同層。支援副檔名：.jpg / .jpeg / .png / .gif / .webp / .svg / .bmp。
・圖片標記：於 Markdown 中以 ![說明](images/檔名.jpg) 引用；路徑前綴固定為 images/，與 ZIP 內資料夾名稱對應。
・封面圖片：將圖片之 alt 標為 cover（如 ![cover](images/cover.jpg)），系統會自動將之提取為書籍封面；或於上傳介面另行指定封面圖片。
・圖片於純 .md／.txt：若僅上傳單一 .md 或 .txt（未打包為 ZIP），所有 ![…](…) 圖片標記將被忽略，因無附帶圖檔可解析。
建議流程：可先以本系統將既有 EPUB 「轉出為 ZIP」（含 book.md 與 images/），再以該 ZIP 為樣板進行編輯，即可確保結構正確。

坊間流通之 EPUB，其內所含圖片每每遠逾閱讀所需——動輒數千像素見方、全彩高解析，原為平板、印刷或網頁而備。然絕大多數讀者所持，實為黑白電子紙（e-ink）閱讀器（如 Kindle、Kobo、文石、讀墨等）：
・螢幕為灰階：電子紙僅能呈現 16 階左右之灰，彩色資訊到此盡失，徒佔體積而毫無所用。
・解析度有限：6～7 吋面板縱達 300ppi，可顯像素亦不過千餘見方；逾此之巨圖，閱讀器載入時仍須縮回螢幕尺寸，超出之像素全屬虛耗。
・巨圖之累：未經節制之大圖會使 EPUB 體積暴脹數倍乃至十數倍，傳輸費時、佔用機身儲存，翻至圖頁時更因解碼吃力而卡頓、延遲。
本系統之「瘦身」處理：於轉檔時自動為內嵌圖片作最佳化——將過大之圖等比縮放至閱讀器實際可用之尺度、重新壓縮以汰除冗餘資料；必要時並可轉為灰階，俾契合黑白裝置。經此一道，檔案體積往往可削減大半，而於電子紙上之觀感毫無損折——蓋肉眼於灰階小屏本就分辨不出那些被捨去的彩色與多餘像素。如此既省儲存與傳輸，復令翻頁順暢，可謂兩全。
※ 瘦身僅針對「閱讀無須之冗餘像素」，於黑白小屏之觀感無損。若您所讀為彩色平板或手機 App，且特重圖片精度（如畫冊、漫畫、寫真），那請勿使用此功能。

為避免散文中之豎線「|」誤觸 ruby 樣板，parser 依下列規則處理：凡符合 {base|ruby} 樣板（大括號包覆、中間以豎線分隔）者，視為 ruby 並完整保留原始字串；散落於行內之單一豎線則照常轉換。下表列出常見輸入與其結果：

輸入	輸出	結果
{漢字|hanzi}	{漢字|hanzi}	✅ 保留
{漢字|ㄏㄢˋㄗˋ}	{漢字|ㄏㄢˋㄗˋ}	✅ 保留（中文注音符號）
{ABC|abc}	{ABC|abc}	✅ 保留
|漢字《かな》	｜漢字《かな》	✅ 青空式（兩種都接受）
|中文《注音》	｜中文《注音》	✅ 青空式（中文注音符號）
{標題|title}，後接中文。	{標題|title}，後接中文。	✅ 保留
a|b	a|b	✅ 保留（兩側英文）
中文|英	中文｜英	非 ruby 樣板，照常轉換

簡言之：欲使用日文振假名請用青空格式 ｜漢字《かな》；欲標註中文／英文之雙語對照可用 {base|ruby}，系統將原樣保留。

目前單次僅能上傳一份檔案。

繁簡轉換之專有名詞辭典，會於每次轉換前以「新詞探勘」演算法即時建立。若仍有誤判，可於「留言板」回報該案例，系統會依此擴充辭典。

此數者實為「同源異名」，由 Google 與 Adobe 合作開發之泛中日韓（Pan-CJK）字型，同一套字型檔有兩個品牌名稱：
・思源黑體 ＝ Noto Sans CJK（無襯線／黑體）
・思源宋體 ＝ Noto Serif CJK（襯線／宋體）
「Noto」為 Google 命名，取 No more tofu 之意——消弭缺字時顯示之方框「□」（俗稱「豆腐」）；「思源」則為 Adobe 之中文命名。二者字型檔同源，差別僅在品牌標識。Noto 家族另涵蓋拉丁、希臘、西里爾等近全 Unicode 文字，志在「天下無缺字」。
黑體與宋體之別（Sans 與 Serif）：
・黑體（Sans／無襯線）：筆畫粗細均勻、收筆無裝飾，現代而清晰，宜於螢幕顯示與標題；對應日文之「ゴシック体」。
・宋體／明體（Serif／襯線）：橫細直粗、收筆帶三角狀襯線（即「頓」），具傳統印刷韻味，宜於長文正文久讀；對應日文之「明朝体」，台灣多稱「明體」，中國稱「宋體」。
授權：二者皆以 SIL Open Font License 1.1（OFL）釋出，准許免費使用、商業用途、修改與再散布，並可嵌入（embed）於 EPUB／PDF／MOBI 等文件；其主要限制為：不得單獨將字型檔案販售牟利，衍生字型須沿用 OFL，且若涉及保留字型名稱（Reserved Font Name）須另行更名。職是之故，本系統輸出之電子書得放心內嵌此等字型，俾使各裝置呈現一致而無授權之虞。
關於字重：思源／Noto CJK 各備七種字重（ExtraLight 至 Black）。本系統之宋體除常規字重（Regular）外，另提供粗體（Noto Serif CJK Bold，即思源宋體粗體）一選項；蓋宋體之細筆畫於電子紙（e-ink）等低對比螢幕上易顯黯淡，筆畫繁密之漢字於小字級下尤甚，改用粗體可增筆畫之黑度與對比，使久讀更為清晰省目。其授權同為 SIL OFL 1.1，亦可放心內嵌。

關鍵在於直排（直書）之標點需正確呈現。漢字直排時，諸多標點並非原樣直立，而須依字型內建之 OpenType 直排特性（如 vert／vrt2）作對應變換：
・須旋轉者：破折號「——」、刪節號「⋯⋯」、波浪號「～」及橫式括號等，須由橫向轉為縱向，否則會「橫躺」於行間。
・須移位者：句號「。」、逗號「，」、頓號「、」之擺位須移至字格適當之隅（參見「標點置中」一節），冒號、分號亦然。
・須換用直排專用字形者：部分引號、括號於直排另有專屬字形。
此等「字形自動旋轉、自動套用直排標點」之能力，係由字型檔本身所攜帶。倘不內嵌字型，閱讀器將改用裝置內建字型，而各家裝置（尤其電子紙閱讀器、舊式 Kindle）所附之系統字型未必完整具備直排特性，輕則標點移位失準，重則整排標點橫躺錯亂、版面盡毀。唯有將具備完整直排特性之字型一併內嵌，方能確保各裝置呈現一致而正確。
會否佔用過多空間？不致於。本系統內嵌時採字型子集化（subsetting）——僅擷取書中實際用到之字元納入，未用之字一概剔除。一部中文小說縱含數千異字，子集後之字型檔多僅數百 KB 至一、兩 MB，相較內文與插圖，所增無幾，堪稱物超所值。

目前介面僅提供字型族系切換。詳細之字級只有 PDF 排版可以調整。行距、頁邊等參數，將於下一版開放。如有急迫需求，可於「留言板」說明用途，將酌情提前處理。

PDF 為固定版式，文字大小於排版當下即烘焙入頁，事後無法於閱讀器縮放；故本系統於 PDF 轉換特設字級選項：除 16pt（預設）、18pt、20pt 三枚快捷鈕外，另備「自訂」一欄，可輸入 8 至 22 之任一整數（僅限整數，不接受小數與負數）。
A5 直排，每行約多少字？以預設 A5 開本（148 × 210 mm）為例，版面上下邊距各 56pt（其內含頁眉之書名橫線與頁腳之頁碼帶）、左右各 36pt，扣除後實際文區高約 170 mm。直排之「一行」即一直列，其字數＝文區高 ÷ 字級，茲列數檔以供參酌：
・8pt：每行約 60 字
・12pt：每行約 40 字
・16pt（預設）：每行約 30 字
・18pt：每行約 27 字
・20pt：每行約 24 字
・22pt：每行約 21 字
字級愈大，每行字數愈少、總頁數愈多，惟視讀愈省力；反之字級愈小，版面愈密、頁數愈省。
為何以 16／18／20pt 為快捷三檔？A5 為文庫本、口袋書之經典開本，最宜直排小說握讀。於一般 6～7 吋之手持閱讀器上，每行字數若低於約 22 字，則斷行過頻、語句零碎；若高於約 32 字，則一列過長、目光回掃時易失行。16～20pt 恰落於「每行 24～30 字」之耐讀區間，故取其首、中、尾，以 2pt 為級距列為快捷三檔：16pt 為一般閱讀之最佳密度，18pt 稍寬綽，20pt 則為大字版，便於年長或弱視者。
為何另開放 8～22pt 自訂？上述耐讀區間係以一般 6～7 吋小屏為準；然大開本閱讀器（8 吋以上，如 Kindle Scribe、Kobo Elipsa／Sage、文石 Note 等）螢幕寬綽，A5 頁面於其上顯示得更大，縱用較小字級，字面實際大小仍從容可讀，且每行容字更多、版面更近紙本書之飽滿。為確保此類大屏裝置亦能善用，特開放 8～22pt 之任一整數，由讀者依其裝置尺寸與視力自訂：小屏取 16～22pt 為宜，大屏則不妨下探 10～14pt，以求更密實之版面；自訂亦便於 17、19pt 等細部微調。逾 22pt 則每行不足 21 字、頁數暴增而版面鬆散，故以 22pt 為上限。
EPUB／MOBI／KEPUB 為何不必選？EPUB、MOBI（KF8／AZW3）與 KEPUB（Kobo 之增強型 EPUB，供 Kobo 閱讀器最佳化）皆屬「響應式（reflowable）」格式，版面隨裝置螢幕與使用者設定即時重排；讀者可於閱讀器上隨時縮放字級、調整行距與邊界，故毋須於轉檔時預設字級，本系統亦不提供此選項——選字級之權，逕交予讀者當下之手。

本站之線上閱讀器，可於瀏覽器中直接展讀 EPUB，直排、橫排皆宜。手機、平板、電腦，乃至電子書閱讀器所附之瀏覽器，皆可使用；Chrome、Brave、Firefox 等各家瀏覽器亦俱適用，毋須另裝 App。其介面力求簡淨，平日只留一條細窄之工具列，餘下盡歸內文：
・頂端工具列：左為「關閉」與「目錄」，中央示目前所在之章名，右為「Aa」版面設定；工具列下緣之朱色細線為閱讀進度，頁尾則標示本章之頁次（如「1 / 3」）。

・目錄：點「目錄」即展開全書章節清單，所在之章以朱色標示，點選任一章即可跳讀。

・版面設定（Aa）：點右上「Aa」展開設定面板，調整後即時生效：
　　排版：橫排、直排任選。
　　點擊：輕觸畫面左側抑或右側翻往下一頁，可依持機之手與閱讀習慣而定。
　　背景：白色、淺色、暖色、深色四種，夜讀宜擇深色。
　　字型：宋體、黑體。
　　字級：以「A−」「A+」逐級增減，目力不濟者可放大展讀。
　　行距：緊湊、標準、寬鬆三等。
　　朗讀：詳見下一則。
諸項設定只存於目前所用之瀏覽器，換機或換瀏覽器須另行設定；欲還原時，按「恢復預設」即可。

・單頁、雙頁自動切換：閱讀器依螢幕與視窗之大小，自動變換單頁或雙頁——手機直握或視窗窄小時為單頁；電腦、橫置之平板等寬闊之處，則改為左右兩頁對開，中縫以虛線相隔，頁次標示如「3-4 / 5」，展讀之感一如紙本。縮放視窗、旋轉裝置時亦隨之調整，毋須手動設定。直排諸般細節亦皆照顧：數字與年月日橫置成組（縱中橫），而電話號碼、IP 位址、斜線日期則不強合；引號依層次分作「」與『』，英文撇號則原樣保留；破折號、刪節號連貫直立；強調文字標以著重號，粗體照常；漢字之注音與日文之假名旁註（Ruby）亦依原書呈現。

可以。於「Aa」設定面板之「朗讀」一列點選「開始朗讀」，閱讀器即代為誦讀內文，讀至之處以淡朱色底標示，目光隨之而行，不致失落行次。適合眼倦之時閉目聆聽，或家務、通勤之際以耳代目。
朗讀時畫面下方另有朗讀面板，可調之項如下：
・聲音：女聲、男聲任擇，其下標示目前所用之語音。
・語速：以「慢」「快」增減，圖中為 1.5 倍速。
・音量：以「−」「＋」增減。
・暫停與關閉：面板標題旁示目前狀態（如「已暫停」）；按「繼續朗讀」接續誦讀，按「關閉朗讀」則結束。右上「×」收起面板後，右下角之圓鈕仍可隨時播放或暫停。

天火，喻其燃燒荒蕪、煉成精粹之力；藏書，喻其守護書卷、世代傳遞之意。願以此名，自勉之。