Broken characters in iBooks

[Quoth]

Originally Posted by AntoniDol

I chose a fixed size of 1200 x 768 and created verso and recto containers for the pages and I pasted the figures and text into those containers. The book looks fine in every reader I've tried, including Thorium and ADE. Readers deny enlarging fonts for FXL e-books.

I bet your screen is bigger than 800x600, 1366x720, 1024 x 768 and is either 1920x1080, 1920 x 1200 or 2K or 4K and 15″ or larger? Do you mean 1200 x 768 or portrait 768 x 1200? If so you are viewing on 2K or 4K screen if at 100% zoom. Won't work on a 1920 x1200 unless there is no window (full screen projector/presentation mode).

Readers on a desktop are only to preview TOC, links etc. Real testing is on phones, tablets and dedicated ereaders. No one reads books etc on a laptop or desktop it they have an alternative.
We test new styles / layout on a 4.3″ Android phone (Aldiko), 5″ Sony 800x600 ereader, Kindle Keyboard 3 (6″ 800 x 600, mobi/KF7 and azw3), Kindle DXG (9.7″ 150 dpi Mobi only limited fonts), Kindle PW3, Kobo 7″ & 8″, Android eInk KOReader 6.8″, Android Lithium & Pocketbook on 6″ & 10″. Testing of new ebook content using existing styles is only done on Calibre Viewer (for TOC and links) and on an 8″ Kobo Sage (used to proof & annotate).
We don't do kids picture books or Graphic novels or Comics so no fixed Layout. One text book was done in epub2, and was OK converted to mobi and azw3.
I've done one family history as reflowable epub2.
We take final proofed content for epub and reformat the wordprocessor source for desired size paper and export that as PDF.

[AntoniDol]

8...

9...

10.

Here are some answers to your barrage of question...

You couldn't have set the precise display parameters for the screen to be used, right?
I've created this FXL e-book as a landscape 1200 x 768 px with a spread of two 600 x 768 pages.

And how did you set the pixel offsets, for the words?
The reader determines the flow of the words in the verso and recto containers. I don't set any pixel offsets for words.

So, I am not sure how you actually designed that, to be FXL, without taking into account all the various parameters?
The layout is fixed on 1200 x 768 px, the text and figures are in the verso and recto containers a paragraphs in chapter and section containers. The images are figures with a figcaption.

Did you size it by the clients custom requirement, to a specific screen and reader?
The client requested a FXL e-book. I determined the size of the layout. It is not sized to a specific reader.

Do you design for an iOS full-size iPad? A Mini? What about a Nook? Color Nook? Nook Color HD? Droid tablet? Phone?
It is not sized to a specific reader. It's tested on my Windows laptop with Sigil, Calibre, ADE en Kindle previewer 3, the clients mac and on my Sony phone with Kobo Android app.

What about every "reader" out there, that resizes itself to fit a screen of (whatever) size? How can that even remotely work?
From what I can see, the readers all padd any remaining space to black or white when the aspect ratio does not match.

Sure, you can create text boxes--but how do you know if the box will work in environment X?
I can imaging the verso and recto page containers don't work on every environment, but I'm conviced it will work on most modern readers.

How the hell can the thing work, unless all the text--all of it--is images of text, not real text?
I can assure you the text is "real text" and the images are "real" images.

But also it probably can be done reflowable. It's not a graphic novel.
Better still: I've done the book reflowable first, because I did not see a need for FXL. And it worked. It still works when I swipe through it.

I’m not sure what aspects of the book require fixed layout?
As mentioned earlier, the issues were: the figcaptions in figures not sticking with the images, "hero" - images not visible next to chapter openings, images not bleeding of the sides of the pages, chapters not starting on recto pages, no running headers or pagenumbers. These are not my requirements, but the clients'.

So, in other words, the client didn't understand eBooks, resisted all attempts at client education and basically wanted an ePDF, but instead, got this?
I assume that when you discussed this with her, you disclosed everything--what works in reflow, what doesn't.

The client already provided me with a PDF of the printed book. The client wanted a FXL e-book and got that. It looks similar to a PDF, but it is an ePub3 e-book.
I delivered the flowable layout e-book first and educated on how e-books did not have verso and recto pages, no page numbers, no running headers and such. The client requested a FXL e-book anyway.

But you undertook the job anyway? And made a fixed-layout ePUB, from scratch, it seems, even though generally speaking, that doesn't work?
I created a FXL ePub3, starting from a InDesign export, but reworked it the way I needed it to be. In my view the e-book works just fine (apart from the glitches in iBooks).

You warned her, you told her that you couldn't guarantee that it would work across the spectrum of devices, right? She understood that she was taking that risk?
The client understood the risk involved. It did mention the danger of getting tiny text on small screens. l wouldn't have been paid if I hadn't deliver the FXL e-book.

Well...you say it's successful, but it's not even working in iBooks, which is the most forgiving, the most supportive, of fixed-layout.
For me, iBooks is the sole reader giving problems. Even the Kindle version is looking fine, which is normally the worst PITA as far as I'm concerned.

This isn't from INDD, right, so you don't have the expectation that it should work in iBooks.
I created a FXL ePub3, starting from a InDesign export, but reworked it the way I needed it to be. It's not a one-on-one export from InDesign.

Does it work on a NookHD? What about a Droid tablet? What happens on other devices? Kobo?
It's tested on my Windows laptop with Sigil, Calibre, ADE en Kindle previewer 3, the clients mac and on my Sony phone with Kobo Android app.

Can you elaborate on which real devices you tested, rather than readers?
Devices this book is tested on are a Sony phone with Kobo Android app and a Samsung phone with Kobo Android app, my laptop and the clients mac

I bet your screen is bigger than 800x600, 1366x720, 1024 x 768 and is either 1920x1080, 1920 x 1200 or 2K or 4K and 15″ or larger?
The second screen on my laptop is 1280 x 1024. The laptop screen is 1366 x 768. Indeed, the chosen dimension fit on both my screens and the clients screen.
The resolution of my Sony 10 plus phone is 2520 x 1080.

Do you mean 1200 x 768 or portrait 768 x 1200?
The e-book is landscape 1200 x 768, containing spreads with two pages of 600 x 768 px.

Readers on a desktop are only to preview TOC, links etc. Real testing is on phones, tablets and dedicated ereaders.
The e-book is tested on two phones and two computers. No tablets an no dedicated e-readers.

We test new styles / layout on ...
I would love to test this e-book on those devices as well. Alas, I don't have access to any of those. I did test with the devices I do have access to.


Well, It's so nice to be a new member on this forum. I feel very welcome here. All that attention...

Can we get back to normal and try to answer the question in the title? Why is iBook creating those glitches, so I could try to mitigate that issue, in stead of answering to these allegations?

[AntoniDol]

FWIW: the book can be seen here: https://antonidol.nl/diensten/portfolio/

[Doitsu]

Originally Posted by AntoniDol

Can we get back to normal and try to answer the question in the title? Why is iBook creating those glitches, so I could try to mitigate that issue, in stead of answering to these allegations?

IIRC, iBooks/Apple Books supports a couple of custom .opf parameters for defining viewports etc.
For example:

<meta property="ibooks:respect-image-size-class">class</meta>

Have you checked the relevant sections in the Apple Books Asset Guide? (Search for the ibooks: prefix.)

Without seeing the actual code, it'll be hard to troubleshoot this problem.
Can you upload a sample of the book that illustrates the problem?
(You can use the Borkify ePUB plugin to anonymize the text.)

[AntoniDol]

The "problem" is visible in the first post of this thread

I have inserted every layout relevant code I could find, but not sure iBooks is there... I'll have look.

[Doitsu]

Originally Posted by AntoniDol

The "problem" is visible in the first post of this thread

Yes, but it could have been caused by any number of problems, which can only be fixed with access to a sample of the book.
For example, you didn't mention which font(s) you've embedded and what styles you've used. (Some fonts are known to have rendering issues.)

[KevinH]

If it helps, on different operating systems some os specific tables in the font file can be used, so there are times when a font can be "broken" on Windows but pass all font tests on Linux/macOS and visa-versa, although admittedly this is probably rare nowadays.

[AntoniDol]

Originally Posted by Doitsu

Without seeing the actual code, it'll be hard to troubleshoot this problem.
Can you upload a sample of the book that illustrates the problem?

Actually, I cannot, because the problem is not visible in code: the text looks fine in all readers and devices I've tested with. This only appears on the clients mac using iBooks.
I can show you the beginning of the OPS, the (borkified) paragraph with the problem and the fonts and paragraph declarations in the stylesheet.

<?xml version="1.0" encoding="utf-8"?>
<package version="3.0" unique-identifier="bookid" prefix="rendition: http://www.idpf.org/vocab/rendition/#" xmlns="http://www.idpf.org/2007/opf">
  <metadata xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:opf="http://www.idpf.org/2007/opf">
    <meta content="true" name="fixed-layout" />
    <meta content="landscape" name="orientation-lock" />
    <meta content="1200x768" name="original-resolution" />
    <meta property="rendition:layout">pre-paginated</meta>
    <meta property="rendition:orientation">landscape</meta>
    <meta property="rendition:spread">none</meta>
    <meta content="width=1200, height=768" name="viewport" />
    <meta property="ibooks:specified-fonts">true</meta>
    <dc:description>...</dc:description>

  <body id="Intro02" xml:lang="nl-NL">
	 	<div class="viewportContainer">
			<div class="versoContainer">
				<div class="sectionContainer">
					<p> In iee-a un*de-a*re-a kest ston*dee-a nog wet do*zee-a ge-a*foold met meer*de-a*re-a dia- ie-a film*do*zee-a: Hon*der*dee-a dia’s ie-a tiee-a*tel*lee-a films foon de-a for*ma*tee-a icht mil*li*me-a*ter ie-a soo*per icht mil*li*me-a*ter.  Bork Bork Bork! De-a*ze-a hoe-a*feel*heid ma*te-a*ri*iel hed na*toooor*lijk te-a ma*kee-a met het be-a*roep foon Boy, det foon jooor*na*list.  Bork Bork Bork! Het wes oook te-a doon*kee-a ioon zijn ie-a*thooo*si*is*me-a foor de-a fo*to*gra*fie-a ie-a de-a film*koonst</p>
		 			<p>We-a kee-a*dee-a fe-a*le-a dia’s ie-a films foon oon*ze-a fa*mi*lie-a*bij*iee-a*kom*stee-a weer Boy ze-a fer*toon*dee-a.  Bork Bork Bork! We-a dech*tee-a fe-a*le-a fer*ha*lee-a te-a kee-a*nee-a, woont oon*ze-a fa*der wes tee-a*slot*te-a iee-a woon*de-a*lee-a*de-a ie-a*cy*clo*pe-a*die-a die-a oofer foon il*les in geoo*ree-a ie-a kleoo*ree-a kon fer*tel*lee-a.  Bork Bork Bork! Feel kon hij fer*tel*lee-a, feel is oofer hem te-a fer*tel*lee-a.  Bork Bork Bork! </p>

/*fonts*/
@font-face {
	font-family:"Warnock Pro";
	font-style:normal;
	font-weight:normal;
	src: url("../font/warnockpro-regular.otf");
}
p {
	font-family:"Warnock Pro Light", serif;
	font-size:1.0em;
	font-weight:300;
	line-height:1.2em;
	text-align:justify;
	text-indent:15px;
	-epub-hyphens: auto;
	hyphens: auto;
	widows: 2;
	orphans: 2;
}

Hope this helps

[Doitsu]

Originally Posted by AntoniDol

Actually, I cannot, because the problem is not visible in code:

Unless it's a font issue, the problem is definitely caused by the code and you're only providing piecemeal information. For example, you've only provided the paragraph style, however, the appearance of the paragraphs is also controlled by the viewportContainer, versoContainer and sectionContainer classes, which are missing. Moreover, you're using ems instead of pixels, contrary to the Apple Books Asset Guide recommendations.

Originally Posted by Apple Books Asset Guide 5.2.13

Using Fonts in Fixed Layout Books

Fonts are defined in the opf and CSS just as in Flowing Books. In addition to the font recommendations in Fonts, the following apply to working with fonts in Fixed Layout books:

Use pixels instead of ems for the font-size.

Text placement should be specified in pixels.

Do not use fractional measurements for letter spacing, font size, and text placement. An example of a fractional measurement is 5.255px.

The ideal font-size (in pixels) is ~3% of viewportheight. For example, if <meta name="viewport" content="width=600, height=1000” />, Apple Books recommends the font-size to be 30px (1000 x .03).

[Hitch]

Originally Posted by Doitsu

Unless it's a font issue, the problem is definitely caused by the code and you're only providing piecemeal information. For example, you've only provided the paragraph style, however, the appearance of the paragraphs is also controlled by the viewportContainer, versoContainer and sectionContainer classes, which are missing. Moreover, you're using ems instead of pixels, contrary to the Apple Books Asset Guide recommendations.

Yep.

If you use ems, and not pixels, for font sizing, in fixed-layout--this sort of thing can definitely occur. Ems are not fixed-layout spacing, as we all know.

When you use pixels, you offset the placement of each and every word--every one--for fixed-layout. Which is one of the reasons that I made the comments that I did, in the first place.

Each word's div is set in pix. (e.g., width:415px;height:200px). Then the absolute position is set for that same word. And set the letter spacing, inside the word. That's how it works. Which isn't done here. As far as I know, without this precise placement, it does not work.

We've used Warnock Pro ourselves and all things being equal and assuming the font came from the usual sources, licensed, etc. I don't know of any problems with it.

Hitch