dvschultz / 99problems Goto Github PK

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>

iBooks completely ignores attributes in an element, instead showing the image a it's full pixel size, or as large as it can be given the width of the current view.

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:

• if a media query/CSS selector is in a linked CSS file, the entire CSS file will be ignored.
• if a media query/CSS selector is in a <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.

iBooks frequently (but not universally) moves floated elements such as drop caps out of position when they fall immediately after a pagination-generated page break. The misalignment resolves if you change font settings such that the float no longer falls at the top of the page.

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 bodyelement'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.

it looks like iBooks for Mavericks will always return true when using min-widths:

@media only screen and (min-width: 1025px) {
    p {
        color: blue !important;
    }
}

that will turn all of a page’s text blue even when the application is very narrow.

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;">&#xa0;</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)

KF8 file containing ol that reaches double digits renders with no issues on most Kindle platforms. Kindle Fire cuts off the first numeral of double digit list item. Attached screen is from Previewer, but same happens on device. I have not done much of anything to attempt a resolution.

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.

On Nook and ADE, if you have a floated element next to running text that has borders, the text will flow around the floated element but the border will not

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.

Without section {height: 100%;} (where the section element wraps all text):

With section {height: 100%;}:

(notice the cropped text at the top. Not shown here is that 75% of the text here was on the previous page as well.)

(These are Kindle Previewer screens, but they accurately reflect the issues on Kindle Fires as well).

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 browsers¹. 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;
}

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.

I mistakenly applied an invalid style to text in an EPUB

p.graph3 {
    opacity: #999999;
}

p.graph4 {
    opacity: #cccccc;
}

this caused the text to render as opacity: 0 rather than just ignoring the CSS style as it should do.

This is fixed in the ADE4 Beta.

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.