一千萬個為什麽

搜索

在ePUB和Kindle電子書和@page規則中設置邊距



我目前正在創建一個ePUB3文件來將其轉換為Kindle格式,並且與其他支持epub的電子閱讀設備兼容。

我註意到一個我正在用來幫助我練習的無DRM epub書籍的css文件中的指令。它是這樣的

@page { margin: 5px !important; }

經過測試後,它似乎用於在頁面上添加頂部,底部,左側和右側空白處。但似乎(從我在KindleGen上轉換時得到的消息),Kindle不支持這一點。我是否應該將它保留在我的ePUB css文件中,同時轉成kindle希望KindleGen忽略它?此外,kindle頁邊距必須單獨指定,否則kindle設備會使用內置設置自行工作。除此之外,您認為在@page指令和其他設備中設置的最佳邊距(頂部,底部,左側和右側)值是什麽。

轉載註明原文: 在ePUB和Kindle電子書和@page規則中設置邊距

一共有 2 個回答:

不少渲染引擎實際上都在考慮@page。其他人喜歡iBooks或Kindle忽略它用默認值覆蓋為身體設置的邊距值。

我可以確認@page在Adobe Digital Editions中運行良好 - 有些但不是全部使用Adobe RMSDK的應用程序+設備。

總結一下,您可以使用它為每個頁面/窗口/屏幕設置頁邊距,而為主體設置的頂部和底部頁邊距僅應用於每個新(x)頁的第一頁(頂部)和最後一頁(底部) HTML文件。

關於價值觀,不要在我們這個可回流的世界裏把它們放在時間裏。您越會增加字體大小,這些邊距也會增加得越多。

無論你做什麽,Px和Pt都將保持不變。

% will remain the same and be interpreted as % of screen, which is the most "reflowable-compliant" choice in theory. 3% of a phone screen < 3% of a tablet screen < 3% of a computer screen.

JohnLepic is quite right that some devices ignore @page while others accept it happily. Because of this, I find it's best practice to use a small @page value if I use one at all—it doesn't make sense to design around a feature that may or may not be supported, after all. I generally go for 5px; all around.