Fixed Layout vs Reflowable For A Puzzle e-Book

Question

I am putting together a puzzle book. In fact, I have been able to get the book organized into a valid .epub format. However, when I go to view the book on Amazon's Kindle Preview, the layout is less than desirable on the "Phone" and "Kindle e-Reader" options. The content shows fine when I view it through a web browser or if I open it through Google Play from a variety of tablets or if I view it on Kindle Preview's Tablet view --- and that was how I had tested it.

The dilemma is this. The puzzle book format in order for it to make sense needs to have certain elements together. The general layout each page is this (pretend there's a stylesheet somewhere and there are divs in various spots)

Puzzle #
Puzzle Goal
Number of Possible Solutions (with link to solution page)

Puzzle Image HERE

I need for the image to not get tossed on to the next "page" (another swipe). I want each puzzle to be self-contained on one screen regardless of the device. I've tried to have the image auto resize, but this behavior isn't always reliable and if the user chooses a different font setting, auto resizing is irrelevant since the image will simply be too big.

I did some digging around on Amazon's website and found this https://kdp.amazon.com/en_US/help/topic/A1WQ3CZGEVWE1V which effectively says that if you have a book that is image heavy then you want a fixed layout file format.

So I read Amazon's Kindle Publishing Guidelines: http://kindlegen.s3.amazonaws.com/AmazonKindlePublishingGuidelines.pdf to see what it would take to get everything converted to fixed layout file format. From what I gathered, every page has to be its own separate HTML file, with its own stylesheet. I have 100 puzzles, with accompanying solutions making this effectively a 200+ page book (intended).

Thus, my questions are as follows:

1. Is the fixed layout file format, the only way to achieve what I'm after (without making the entire page itself an image)?
2. Is it true that I have to have a separate stylesheet for each page for fixed layout file format? If so, why?
3. Can I have <a> tags in a fixed layout book? (so that I can link to a puzzle's solution and also have a link from the solution back to the original puzzle, among other things)

I ask these questions because this looks like a considerable amount of work and if there are alternative methods in a reflowable way that aren't too much work, I'd rather that. Or if you happen to know some way of taking an existing .epub file which looks as desired in a .pdf [one puzzle on each page] and converting that to fixed layout, I would greatly appreciate a point in the right direction for how to do that.

Answer 1

I'm not answering the main part of your question, which is what are the capabilities of fixed layout ebooks. I think someone with a moderate amount of experience on reflowables could do a reflowable version provided that readers were informed to use a minimum screen resolution (768 pixels width?) and not use devices older than K4.

Fyi there is an issue with Google Play Books which does not honor this bit of code:

img {
page-break-after: always !important;   
}

That makes it impossible to do a page break using css alone in Google Play Books. I'm pretty sure this code works on Kindle devices and other reading systems though.

For a reflowable book, you probably could use css media queries to ensure that each display size works on Kindle. The css breakpoints I use are 320-767px width (both portrait and landscape), 768-1500 (landscape), 1500+ (landscape), 768-1024 (portrait) and 1025+ (portrait). You should use high resolution images and then let Kindle downsize them when needed. Each css media query should specify a different size for the div container which contains the image.

On Kindle the css max-width isn't supported, so I use the code here: https://kdp.amazon.com/community/thread.jspa?messageID=1005910

If you do reflowable, you could declare that ebook is only for tablets and not for phones (that's the easiest thing!). For smaller screens you could split the content into 2 screens, but it wouldn't be optimal.

A lot of testing would be involved, but it wouldn't be impossible.