The joys --- or not --- of KPV 3

[kso]

I have three questions about the Kindle Previewer 3. I'm running the previewer in a virtual Win7 (32bit) PC under QEMU on Linux. The virtual PC has 4GB Ram. Previewer 2.94 runs as expected in this virtual PC.

1) I can't get KPV3 to display anything on the simulated tablet or phone "screens" in the preview window. All I see is the frame of the selected device (tablet, phone or kindle reader), with frame-less pages shown on the left in the preview window. I've installed KPV3 on my wife's win7 Home PC and there previews work showing the previews in the selected "device", although that PC also has 4GB Ram.

2) KPV3 running in the virtual PC refuses to display "Publisher Fonts". In fact, the menu choice to do so isn't there. On my wife's "real" PC again this works, but then it seems to use this font exclusively and not just in the few places where my CSS says the alternative font should be used. This is in contrast to, say, (i)Books on an iPad. Don't throw stones at me. I need a mono-spaced font for some script code listing that looks rather silly in a proportional font.

3) KPV3 dislikes floats on both installations I tried. If I have a float like a small image or a pull-quote set to any width less than 100%, KPV3 stretches it all the way across.

All three (!) cases work in KPV 2.94 and all the epubs validate.

I know 3.48 is available. Version 3.38 was the last one I was able to install under win7. I have a windows 10 (64bit) dvd here to install once I have a bit more time or I get desperate. Allowing windows to use more than 4GB of RAM might be enough to resolve 1) and 2), but I'm really frustrated about 3).

Does anyone have experienced one or more of the situations I described and found a way round? The first one I can cope with, but it's frustrating not to be able to see what is possibly just a "best case" scenario?

klaus

[slowsmile]

"1) I can't get KPV3 to display anything on the simulated tablet or phone "screens" in the preview window. All I see is the frame of the selected device (tablet, phone or kindle reader), with frame-less pages shown on the left in the preview window. I've installed KPV3 on my wife's win7 Home PC and there previews work showing the previews in the selected "device", although that PC also has 4GB Ram."
I have Oracle Virtual Box(OVB) running both on my Linux Mint and Windows 10 system on my laptop without any problems. To run the OVB emulator I also have 12 GB ram on my laptop. Quite frankly I would also have to say that running KP3 within QEMU with only 4GB ram is rather laughable in terms of the memory that's actually needed for that emulation. The KP3 application alone is about 1GB in size!! And I would never even consider using any emulator unless I had at least 8GB ram available on my computer.

"3) KPV3 dislikes floats on both installations I tried. If I have a float like a small image or a pull-quote set to any width less than 100%, KPV3 stretches it all the way across."
I don't understand when you say your using "floats" and "pull-quote" to position your images and text. If you're just talking about size and position of images, for epubs I generally use % values in my <img> tags which specifies the actual image size in terms of % of current screen size. Like this:

<p class="centered"><img alt="img001.jpg" src="../Images/image001.jpg" style="width: 50%;height: auto;"/></p>

In epubs you only have the choice of left aligned or centered for images. And you should not be anchoring images surrounded by text in reflowable ebooks. So forget about using "float" for positioning in epubs. You're asking for trouble if you do that. Centered or left aligned is really your only sensible choice for images or text.

[kso]

Thanks for your comments, slowsmile.

1) I was talking about the RAM made available to win7, not the amount installed on the system. If I tell Qemu to give win7 8GB, it can't use that - it's a 32 bit x86 OS. Sorry if that was unclear. The issue is really that the emulated win7 instance behaves different to one that runs on its own hardware, both with 4GB Ram. I was hoping someone would know why, but it's early days.

3) Here I was comparing PV 3.38 to PV 2.94 (and books sideloaded to kindle fire 7in and 8.9in, touch, even kindle keyboard 2 (the white one) and 3).

PV 3.38 fails, all the others work as expected.

klaus

[DNSB]

Originally Posted by slowsmile

In epubs you only have the choice of left aligned or centered for images. And you should not be anchoring images surrounded by text in reflowable ebooks. So forget about using "float" for positioning in epubs. You're asking for trouble if you do that. Centered or left aligned is really your only sensible choice for images or text.

I've used right aligned images often enough in epubs to know that they work. Perhaps not in Amazon's mobi, azw3 or KFX formats since I have never tested a right aligned image in those formats.

[Hitch]

Originally Posted by DNSB

I've used right aligned images often enough in epubs to know that they work. Perhaps not in Amazon's mobi, azw3 or KFX formats since I have never tested a right aligned image in those formats.

As have we, and they work fine in KF8 and most likely KFX; they are not worth a damn, obviously, in the old KF7 (original mobi) format, as it ignores CSS entirely.

Hitch

[Quoth]

Right aligned anchored as a character should work in epub.
Float (i.e. with more than one line of text beside the image) may not work.

[kso]

As have we, and they work fine in KF8 and most likely KFX; they are not worth a damn, obviously, in the old KF7 (original mobi) format, as it ignores CSS entirely.

Hitch

That's what I implied with my reply to slowsmile when I said

3) Here I was comparing PV 3.38 to PV 2.94 (and books sideloaded to kindle fire 7in and 8.9in, touch, even kindle keyboard 2 (the white one) and 3).

.

Floats also work in (i)Books and some other readers as they do in Calibre. But there are apps on both iOS and Android that leave you in tears.

But coming back to my original posting: anyone knows if PV3.* truly shows what comes out at the other end of the KPS or if this is just an approximation, and one that's not as precise as shown by PV 2.94?

klaus

[jhowell]

Originally Posted by kso

But coming back to my original posting: anyone knows if PV3.* truly shows what comes out at the other end of the KPS or if this is just an approximation, and one that's not as precise as shown by PV 2.94?

Amazon supports multiple different Kindle book formats and associated rendering software depending on the device/app used for reading. Devices and apps released in the last five years support KFX format, providing "Enhanced Typesetting".

Previewer 2 predates KFX and shows how a book will render from the older MOBI7 or KF8 formats. That is how the book will look on older devices and also on newer ones if sideloaded instead of being delivered over-the-air by Amazon.

Previewer 3 shows how the book will render from KFX format, which can be quite different. One of the features of Enhanced Typesetting is intentionally not obeying all of the formatting specified in the book in order to produce a more readable result on smaller screens, like phones.

When your book is actually published Amazon will make some adjustments during the publishing process, but what Previewer 3 shows is very close to the end result in most cases.

[Hitch]

Originally Posted by jhowell

Amazon supports multiple different Kindle book formats and associated rendering software depending on the device/app used for reading. Devices and apps released in the last five years support KFX format, providing "Enhanced Typesetting".

Previewer 2 predates KFX and shows how a book will render from the older MOBI7 or KF8 formats. That is how the book will look on older devices and also on newer ones if sideloaded instead of being delivered over-the-air by Amazon.

Previewer 3 shows how the book will render from KFX format, which can be quite different. One of the features of Enhanced Typesetting is intentionally not obeying all of the formatting specified in the book in order to produce a more readable result on smaller screens, like phones.

When your book is actually published Amazon will make some adjustments during the publishing process, but what Previewer 3 shows is very close to the end result in most cases.

FWIW, we still use KP2 to assess (easily) how something will look on DX, etc. (the KF7 devices).

I find that KP3 is roughly approximate, but it has several glitches, particularly around images, that make it important to be able to live test on real devices.

Hitch

[kso]

Originally Posted by jhowell

One of the features of Enhanced Typesetting is intentionally not obeying all of the formatting specified in the book in order to produce a more readable result on smaller screens, like phones.

Shame there is no mechanism by which you could tailor your instructions to specific devices or media, so you'd be able to verify before publication that your code --- as long as you and the previewer both follow published guidelines --- actually does what you want.

Originally Posted by Hitch

I find that KP3 is roughly approximate, but it has several glitches, particularly around images, that make it important to be able to live test on real devices.

I've seen several types of glitches, mostly to do with indentation (of lists), ignoring the PRE element (proportional spacing), and vertical spacing.

All the things I've noticed so far work in PV 2.94 and on actual Kindle devices when I sideload KF8 books. That's what's really frustrating.

So far KPV 3 appears to be a step backwards (or maybe not yet ready for production?) for the author, even if it has advantages for Amazon.

klaus

[Hitch]

Originally Posted by kso

Shame there is no mechanism by which you could tailor your instructions to specific devices or media, so you'd be able to verify before publication that your code --- as long as you and the previewer both follow published guidelines --- actually does what you want.

Well, there are, in fact, media queries that you can use to (somewhat) tailor your rendering to devices. Kindles are basically honoring screen-size-based identifications, using device-aspect-ratio. It's not perfect, mind you; for example, you still can't really tailor to the LookInside--but it's a huge step up from a few years ago when there was NO way to separate out an iPad, for example, from other KF8-rendering devices.

And you can use them for older-device capability, too. "amzn-mobi" versus "amzn-kf8" and the like.

I've seen several types of glitches, mostly to do with indentation (of lists), ignoring the PRE element (proportional spacing), and vertical spacing.

All the things I've noticed so far work in PV 2.94 and on actual Kindle devices when I sideload KF8 books. That's what's really frustrating.

So far KPV 3 appears to be a step backwards (or maybe not yet ready for production?) for the author, even if it has advantages for Amazon.

klaus

Images can display quite improperly, both in size and alignment. I've had to take screenshots of books, on real physical devices, to assuage customer concerns based upon what they see in KP3. Also, the line-heights in KP3 are slighly off, slightly too tall/high. While that mayn't seem a big deal, to some customers who are very obsessed about appearance, the distance between (for example) the end of one body paragaph to the next subhead, to the following body paragraph is VERY important and they can be quite...distressed...if they think that the layout isn't close to what they've got in print (or whatever).

Hitch

[kso]

Originally Posted by kso

Shame there is no mechanism by which you could tailor your instructions to specific devices or media, so you'd be able to verify before publication that your code --- as long as you and the previewer both follow published guidelines --- actually does what you want.

Originally Posted by Hitch

Well, there are, in fact, media queries that you can use to (somewhat) tailor your rendering to devices.

Damn. Completely forgot the sarcasm tag. Sorry 'bout that. But seriously, I found the aspect-ratio queries somewhat erratic, whereas the amzn-mobi and amzn-kf8 queries work.

Originally Posted by Hitch

While that mayn't seem a big deal, to some customers who are very obsessed about appearance, the distance between (for example) the end of one body paragaph to the next subhead, to the following body paragraph is VERY important...

And rightly so I say. I know it's easier to find fault in other people's work, but I seem to notice even small mis-alignments or bad spacing. And I do not obsess, it's just that I notice. I've only started reading on a kindle about 18months ago, so I've dealt with dead tree books all my life. And I habitually look at the design of everything before and after the main content. Some books are really beautiful, but a there are some that seem to have had accidents during production (or earlier).

klaus

[Hitch]

Originally Posted by kso

Damn. Completely forgot the sarcasm tag. Sorry 'bout that. But seriously, I found the aspect-ratio queries somewhat erratic, whereas the amzn-mobi and amzn-kf8 queries work.

I agree that they are erratic, but they seem to have stabilized a bit from when we first attempted them...gosh, I dunno, 2+ years ago? They do seem to work better now.

It is always a sense of wonderment to me, that invariably and inevitably, as sure as the rising of the sun follows the night, the Media queries and other coding examples in the Publisher's Guidelines, from Amazon...will not work correctly or at all.

For years, the text-color example didn't work and the text box? Don't get me started.

And rightly so I say.

To some extent. We tend to deal with a lot of yammer that is more about "exactly" matching someone's print layout than simply channeling the look/feel of the print book. I cannot tell you how many times in the course of a week that I have to explain that we don't have kerning/tracking in eBooks and/or that we can't adjust the leading throughout. (sigh).

I know it's easier to find fault in other people's work, but I seem to notice even small mis-alignments or bad spacing. And I do not obsess, it's just that I notice. I've only started reading on a kindle about 18months ago, so I've dealt with dead tree books all my life. And I habitually look at the design of everything before and after the main content. Some books are really beautiful, but a there are some that seem to have had accidents during production (or earlier).

klaus

It is indeed easier to find fault with others' work! And it's typically happy-making to notice, telling yourself that of course, you would have done better. Ha!

It's satisfying to design or create a good-looking ebook--but it's equally easy to be exceedingly disappointed by the result when you see it overridden in a Paperwhite, or on KCR, or completely obliterated in iBooks, etc.

You have to take it in stride, because other than going with PDF as your "ebook format," the reality is, your control is limited.

Hitch

[Quoth]

And PDF is really paper proofing and not an ebook format at all.

It's really great to be able to read the book just by page turning on everything from 160 x 160 pixel Palm PDA, 5" Sony eink, 4.3" to 10" Android screens, 9.7" DX / DXG, 6" 167 dpi Kindles, 6" and bigger 300 dpi Kindles and various eink and LCD epub readers.