dvschultz / 99problems Goto Github PK
View Code? Open in Web Editor NEW99 Problems and e-reader rendering are all of them
99 Problems and e-reader rendering are all of them
Here’s iBooks for Mac, clipping the text: http://d.pr/i/E3Q2/1oQDpFqP
Here’s Kindle Previewer bleeding it into the margins: http://d.pr/i/HatU/4ryCsibR
Is there a known workaround? Here’s the code:
<p>You can, if you’re passionate, read the standard on the web, and it’s all piled in there, the history of pictures on computers. That’s when it becomes clear: only Photoshop’s creator Adobe can understand this thing. Here’s the list of four-letter abbreviations that are used to set the blend mode of a layer, taken straight from the standard as formatted:</p>
<pre><code>'pass' = pass through, 'norm' = normal, 'diss' = dissolve, 'dark' = darken, 'mul ' = multiply, 'idiv' = color burn, 'lbrn' = linear burn, 'dkCl' = darker color, 'lite' = lighten, 'scrn' = screen, 'div ' = color dodge, 'lddg' = linear dodge, 'lgCl' = lighter color, 'over' = overlay, 'sLit' = soft light, 'hLit' = hard light, 'vLit' = vivid light, 'lLit' = linear light, 'pLit' = pin light, 'hMix' = hard mix, 'diff' = difference, 'smud' = exclusion, 'fsub' = subtract, 'fdiv' = divide 'hue ' = hue, 'sat ' = saturation, 'colr' = color, 'lum ' = luminosity`
</code></pre>
<p>They’re like characters in a kid’s book. <em>Smud, Plit, and Diff went down to the river one day to go fishing.</em> Nestled in the code of the open-source Mac OS X image-viewer Xee there is this comment, written by a coder:</p>
<pre><code>/*
At this point, I’d like to take a moment to speak to you about the Adobe PSD format. PSD is not a good format. PSD is not even a bad format. Calling it such would be an insult to other bad formats, such as PCX or JPEG. No, PSD is an abysmal format. Having worked on this code for several weeks now, my hate for PSD has grown to a raging fire that burns with the fierce passion of a million suns.`
*/
</code></pre>
<p>The poor guy. The thing is, he’s trying to unpack decades of decisions, to make sense of them. But at this point the Photoshop format—most file formats of great age, in fact—is more like a legal document. Parts are open to interpretation. The computer is the ultimate judge, but you never know how it will rule. Later, that same open-source programmer writes:</p>
<pre><code>/*
Trying to get data out of a PSD file is like trying to find something in the attic of your eccentric old uncle who died in a freak freshwater shark attack on his fifty-eighth birthday. That last detail may not be important for the purposes of the simile, but at this point I am spending a lot of time imagining amusing fates for the people responsible for this Rube Goldberg of a file format.
*/
</code></pre>
<p>You feel for the programmer. Because if you’re going to create an image viewer you need to deal with Photoshop. But when you think about it, when you look at the way that files and programs tend to go, well, the fact that Photoshop would be a puzzle seems inevitable. Look at HTML5.</p>
orientation:portrait works. But it doesn't.
in iBooks iPad, this media query returns true with pagination turned on:
@media screen and (min-width: 560px) and (orientation: portrait) {}
but return false in scrolling mode.
When multiple images floated to the same side are placed in close proximity to each other, the "text wrap" goes wonky (got all technical there) and starts overlapping the images.
Can be fixed by placing another (non-floated) object between the offending images and using clear: both; on that. I usually wrap things in superfluous divs to achieve this.
if an <img>
is wrapped in a <figure>
tag and the figure tag has left padding on it, the image inside extends outside of its wrapper. Seems like even width: 100%
on the <img>
doesn’t work to fix it.
In iBooks 3.2 (iOS 7.1):
<a class="box" href="#x" epub:type="noteref"><span class="iconContainer"><img class="icon active" src="y.png"/></span></a>
(with the CSS workaround of issue #13 ), if the target does NOT have epub:type="footnote"
, as in:
<div id="x" class="z">
...
</div>
the popup does not appear (ok, that's reasonable), but also the <a>
seems dead, that is, the window.location is not changed to the target x
. (The target is visible.)
After touching the image contained in the <a>
, a gray flash appears behind the image, as if some event is triggered, but after that nothing happens.
iBooks supports canvas, but not drawImage
. Example to follow.
The book cover (specified with <meta name="cover">
) just shows as a tinny unreadable thumbnail in the "bookshelf". I think it should be part of the reading experience, being shown when starting to read book.
I think this might actually be an ADE issue, but I can say with certainty that the Nook tablets ignore sections of CSS where media queries and advanced CSS selectors are present:
<style>
block in an html file, that entire block is ignored.https://twitter.com/tzviyasiegman/status/444533948560191488
This is both insane from a production perspective, and the lack of documentation makes it a guessing game.
Note: this bug is actually a consequence of #49
In EPUB 3 FXL, if the body
element has the CSS property position
, its implicit width
becomes zero in Kobo iOS. As a consequence, descendants with percentage-based absolute positioning relative to the page (i.e. not contained within another element with an explicit position
property) are always placed in the top-left corner of the viewport (i.e., top: 0; left; 0;
).
An XHTML file with this markup:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta name="viewport" content="width=500, height=500"/>
<meta charset="UTF-8"/>
<title>Percentage-based absolute positioning</title>
<style type="text/css">
body{
width:500px;
height:500px;
margin: 0;
position: relative;
}
.textFrame {
position: absolute;
left: 20%;
top: 40%;
}
</style>
</head>
<body>
<div class="textFrame">
<p>Lorem ipsum dolor sit amet,<br/>consectetur adipisicing elit.</p>
</div>
</body>
</html>
displays correctly in a browser and Kobo for Mac 3.12.0 running on OS X 10.10.3, but not so in Kobo for iOS 7.4 on an iPad 3 running iOS 8.1.3 (not tested on any other Kobo app/device):
(This issue describes only the positioning bug illustrated in the screenshot. The reason why the text box in Kobo iOS, besides being in a wrong position, has its lines broken after each word is described in #49 )
Removing the body
element's CSS property position
corrects the issue in Kobo for iOS, but breaks it on desktop browsers.
You might have added position: relative
along with width
and height
in px
to the body
for the purpose of previewing such pages in a desktop browser for editing or QA purposes. Desktop browsers have windows of variable size and disregard the viewport
dimensions' declaration. Therefore, descendant elements whose dimensions and positions are percentage-based relative to the body
would not display correctly on desktop browsers, unless body
has explicit width
and height
in px
and position
. Ereaders, having fixed viewport sizes, do not need those, but having them present or not should make not difference for ereaders provided the body
CSS dimensions match those of the viewport meta tag.
Our ebook production people complained that iBooks 4 on iOS 8 would choke on the following embedded SVG:
<div …>
<svg xmlns="http://www.w3.org/2000/svg" version="1.1"
width="100%" height="100%" viewBox="0 0 1000 1594">
<image xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="images/000-0-0000-0000-0_front.jpg"
width="1000" height="1594"></image>
</svg>
</div>
Where “choking” means that once you’re trying to zoom in on that image, iBooks’ UI will freeze.
They found out that it can be fixed by moving the xmlns:xlink declaration up to the svg element:
<div …>
<svg xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1"
width="100%" height="100%" viewBox="0 0 1000 1594">
<image xlink:href="images/000-0-0000-0000-0_front.jpg"
width="1000" height="1594"></image>
</svg>
</div>
Moving the namespace declaration up to the surrounding XHTML didn’t help.
It shouldn’t matter at all where this namespace is declared, as long as the declaration is in scope when the image element is being read. This indicates that iBooks is not using a “real” XML parser.
If you’re using XSLT 2 or 3 for creating/splitting your EPUB content files, this can be achieved by copying all elements except svg with copy-namespaces="no" and explicitly adding the xlink namespace declaration to the svg element (see example ← wow, it took me less then 4 attempts to get the brackets, parentheses, link and text thing right. I’m getting proficient in this “markup” language).
XML namespaces are kind of tricky, admittedly. But what is much worse than the XML namespace complexity alone: That some applications that pretend to be XML-aware expect literal namespace declarations at certain locations. The XML might be equivalent from an XML parser’s perspective, but not for these pseudo XML processors.
in most CSS stacks, font-weight: normal
is synonymous with font-weight: 400
On the Nook HD (and maybe other ADE readers?), you must specify 400 as the font-weight.
In iBooks 3.2 (iOS 7.1), if a noteref / footnote has the following structure:
<a class="box" href="#x" epub:type="noteref"><span class="iconContainer"><img class="icon active" src="y.png"/></span></a>
<div id="x" epub:type="footnote">
<p>TextLine1 </p>
<p>TextLine2</p>
...
</div>
Once the popup opens, there is a blank space before "TextLine1", as if the noteref image was injected as the popup title, but the actual image is not displayed, nor resized as described by the icon
CSS class.
from @makeBetterEBooks here: #22 (comment)
Some more fun and games, in ADE 1.7 if multiple CSS sheets are referenced by the same HTML page, internal hyperlinks will go to the top of that HTML page, NOT the specific anchor.
Never did extensive testing, so unsure if it was the presence of multiple CSS sheets, or the fact that the second one was for mobi.
it’s possible this also affects iBooks for iOS, but it’s impossible to test without an inspector.
If you add an <img>
into a chapter without it being wrapped in a <figure>
(or div?) iBooks for Mavericks will wrap it in a <div>
, move your CSS applied to the img
to that div
and add a host of inline styles to your img
the solution is to wrap it in a div in your xhtml. this will give you more control over its styling and avoid messy inline styling:
Ordered lists that come after a heading retain a bold first numeral.
The workaround I use is:
in the html file:
<h2>Header Here</h2>
<!-- this is the key -->
<span class="mobi7only" style="height: 0%; overflow: hidden;"> </span>
<ol>
<!-- ordered list continues on here -->
(to be safe I media query the .mobi7only
class away)
note that this won’t work in some places due to epubcheck (like in nav’s where spans are not allowed).
you should use page-break-after
instead (which IS supported)
For Kindles to offer a "Go to… TOC" menu (in Kindles that have such menu at all), Kindle Publishing Guidelines (2014.2) state:
3.3.3 TOC Guideline 3: HTML TOC Must Be Referenced
To enable the customer to jump to the TOC from the Kindle menu, the OPF file must reference the TOC from a TOC guide item or the navigation html file must reference a TOC in a landmarks nav element. […]
Here is an example of a landmarks nav element for a TOC:
<nav epub:type="landmarks"> <ol> <li><a epub:type="toc" href="toc.html">Table of Contents</a></li> </ol> </nav>
While that will work for flowing layout books, for some obscure reason fixed layout books (FXL) have the additional unstated requirement that such reference has to point specifically to the toc
nav element.
<nav epub:type="toc" id="toc">
…
</nav
<nav epub:type="landmarks">
<ol>
<li><a epub:type="toc" href="#toc">Table of Contents</a></li>
</ol>
</nav>
or else the "Go to… TOC" button will remain grayed out.
Google Play will split some HTML pages at arbitrary points for "performance reasons". Breaks are consistent across devices and even across versions of the ePub.
in iBooks (iOS), SVG rendering, especially height and width sizing, is off.
Here’s what it looks like in iBooks for Mavericks
and here’s iOS. Not a CSS issue.
In iBooks (3.2, iOS 7.1) the following link does not work:
<a class="x" href="#y" epub:type="noteref"><span class="z"><img src="q.png"/></span></a>
If epub:type="noteref"
is removed, or the <img>
is replaced by just text, the link works as expected, and it shows the linked footnote in a popup.
this one only seems to occur with a lot of use of the opacity style. I have a chapter that has 20+ spans, each with a different opacity all in a row. RMSDK e-inks (like the Kobo and Nook brands) will start to render the text but very quickly display no text or crash altogether.
When using Book Proofer (available from iTunes Connect for iBooks) to test EPUB folders or EPUB documents in iBooks for iOS, entries in iBooks’ native TOC will not link to their respective document if the name of the source EPUB folder or EPUB document contains spaces.
Note that this issue has nothing to do with names of files inside the EPUB, but with the name of the zip or folder that contains the whole EPUB structure.
Tested with an EPUB 3 folder with name "EPUB 3".
Seen on iBooks for iOS 3.2 & Books Proofer 1.0.1
screenshots and explainers next week.
Kindle ignores external stylesheets in KF8 if the declaration of the link
element lacks the type
attribute, even though such is not a requirement in HTML5 (but was in XHTML1.1 and before).
i.e. This will not work:
<link rel="stylesheet" href="stylesheet.css"/>
but this will:
<link rel="stylesheet" href="stylesheet.css" type="text/css"/>
Both HTML The Living Standard and HTML5 specifications declare the attribute as “purely advisory”.
Interestingly, Kindle Previewer when in Kindle DX mode (but not in any other mode), which purportedly uses the Mobipocket variant inside the .mobi file, not the KF8 variant, does use the external stylesheet, which might imply that the bug does not apply to old Kindle devices.
If an element is first on the page but not the first element in an html file kf8 will remove its padding-top and margin-top.
When an e-reader’s palette is inverted (to white on black), images don't invert. This leaves section-separating dashes and chapter drop caps (which are usually bitmaps) looking terrible.
Obviously this should be a preference, or better still an attribute in the ebook markup (say, <img does-invert>
If in css file empty media queries exists, then ADE (tested with 2.0 and 4.0) and readers (e.g. tolino) or software (blue fire reader) with adobe engine chrashes. Here an example file:
@font-face {
font-family : "Gentium";
font-weight : normal;
font-style: normal;
src: url("../Fonts/GentiumPlus-R.ttf");
}
@media amzn-kf8
{
}
@media not amzn-mobi
{
}
Repair is naturally easy: remove the empty media queries
this apparently only pertains to non-paperwhite, 3rd and 4th gen kindle e-inks.
Update: it also apparently breaks iBooks iOS, though not nearly as bad.
Full description and files to test with here: http://epubsecrets.com/break-rendering-css-body-width-100-percent.php
This CSS:
.appendix .hidden {
display: none;
}
gives the message:
Error(parsing):E3013: More number of characters are hidden using
display:none than allowed limit. Limit: 10000 in File: … line 8
when there is a div.appendix
with more than 10,000 characters.
kindlegen 2.9 apparently stops parsing the selector at the first space. The selector pertains to some .hidden
element within an .appendix
element, and there was none such. kindlegen erroneously assumed that it applied to any .appendix
. If that’s the quality of their CSS parsing also for display then good luck with reproducing your fancy layout on the Kindle.
Removing the rule or changing the selector to, for example, .appendix.hidden
, let the message disappear.
It’s frustrating when customers ask us to fix stuff that we didn’t cause and that isn’t problematic at all in the first place.
Adobe Digital Editions 1.7.2 and 2.0.1 crash when the book's CSS uses viewport-relative sizes like vh
or vw
on certain CSS property, but not when used on others.
It crashes with either shorthands of margin
and padding
, like:
margin: 50vh 0 0 0;
padding: 50vw 0 0 0;
but not with their expanded versions:
margin-top: 50vh;
padding-top: 50vw;
I have not explored other combinations.
So tl;dr: just don't use -webkit-initial-letter
(and initial-letter
).
To sum things up, first line overflows the column width, drop cap + lines overlap.
You may solve the overlap by applying a padding-right
but then you'll be screwed when they fix this bug. Tried letter-spacing
but it seems to have no effect.
This seems to only affect non-paperwhite kindles. I will upload screenshots next week.
In EPUB 3 FXL, if the body
element has the CSS property position
, its implicit width becomes zero in Kobo iOS. As a consequence, descendants with dimensions relative to the body
(be it by having explicit percentage-based dimensions while not contained within another element of dimensions not relative to the body, or by simply inheriting their width from body
) inherit too a width of zero. In such case, text boxes break lines after each word.
An XHTML file with this markup:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta name="viewport" content="width=500, height=500"/>
<meta charset="UTF-8"/>
<title>A text box without explicit width</title>
<style type="text/css">
body{
width:500px;
height:500px;
margin: 0;
position: relative;
}
.textFrame {
position: absolute;
left: 100px;
top: 200px;
}
</style>
</head>
<body>
<div class="textFrame">
<p>Lorem ipsum dolor sit amet,<br/>consectetur adipisicing elit.</p>
</div>
</body>
</html>
displays correctly in a browser and Kobo for Mac 3.12.0 running on OS X 10.10.3, but not so in Kobo for iOS 7.4 on an iPad 3 running iOS 8.1.3 (not tested on any other Kobo app/device):
Removing the body
element's CSS position
corrects the issue in Kobo for iOS, but breaks it on desktop browsers1. Providing the text box with an explicit width
in an absolute unit (such as px
) so that it does not inherit from body
makes it work properly in both Kobo for iOS and desktop browsers.
.textFrame {
position: absolute;
left: 100px;
top: 200px;
width: 300px;
}
You might have added position: relative
along with width
and height
in px
to the body
for the purpose of previewing such pages in a desktop browser for editing or QA purposes. Desktop browsers have windows of variable size and disregard the viewport
dimensions' declaration. Therefore, descendant elements whose dimensions and positions are percentage-based relative to the body
would not display correctly on desktop browsers, unless body
has explicit width
and height
in px
and position
. Ereaders, having fixed viewport sizes, do not need those, but having them present or not should make not difference for ereaders provided the body
CSS dimensions match those of the viewport meta tag. ↩
Consider the embedded SVG code of #46. When processing it, kindlegen complains:
Warning(inputpreprocessor):W29008: Tag rejected due to improper usage: </image>
in file: /tmp/mobi-ktXBEY/OEBPS/cover.xhtml
So this is not ok:
<image xlink:href="images/000-0-0000-0000-0_front.jpg" width="1000" height="1594"></image>
While this is ok:
<image xlink:href="images/000-0-0000-0000-0_front.jpg" width="1000" height="1594" />
Unfortunately, when we are using the 'xhtml' serialization method of Saxon/Calabash, the image element within embedded SVG will be serialized with an explicit closing tag. This should be no issue when the input is XHTML with embedded SVG; an XML parser should see no difference between the two variants.
What kindlegen apparently does: Read the opening image tag as an empty HTML5 elemen that doesn’t need to be terminated by '/>'. From that standpoint, it might seem reasonable to consider the additional “tag” </image>
as misplaced.
However, as kindlegen is processing XHTML with embedded XML rather than HTML5, it should treat its input as such.
Luckily, the resulting .mobi file seems to be ok. So this warning may safely be ignored.
It is, however, a reminder that the vendors don’t just put crappy sofware into devices. They also provide crappy software for content conversion.
See this: http://apple.stackexchange.com/questions/157460/ibooks-epub3-nested-ncx-toc-isnt-working
I duplicated the problem tonight with 3 nested levels.
The GUI TOCs work as expected in Readium 2.15.2 and VST Bookshelf V6.5.2 (1923)
I've been staring at this thing for hours now. I've tried rearranging things in legal nesting ways, to no effect. The toc that displays in the book is correct, and iBooks GUI realizes that both chapters are nested, it just doesn't indent the first chapter and sections appropriately, and formats the second chapter titles as if it were a top level TOC item.
Here's what the first chapter looks like:
And here's what the second chapter looks like for comparison:
and here's the in book toc.xhtml nav:
I'm 98% sure that iBooks is pulling the GUI TOC from the NCX rather than the nav.xhtml, which doesn't make sense at all since this is an EPUB 3 book.
not entirely convinced this is a real issue, but logging here for future investigation
I have the following styles:
page-break-before: always;
position: relative;
which renders the first page with this applied to it blank in Kobo Android tablets (Arc7 HD is all I have to text on right now).
This isn’t technically a bug as the EPUB spec also doesn’t support it, but every other reader does support it.
When I load a Fixed Layout book into Google Play that's longer than 20 pages, one of the pages won't display.
The missing page moves later in the book as the book gets longer (at 21 pages, page 2 disappears, at 389 pages, page 20 disappears, at 424 pages, page 21 disappears--I haven't tried all variations in between).
It seems to be upset with the position in the playorder, not necessarily the page itself. If I move the page or duplicate the page, it appears.
I've tried a lot of stuff: removing images, fonts, html, css, re-encoding the opf and html files, rearranging the order, standing on my head, etc.
Anyone else having this issue? Or resolved it?
via @jeankaplansky
All ordered and bulleted lists are hard coded in Mobi7. There is no way to turn numbering or bullets off, or change the numbers to another numbering scheme.
I assume maybe you could solve this by wrapping it in a span with its own class?
If an SVG file contains any PNG or jpg data, that data won't display in iBooks. The workaround is to use <embed>
instead of <img>
to point to the SVG; then iBooks will read the embedded bitmap data. Other readers I've checked (Kindle, ADE, Firefox) seem to be okay with <embed>
, so no separate version required.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.