Should Ebook Font Be Indented for Better Reading
Contents
- Heading Alignment and Justification
- Body Text Defaults
- Formatting Paragraphs
- Fixed Values
- Margin and Padding Formatting
- Driblet Caps
- CSS for Page Breaks
- Embedded Fonts
- Customizing Font Selection
- Page Number Guidelines
- Enabling Existent Page Numbers
- Footnote Guidelines
- MathML Support
Heading Alignment and Justification
Because text in reflowable eBooks is fully justified past default (i.east., text-align: justify;), Amazon strongly recommends specifying the appropriate CSS alignment for all headings to prevent excessive spaces between words (i.e., text-marshal: left; text-align: correct; text-align: center;).
Body Text Defaults
The trunk text in a reflowable Kindle book (fiction and nonfiction) must be all defaults. Amazon encourages content creators to use creative styles for headings, special paragraphs, footnotes, tables of contents, etc., simply not for body text. See details on using embedded fonts. The reason for this is that whatever styling on body text in the HTML will override the user's preferred default reading settings. Users report such beliefs every bit a poor reading experience. Hither are the nigh important points:
- The trunk text font should be set in the CSS using the font-family attribute. Body text must use the default font size (1em) and line height. Body text should not use the <font size="…"> tag or the font-size and line-acme attributes in CSS.
- Trunk text should not exist primarily bold or italicized. Selected parts of the text tin can be assuming or italicized for emphasis. This guideline only prohibits a book from being entirely bold, for example.
- Trunk text should not have an imposed font color throughout the book. If you adopt to apply imposed font color in some sections of your book, practice not use likewise light or too night a color. Lite colors will not display with enough dissimilarity on devices set to white backgrounds or on E-reader devices. Nighttime colors volition not display well on devices set to blackness backgrounds. See the W3C recommendation for maintaining a readable dissimilarity ratio between text and background colors. For grays, utilize colors within the hex value range of #666 to #999.
- To determine if a color falls within this range, utilize a tool to catechumen your color to RGB values. Enter the resulting three numbers into the following formula: Y = (0.2126 * R) + (0.7152 * G) + (0.0722 * B). If the value of Y falls inside a range of 102 and 153, this color volition create a good client experience beyond Kindle devices and applications.
- Body text must non have a blackness or white background color. Customers report this as a bad user experience because information technology tin can create an awkward, indigestible reading experience when the device background is set to a different color and because the text can become invisible when a user changes the groundwork colour setting on their device and the font color automatically inverts.
- Torso text should non take a forced font face up. Brand certain that you have followed the guidelines for embedded fonts. Not following these guidelines could pb to customers not having the power to change their preferred reading font.
- Body text must non employ non-breaking spaces in place of normal spaces in between words in paragraphs.
- Torso text must not have an imposed left/right margin or padding throughout the book. If at that place are paragraphs that practice require left/right margin to differentiate them visually from body text, such as a recipe list or a cake quote, margins applied to these sections should be specified as percentages rather than ems or point values.
- The post-obit font fixes volition exist applied in during the upload process:
- The font size used in the bulk of the content will be normalized to 1em.
- The font-family used in the majority of the content will be moved to the root tag (body text).
- Forced font colors used in body text will be removed and then the user may change the color of the text.
Formatting Paragraphs
For body text, either indents or extra line spacing must be used to distinguish paragraphs for customers. Amazon recommends using the text-indent attribute in the CSS to ready indent values of no more than 4 ems for body paragraphs. To change the infinite before or after each paragraph, use the margin-meridian or margin-bottom styles respectively in the CSS. We recommend using em values for these attributes. Never use the height belongings to control the size of elements containing text or instances of overlapping text may occur in your book. The height property should only ever exist applied to images in reflowable books.
Fixed Values
Avert using fixed values such as points and pixels for CSS backdrop such as font-size, width, height, margin, padding, and text-indent. To enable rendering across diverse screen sizes and resolutions, specify these values in ems or percentages.
Margin and Padding Formatting
When using left or correct margin and padding CSS properties, specify the values in percentage (%) instead of em units. This ensures that the margins practise not grow also broad with large font sizes and impair reading. Margins should exist assigned values of 0 or greater to keep content from falling off the border of the screen or overlapping other content. E'er set left and right margins to 0 for normal trunk text to permit users the full range of margin selection using device defaults. Elevation/lesser margins should be specified in ems and then that spacing between paragraphs is easily distinguishable at whatsoever font or device size.
Drop Caps
Elements such equally drib caps should be specified using percentages or relative units (positive or negative) instead of fixed values such as points and pixels. The acme of the drop cap should be aligned with the body text. To create drib caps, Amazon recommends using the post-obit sample CSS:
Example:
p.para {
font-size: 1em;
margin-lesser: 0;
margin-top: 0;
text-align: justify;
text-indent: 0;
}
@media amzn-kf8
{
bridge.dropcaps
{
font-weight:normal; font-size:320%; bladder:left; margin-peak:-0.3225em; margin-lesser:-0.3245em;
}
}
@media amzn-mobi
{
span.dropcaps
{
font-size:3em; font-weight: assuming;
}
}
<p course="para"><span class="dropcaps">T</bridge>his is a sample.
To verify that the driblet caps display equally intended, exam the book. The post-obit is an example of a driblet cap formatted using this method in a book with Enhanced Typesetting:
 Small font setting |  Big font setting |
CSS for Page Breaks
Kindle now supports CSS attributes for folio-break-inside:avoid and interruption-within:avoid. This allows publishers to group elements together so they practice not break beyond pages. Utilise cases include images with captions and headlines with paragraphs you want to continue together in your pattern.
In addition, Kindle supports CSS for folio-break-after and pause-after likewise equally folio-break-before and break-before, which tin can be used to avert page breaks before and after specified containers or blocks. Kindle looks at these properties to determine if page breaks need to be prevented betwixt or within elements. Values for these attributes are :avoid, :machine, and :always.
Using Embedded Fonts
Kindle supports embedded fonts within the eBook. These fonts can be either Open Type (OTF) or True Type (TTF). Kindle does non recommend the employ of Blazon 1 (Postscript) fonts. To provide Kindle customers with the best possible reading experience, reflowable books that apply Blazon 1 fonts are rendered using Kindle fonts by default. On KF8-enabled devices and applications, customers have the option to turn publisher-provided fonts on or off.
It is the responsibility of the publisher to secure the appropriate license rights for fonts. Unless embedded fonts are necessary to convey intent, Amazon recommends using the default set of fonts installed on Kindle devices and applications considering they accept been tuned for high quality rendering.
When choosing a font, consider usability for readers with moderate vision impairments. Choose a simple, clear font which will dissimilarity well against all tablet and Due east-reader backgrounds.
Accessibility tip: Thin fonts are harder to read and can affect the perceived contrast of the text with the background. Amazon recommends fugitive thin fonts for the torso text of your manuscript.
Kindle too supports a monospaced font. Content in the following tags will exist rendered in monospaced font: <pre>, <code>, <samp>, <kbd>, <tt>, <font face="courier">, <font face="monospace">.
With the exception of <pre>, the tags listed to a higher place do not change the text align
Customizing Font Pick
The main or main font in a book should be prepare at the <body> level. If y'all prefer to utilize boosted text styling such every bit bold or italics, ensure that the styles are attack the text rather than the font then that any font that the client selects correctly displays these styling elements. Beneath are examples of both correct and wrong implementation of customizing fonts in a Kindle book.
| Incorrect HTML Code | Correct HTML Lawmaking |
| |
The same behavior can be achieved past using CSS classes as shown below.
| Wrong CSS Code | Correct CSS Code |
| |
When coding fonts, make sure that HTML tags are closed correctly to avoid an override conflict. When there is an override disharmonize, the font files inside the book will be intentionally removed to provide Kindle customers with the best possible reading experience when they select the font settings.
For case:
| Wrong HTML Lawmaking | Correct HTML Code |
| |
| Wrong CSS Lawmaking | Correct CSS Lawmaking |
| |
Page Number Guidelines
Kindle books practise not e'er map straight to page numbers in physical editions of the book. Even if the Kindle Real Page Numbers feature is activated in the Go To menu, references to folio numbers within the eBook should be handled as follows:
- Table of contents (ToC): If there are folio numbers in the print source's ToC, they should be removed in the digital conversion. The name of the department should be retained and hyperlinked to the relevant location in the eBook. For instance, if a print source ToC displays the entry "Affiliate 1 ... P. 36," then the eBook should only display "Chapter 1" hyperlinked to the correct digital location.
- Internal links: If there is text that refers to another page in the eBook, such as "meet page XX", this text should exist linked to the relevant paragraph within the eBook.
- Index: Every page number in the index should be linked to the relevant paragraph in the eBook (or the relevant illustration, table, or nautical chart).
- Links within index: If in that location is an entry that references another section of the index, such as "see also 30", this text should be linked to the relevant department within the alphabetize.
Enabling Real Folio Numbers
Readers savor page numbers because they are a familiar method of navigation and allow readers to coordinate reading with their peers who use print versions, such as in a classroom or volume club. Authors and publishers can include Amazon's Existent Folio Number feature in their Kindle books past adding page numbers in the EPUB, which are displayed on Kindle devices and applications.
Publishers should map the Real Page Numbers in the eBook to the print edition (hardcover, paperback, etc.) that most closely matches the eBook and provide that ISBN in metadata as described in http://kb.daisy.org/publishing/docs/navigation/pagelist.html#desc. At this fourth dimension, Real Folio Numbers cannot exist previewed in Kindle Previewer or past sideloading, but they are visible when your eBook is published and are mentioned on the detail page.
To support the Existent Page Number characteristic:
- EPUB 3: Follow the EPUB 3 accessibility guidelines for folio numbers.
- EPUB 2: Follow the NCX requirements in OPF ii.0 department 2.4.1.two.
Additional notes:
- Simply employ Roman or Arabic numerals for adding folio numbers. (Example: i, ii, iii, etc. and/or one, 2, iii, 4, etc.)
- Practice not add boosted text such equally "Folio" in the proper name aspect of the pages tags (Example: "Page 1", "Page 2"). Kindle adds the word "Page" in front of the page number attribute by default.
- Make sure there are no duplicate HTML locations referenced as different pages.
- Make sure there are no duplicate folio labels referenced equally different HTML locations.
- Make sure there are no empty page labels (fifty-fifty for blank pages).
- Make certain there are no anchors without proper targets.
- Make sure that all paths to the HTML pages are relative.
Footnote Guidelines
Amazon strongly recommends marking footnotes with the HTML5 bated element, together with the epub:type attribute. This allows accessible reading systems to ignore the footnotes except when followed by their referents and allows any reading system to handle them more intelligently (due east.grand., every bit popups). This usage ensures that even if the EPUB semantic is not recognized, the notes will however be treated equally secondary content due the nature of the HTML5 aside element.
Regardless of whether the aside element is used, Amazon requires formatting footnotes with bidirectional hyperlinks (the text is linked to the footnote and the footnote is linked back to the text). This makes it easier for customers to render to the text after viewing the footnote. On some Kindle devices, such equally Kindle Paperwhite, footnotes with bi-directional hyperlinks are displayed in a pop-up.
For a meliorate reading experience, Amazon strongly recommends placing the footnote text at the stop of the chapter or volume.
Define footnotes using either of the following methods:
Method one (preferred):
<p>This footnote example uses the aside element with the epub:type attribute and bi-directional hyperlinks.<sup><a id="source" href="#ft-1-one" epub:type="noteref">ane</a></sup></p> ... <bated id="ft-1-1" epub:type="footnote"> <p><a epub:type="noteref" href="#source">one.</a> This is the footnote text, which should be placed at the terminate of the chapter or book.</p> </aside>
Method 2:
<p>This footnote example uses bi-directional hyperlinks only. <sup><a href=>footnotes.html#fn1" id="r1">[2]</a></sup></p>
...
<p id="fn1"><a href="chapter01.html#r1">2.</a> This is the footnote text, which should exist placed at the finish of the chapter or book.</p>
If your book includes footnotes or endnotes without numbers or symbols, Amazon recommends creating a unmarried link from the notation to the relevant text in the book.
Instance:
<p>This instance describes an <a id="fn1"/>event that happened.</p>
...
<p><a href="chapter01.html#fn1">event that happened</a> This is the endnote text, which provides a reference for the details of the event.</p>
MathML Back up
Enhanced Typesetting supports MathML.
Supported Tags:
| maligngroup | mrow |
| malignmark | ms |
| math | mspace |
| menclose | msqrt |
| mfenced | mstyle |
| mfrac | msub |
| mi | msubsup |
| mlabeledtr | msup |
| mmultiscripts | mtable |
| mn | mtd |
| mo | mtext |
| mover | mtr |
| mpadded | munder |
| mphantom | munderover |
| mroot |
Unsupported Tags:
| annotation |
| maction |
| mglyph |
| mlongdiv |
| msgroup |
| mstack |
| semantics |
Troubleshooting:
Open the HTML page with MathJax. If MathML is displayed without any problems, and then it will exist supported in Enhanced Typesetting.
Source: https://kdp.amazon.com/en_US/help/topic/GH4DRT75GWWAGBTU
Belum ada Komentar untuk "Should Ebook Font Be Indented for Better Reading"
Posting Komentar