> the idea of page size goes pretty much out the window.
what pagesize did your .pdf have? that's what i meant.
if you put each section on its own e-book screen, and
make the sections small enough to fit on one _screen,_
or two, or three, they'll also fit on one/two _pages._
*
> Using CSS page-break doesn't quite help,
> since it presumes what has come before
> and how it fit on the page.
i'm not sure i understand.
so -- for the sake of others reading this thread --
let me explain further. when you create the e-book,
if you segment the book into small-enough sections,
it'll generally work, across almost all situations,
no matter how the person has configured the fontsize.
so there, a "screen-break" comes before each section,
and before-and-after images you want to fill a screen.
conversely, for the .pdf, you _know_ the pagesize, and
the fontsize as well, so you know where pagebreaks are,
and you add/delete/change until you get what you want.
*
> What's needed is orphan/widow control
> and "keep with next" so that, for examples,
> related sections can be rendered on one page
> or the next but not split across pages.
it would be nice if the programs had enough smarts to
do this automatically; until then, you do it manually.
but you don't need indesign to do it; you really don't.
i'd be happy to show you how i'd do your book, if you'd
be interested in seeing it, if you send me a copy of it.
*
> In practice, though, I found I needed to
> aim for some sort of highest common factor
> across popular devices, keep test-viewing
> the results, and drop anything too clever.
that is the approach that is needed these days, yes.
I don't recall now just how I originally did the PDF, but it was some CLI tool that read either the markdown or HTML.
let me explain further. when you create the e-book, if you segment the book into small-enough sections, it'll generally work, across almost all situations, no matter how the person has configured the fontsize.
That's probably true enough for ebook readers (and I got good results for just epub using my CLI tools) but once I went to InDesign for the PDF layout using it for epub generation was no big deal and that was where I was making final changes to the text.
i'd be happy to show you how i'd do your book, if you'd be interested in seeing it, if you send me a copy of it.
(If you need the actual markdown files I'd have to see about packing those up. I was writing the book as a Webby-generated site using a combination of Markdown and ERB. I had some scripts that would then use that same generated HTML to package it up as epub. )
It would be great if I could use command-line tools to generate the PDF while not sacrificing the precise look and layout I want but I'm deeply skeptical this can be done without a visual tool and manual adjustments to adjust things for aesthetic reasons. (Or without learning LateX. :))
ok, that didn't take long. can't open your .epub file.
it doesn't validate, and i wonder if anyone can open it.
so that's a major problem that you will need to solve...
unzipped it to find out why, and discovered it was made
with calibre. e-book developers hate that program because
it does a rewrite of the underlying .html and .css files,
creating an unholy mess that's very difficult to decipher.
personally, i won't touch a calibre file; life is too short.
aside from the .epub, the .mobi and the .pdf do just fine
in getting the content across, so even though i would likely
have done them slightly differently, what you have is fine.
still, if you really want more feedback, i can give it. but
the original markdown files would be best, concatenated so
they're just one big file, with the text running linearly.
(a book really works best with the whole thing in one file,
because that usually minimizes editorial inconsistencies
while you're writing, and makes it easier to check later.
it also dampens file-clutter considerably, which is good.)
ok, that didn't take long. can't open your .epub file. it doesn't validate, and i wonder if anyone can open it. so that's a major problem that you will need to solve...
Weird. It was generated using InDesign (though I've now learned that opening the .epub in Calibre's ebook-reader will insert a bookmarks file into the zip).
I then used Kindlegen to turn that epub into mobi for sale on Amazon, and Calibre to create the mobi I offer elsewhere. No one has told me they had any trouble opening files and I've viewed them using assorted programs.
(a book really works best with the whole thing in one file, because that usually minimizes editorial inconsistencies while you're writing, and makes it easier to check later. it also dampens file-clutter considerably, which is good.)
I find it easier to break things out into chapter files. Turning the chapters into a Web site even if only hosted locally) makes it easy to navigate through the whole thing. It works for me.
> getting the PDF just right was important to me.
i respect that. how were you generating the .pdf?
*
> Since the user can set the font and text size
> the idea of page size goes pretty much out the window.
what pagesize did your .pdf have? that's what i meant.
if you put each section on its own e-book screen, and make the sections small enough to fit on one _screen,_ or two, or three, they'll also fit on one/two _pages._
*
> Using CSS page-break doesn't quite help,
> since it presumes what has come before
> and how it fit on the page.
i'm not sure i understand.
so -- for the sake of others reading this thread -- let me explain further. when you create the e-book, if you segment the book into small-enough sections, it'll generally work, across almost all situations, no matter how the person has configured the fontsize. so there, a "screen-break" comes before each section, and before-and-after images you want to fill a screen.
conversely, for the .pdf, you _know_ the pagesize, and the fontsize as well, so you know where pagebreaks are, and you add/delete/change until you get what you want.
*
> What's needed is orphan/widow control
> and "keep with next" so that, for examples,
> related sections can be rendered on one page
> or the next but not split across pages.
it would be nice if the programs had enough smarts to do this automatically; until then, you do it manually.
but you don't need indesign to do it; you really don't.
i'd be happy to show you how i'd do your book, if you'd be interested in seeing it, if you send me a copy of it.
*
> In practice, though, I found I needed to
> aim for some sort of highest common factor
> across popular devices, keep test-viewing
> the results, and drop anything too clever.
that is the approach that is needed these days, yes.
-bowerbird