best format for complete photo book in given quality and feature list / KDP

[Quoth]

Originally Posted by Hitch

Okay, you all knew that I was going to HAVE to ask: why are you trying to make it impossible for people to make notes to themselves????

I mean...what? Why? What business is it of yours if I want to make some notes to myself about the images that you've put, in a book that *I have paid for*? I'm sure you have some perfectly logical reason, but to me, that reads like "control freak trying to control what I do."

I do hate it when I get a secondhand paperback and later discover it's annotated and highlighted. But I support the right of people to do it to their own books.

I agree, there is no good reason ever to prevent electronic document users highlighting and annotating a document.

[Hitch]

Originally Posted by Quoth

I do hate it when I get a secondhand paperback and later discover it's annotated and highlighted. But I support the right of people to do it to their own books.

I agree, there is no good reason ever to prevent electronic document users highlighting and annotating a document.

LOL, you wanker! You know danged well that the notes don't just accrue in some big backlog that download to the next buyer, LOL. Snort....annotated and highlighted books, indeed!

Honestly, I'm dying to hear this explanation.

Hitch

[JSWolf]

Originally Posted by Hitch

Well...to my way of thinking, it's back to basics. Make a nice, ordinary HTMl/CSS eBook, no magic tools, no button-clicking this or that. But I'm sure that piece of advice will be soundly ignored. JWolf thinks that you'll care about what the code looks like underneath; I know better. Authors just don't give two s**ts about how the code looks; they'll by and large do whatever is easiest/cheapest/free. It is, after all, a business and the publisher (that's you) needs to control costs, so...I can respect their need to watch costs. At least that, anyway.

Hitch

Using Sigil and Calibre are watching costs as Sigil and Calibre are free. You cannot get better cost/value then that.

[knightrider247]

Regarding notes: In my opinion it is not cool when you want to flip to the next page and then the notes pop up comes. So I had the user exoerience in mind.

As long as the resukt is better I do care how it looks under the hood. I saw the code of a Kotobee generated page and did not like it ...

Regarding Word: Would you upload that directly then?

My plan so far was
a) exporting an epub from InDesign (freeflow :-))
b) converting it to AZW or MOBI with Calibre

When doing that the code looks much better ...


The problem that the pictures are not displayed correctly (ratio wise) after exporting I should be able to handle once I slept, but the other problem is: The Kindle Previewer tells me that it has a problem with documents generated by Calibre (third party software bla bla). Any idea or should I ignore it and upload it anyway?

Alternatively I could convert the word file to mobi/azw?

Thanks and Greetings
knightrider

[JSWolf]

Originally Posted by knightrider247

Regarding notes: In my opinion it is not cool when you want to flip to the next page and then the notes pop up comes. So I had the user exoerience in mind.

The notes do not pop up when you change the page. You just see highlighted text and maybe a small symbol to see that there is a not attached to the highlighted text.

As long as the resukt is better I do care how it looks under the hood. I saw the code of a Kotobee generated page and did not like it ...

Regarding Word: Would you upload that directly then?

My plan so far was
a) exporting an epub from InDesign (freeflow :-))
b) converting it to AZW or MOBI with Calibre

When doing that the code looks much better ...

A. No to InDesign. You are best hand crafting the code if you want good code.
b. No to converting with Calibre as amazon won't accept it. You can create an ePub and use that as the source for uploading to Amazon.

The problem that the pictures are not displayed correctly (ratio wise) after exporting I should be able to handle once I slept, but the other problem is: The Kindle Previewer tells me that it has a problem with documents generated by Calibre (third party software bla bla). Any idea or should I ignore it and upload it anyway?

Alternatively I could convert the word file to mobi/azw?

Thanks and Greetings
knightrider

Using Word isn't going to work well. You need to be able to see how the eBook looks using the code for the eBook. You nee to figure out the code to keep the images displayed with the correct aspect ratio. You need high resolution images for display on 300DPI eInk screens and you also need to test on old Readers with a 800x600 resolution eInk screen. You have to come up with the code to keep your images at the correct aspect yet leave enough room on scree if you want a caption.

[phillipgessert]

Originally Posted by knightrider247

Regarding notes: In my opinion it is not cool when you want to flip to the next page and then the notes pop up comes. So I had the user exoerience in mind.

Best user experience is to avoid trying to suppress expected device/app behavior. And you're gonna have to get into the code for the best result regardless. You can probably land at a relatively serviceable epub via Word if you're really meticulous about styles, but as far as trying to do something specific, you're gonna get what you get. I mean, makes sense, right? Autoconverters aren't made with anomalous stuff in mind. They're made for predictable input/output.

[Hitch]

Originally Posted by knightrider247

Regarding notes: In my opinion it is not cool when you want to flip to the next page and then the notes pop up comes. So I had the user exoerience in mind.

Man, I must be missing something, which is damned odd. What "notes popup"? If you simply slide the page, you don't see a notes popup. I've never seen one using fxl, either. ???

As long as the resukt is better I do care how it looks under the hood. I saw the code of a Kotobee generated page and did not like it ...

Yes, that's kind of what I expected.

Regarding Word: Would you upload that directly then?

Well, you CAN, but I'm not sure you'll be happy with the result.

My plan so far was
a) exporting an epub from InDesign (freeflow :-))
b) converting it to AZW or MOBI with Calibre

When doing that the code looks much better ...

Ye Gods, do not use AZW or MOBI from Calibre, not to do what you wish. The AZW can't be uploaded, so...that's worthless to you. The MOBI format is the old KF7 format, which is absolutely what you don't want.

The problem that the pictures are not displayed correctly (ratio wise) after exporting I should be able to handle once I slept, but the other problem is: The Kindle Previewer tells me that it has a problem with documents generated by Calibre (third party software bla bla). Any idea or should I ignore it and upload it anyway?

Yes, but the bookmaking METHOD has nothing to do with the ratio. I mean, largely nothing. Do you have images of what it is you're trying to do and the unhappy results? This guessing is vexing.

The aspect ratio of the image is the aspect ratio of the image. There isn't magic coding that will make the image "fit" no matter what device it's on. So...what is it that you're saying, and can we see some images of what you're unhappy about? I have this feeling that you're unhappy with how images display, typically and normally, is my guess.

Alternatively I could convert the word file to mobi/azw?

Please see my comment about this above.

Thanks and Greetings
knightrider

Hitch

[knightrider247]

Regarding notes: holding the tap too long I meant ...

Regarding format: I ruled out EPUB bc Amazon states it does not support e-ink-readers: https://kdp.amazon.com/en_US/help/topic/G200634390

Aspect ratio of the picture: When I wrote that the ratio of the picture is wrong (after exporting and looking at it in Calibre) then I meant exactly that. I was not talking about how it did not fit the screen on all 4 sides. I know that both is not possible.

Any thoughts on that? Therefore I thought it has to be MOBI.

In light of all your input (thank you for that) I only have the following goals now: :-)
-maximum compatibility
-keeping ratio of pictures
-no additional margins (if there are margins bc of the device - so be it - although I have to say I still quite did not understand that ... cause any device that can show a pic can show it maximized to either (!) top and bottom or left and right) - or what am I missing? I am aware it cannot be screen filling on every device and keep the pic ratio at the same time)

I know a little about HTML, but def. not up to the point where it had to be for this. It wouldnt be only HTML but also I would have to know how each device treats certain things, wouldnt I?

So if coding is not an option, the next best is Word?

THX!

[Quoth]

Amazon recommend uploading epub2 rather than docx. It also gives expected results when later test purchased as mobi/azw/KF7, azw3/KF8 or kfx, depending on registered Kindle. Obviously the models only supporting mobi/azw/KF7 give a poorer less compatible experience.
The download for Paperwhite 3 is essentially similar to epub2 on the Kobo, Nook, Sony or Binatone. Sometimes the images are more correctly sized on the Kindle Keyboard 3 in KF8 mode. Earlier KK3 firmware may only do KF7 format.

If it doesn't work on epub2 and the Amazon Kindle downloads from epub2, then an app framework and iOS and Android apps are better. A bit more than half of ebooks are read on phones and tablets, not dedicated ereaders. Only a fraction of phone/tablet App users have the Kindle App installed, though Kindle formats are maybe about 90% of English language ebook sales.
Apps are more widely used and can run on Amazon Fire and a tiny number of eInk models with the Playstore. Though some Apps are unusable on eInk.

[Hitch]

Originally Posted by knightrider247

Regarding notes: holding the tap too long I meant ...

Regarding format: I ruled out EPUB bc Amazon states it does not support e-ink-readers: https://kdp.amazon.com/en_US/help/topic/G200634390

That table is useless. ignore it. ePUB2 is perfectly compatible with all Amazon devices. I recommend not trying ePUB3 unless/until you are dramatically more experienced with eBook-making and can work in the markup/code.

Aspect ratio of the picture: When I wrote that the ratio of the picture is wrong (after exporting and looking at it in Calibre) then I meant exactly that. I was not talking about how it did not fit the screen on all 4 sides. I know that both is not possible.

Any thoughts on that? Therefore I thought it has to be MOBI.

Again, it's not the format. It's the HTML and CSS inside the format. If you build a mobi the same way as you built the ePUB, the images will be distorted, too.

I suspect that your coding says something about "100%" size, in both directions, or the like. (e.g., width 100%, for BOTH height and width.) And when you do that and then open that up in a desktop reader (like Calibre) where you can stretch the reader's dimensions in any old direction, yup, you get distorted images. Or, hell, on a real device, where the coding forces the image to stretch to fill the window, when it oughtn't due to the aspect ratio.

(snippage).

I know a little about HTML, but def. not up to the point where it had to be for this. It wouldnt be only HTML but also I would have to know how each device treats certain things, wouldnt I?

So if coding is not an option, the next best is Word?

THX!

Well, if we could see your code, we could tell you how to fix it. Any chance you could open that up in Calibre's editor, find the code around one of your distorted images and repeat it here?

Hitch

[phillipgessert]

Originally Posted by knightrider247

In light of all your input (thank you for that) I only have the following goals now: :-)
-maximum compatibility
-keeping ratio of pictures
-no additional margins (if there are margins bc of the device - so be it - although I have to say I still quite did not understand that ... cause any device that can show a pic can show it maximized to either (!) top and bottom or left and right) - or what am I missing? I am aware it cannot be screen filling on every device and keep the pic ratio at the same time)

I know a little about HTML, but def. not up to the point where it had to be for this. It wouldnt be only HTML but also I would have to know how each device treats certain things, wouldnt I?

So if coding is not an option, the next best is Word?

THX!

Your new goals are very much hittable for someone that knows a little HTML. Inserting an image and tweaking its size and margins without distortion are among the first things folks learn, so even if you're rusty, you probably know enough to at least start tinkering. One of those things where it takes more energy to avoid code than to just use it.

But forget about maximizing to top and bottom. You cannot target the height of the device, at least not without toasting compatibility by using SVG. For portrait images you will just want to set some sensible width and roll with it.

[Jellby]

The problem is some of the desired features (left-right flow or top-bottom flow, touch to flip pages, navigation, and even maximize to screen size) are more a matter of the software displaying the book than of the book itself, and they're more user preferences (i.e. of the person reading the book) than design choices (of the person creating the book).

You can try to "reimplement" and "override" the reading software, but it it's a road full of frustration and incompatibilities, and prone to break with the next software update.

But if you settle for "show the images at the largest possible size, with no aspect ratio distortion", as phillipgessert says, that's doable and reasonable (except for the bit about not being possible to easily target the screen height, that's a true nuisance).

[knightrider247]

Sure: The image is not distorted, but I presume size wise it is way less then perfecct.


<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>picture</title>
<link href="css/idGeneratedStyles.css" rel="stylesheet" type="text/css" />
</head>
<body id="Unbenannt-1">
<div class="_idGenObjectLayout-1">
<div id="_idContainer000">
<img class="_idGenObjectAttribute-1" src="image.jpg" alt="" />
</div>
</div>
</body>
</html>



body, div, dl, dt, dd, h1, h2, h3, h4, h5, h6, p, pre, code, blockquote {
margin:0;
padding:0;
border-width:0;
}
body {
-epub-hyphens:auto;
}
@page {
margin : 0px 0px 0px 0px;
}
#_idContainer000 {
display:inline-block;
height:343px;
width:595px;
}
img._idGenObjectAttribute-1 {
height:100.00%;
min-width:100%;
width:100.00%;
}
div._idGenObjectLayout-1 {
text-align:center;
}

[phillipgessert]

My advice would be to get away from InDesign for this, and also to not set a height value at all. You should also avoid using fixed units like pixels. Instead I would set your landscape photos at width: 100%.

Portrait, I’m less sure. Perhaps start at something like 70% for those, and experiment from there.

<div class="landscape">
<img src="image.jpg" alt="a wide image"/>
</div>

<div class="portrait">
<img src="image2.jpg" alt="a tall image"/>
</div>

.landscape img {
	width: 100%;
}

.portrait img {
	width: 70%;
	margin-left: 15%; 
}

[Hitch]

Originally Posted by phillipgessert

My advice would be to get away from InDesign for this, and also to not set a height value at all. You should also avoid using fixed units like pixels. Instead I would set your landscape photos at width: 100%.

Portrait, I’m less sure. Perhaps start at something like 70% for those, and experiment from there.

<div class="landscape">
<img src="image.jpg" alt="a wide image"/>
</div>

<div class="portrait">
<img src="image2.jpg" alt="a tall image"/>
</div>

.landscape img {
	width: 100%;
}

.portrait img {
	width: 70%;
	margin-left: 15%; 
}

It looks to me from the quoted code that the containing block is bloody tiny, vis:

height:343px;
width:595px;

And then the contained element is 100% of that. I mean, sh*t, 343px is roughly...what, an eighth of the width of a Fire tablet screen in landscape now and what, one-fourth of the width of it in portrait? TEENY.

For an Oasis, at 1,680 × 1264 pixels, again, you'd be talking a fourth-to-third of the width.

It's the container that's constraining the image. If you use Phillip's stuff, you won't have to worry about that.

Hitch