jeroen said:
> I will continue then...
great! i'm glad nothing i said served to dissuade you.
your workflow is so idiosyncratic that i don't think it will
ever be a specific aid to other d.p. post-processors, but
your general attitude of wanting to improve your e-books
-- even in the face of d.p. and p.g. stupidity -- _will_ be
a good role-model for others. at least i hope that it will.
> Agreed, but I have a feeling this is a passing phase
well, the lack of power will certainly change in the future.
but that doesn't mean all of the viewer-inconsistencies
will immediately go away. my guess is that they _won't_.
even with web-browsers, the incompatibilities still exist.
yes, the "basics" have all achieved a degree of uniformity,
but on the edges, not so much, as illustrated best by c.s.s.,
where you still have to specify lots of stuff _by_browser_...
for instance, we still need code like this:
> background: url('linear-gradient.png') 0 0 repeat-x;
> background: -moz-linear-gradient(top, #a1e048, #6a942f);
> background: -ms-linear-gradient(top, #a1e048, #6a942f);
> background: -o-linear-gradient(top, #a1e048, #6a942f);
> background: -webkit-linear-gradient(top, #a1e048, #6a942f);
those browser-prefixes are an indicator of the sickness...
and .html5 as a "living standard" (i.e., never on solid ground)
will only exacerbate the problem. what worked yesterday...
well, it might work today, or it might not, we'll have to check.
and that's in an arena where the vendors have a motivation
to match up with each other, to conform to the specification.
but the e-book world has evolved differently, such that the
commercial interests there believe their business imperative
compels 'em to _be_distinct_, so as to build a walled garden.
apple didn't bother with the tedious "embrace" step on .epub;
just skipped straight to the "extend" step with "ibooks author".
and apple didn't even try to disguise this with technical talk;
it was so bold it included a "you must sell output through us"
clause right in the legal terms for the authoring-tool itself...
so, if apple is willing to be that brazen with their customers,
do you really think it's going to work for greater cross-
> But everybody in the "scene" of pirated books is using it.
> (Maybe those two facts are related)
no, _those_ facts aren't related.
the point is whether you must maintain the markup inside.
calibre rewrites that markup, and the rewrite is _extreme._
trying to rework markup after calibre rewrote it is painful.
> I know it wrecks my books...
_that_ fact might be related. due to that extreme rewrite.
> I will try to do some testing on iPads then
apple has about 30% of the total market, 77% of the .epub.
kindle has about 60% of the total market, almost no .epub.
everyone else splits the rest; 10% of the total, 22% of .epub.
so, for your .epub version anyway, ibooks is all that matters.
> Chaining conversions is a pain,
> that is what I complained about several times.
it's a bit more work to have to make a .mobi _and_ an .epub.
that's why most people feed their .epub to kindle-previewer.
but it will hurt your .epub to force it into .mobi double-duty.
so i prefer to make the .mobi separately, and _specifically_...
(the .opf and .ncx are a bit easier to make than for an .epub;
plus, yay, you don't have to split the .html into 300k chunks.)
> For that I will need the spec of both.
well, for .mobi, you pretty much know what will work now,
and sadly, that's probably all that'll _ever_ work for .mobi.
kf8 -- which is now not much more capable than .mobi --
should start showing regular boosts in its capabilities, and
that's why you're gonna wanna split it off as a separate flow.
> I thought it was pretty closed,
> but maybe there are some pointers.
the #eprdctn hashtag on twitter is utilized by many people
who're employed to make e-books, or freelancing at it, so
you can keep up with developments by looking in on that...
> ePub3 is the xml-variant of html5, but ePub3 isn't there yet.
yeah, i know that's "the line".
but considering that .html5 is the route that we switched to,
once enough people finally realized .xml was the wrong way,
that "official line" is best viewed as a contradiction-in-terms.
> I think that should be answer to some of the complaints,
> with a proper explanation of the state of technology.
but that was my earlier point. it is _not_ just "technology".
there's a lot of business shenanigans going on that mean
we're not gonna get what we want out of e-books until we
loss all these corporate leeches and establish our own way.
-bowerbird
