blah blah blah feasibility blah

jeroen said:
I know my ePubs are far from perfect, as, since I am unable to submit them to PG, I lack some motivation to improve them.
your desire to try to improve them is commendable...
I've only been able to test them on PC based readers, which are in general far more forgiving than the small devices they are meant to go on.
they are often "more forgiving", yes, but the real issue is that the chips in our hand-held machines are weak... a lot of hacking is being done in the reader-programs to offset the major lack of power in those hand-helds.
I normally use Calibre to read, now have also installed nook for PC and ADE.
none of the people who make e-books for a living will have anything to do with calibre, not even to just "read". nook for p.c. is also quite squirrely, and sadly, so is a.d.e. (if it weren't for its d.r.m. lock-in which locks in libraries, a.d.e. would have no customers at all; readers hate a.d.e.) there is really only one .epub platform that matters at all, at least at this time, and that's apple. so you need to test on an ipad. i recall you dissing apple, as proprietary, and i understand that. but if you wanna go where people are... the other thing that most people would have to think about is whether their .epub converts nicely to .mobi by kindlegen. because kindle is where the vast majority of people are now. and if you're gonna feed your .epub to kindlegen, then you will also need to factor that fact into your work-flow as well. but since you're working from a master-file, you should not chain your conversions. instead, write mobi-friendly .html. and feed _that_ to kindlegen. separate it totally from .epub. that will also allow you to generate another version for kf8. don't listen to anyone who tells you that kf8 is just like .epub. to put it bluntly, they do not know what they're talking about. .epub has an .xhtml base, whereas kf8 jumped up to .html5. (people will tell you .epub3 does .html5; don't believe them.)
I have regenerated the file with some fixes you suggest, and re-uploaded to the same location.
a word of warning, just so you know. the state of .epub uniformity is shockingly bad. what "works" on one platform might not work on another one. at some point, you need to shrug it off when something "fails". as long as the file, as a whole, works on _one_ platform, then you've done about all you can be expected to do. seriously... (and, as i said up above, the platform to shoot for is apple's.) each of the viewer-applications -- every single one of 'em -- supports only a subset of c.s.s., and sometimes a small one, so any expectations you might have that something will work -- or "should" work, or whatever -- will need to be _verified_. so don't even bother trying to get _everything_ right, because it's just not possible at this time. and you should be told that. (but again, don't use a.d.e. as a guide, because it's the worst.)
Doesn't reproduce for me on any of the PC based readers. Probably has to do with the width of the table.
whether something works on a pc-based reader means nothing.
(but that is really a task of the rendering device, I can only add hyphenation hints...)
expectations any hand-held viewer-app will handle _anything_ are not well-founded. so you do yourself no favor by trying to shift responsibility to them. they will not honor your to-do list. so if you don't want to -- or cannot -- handle a thing yourself, you need to just tell people "sorry, you cannot have that now"... similarly, it does no good to say "i'm following the specification", since the viewer-apps don't give a tinker's damn about the spec. i know this is not what people would like to hear. but it's true.
Again, I do not observe this with the browsers I use to test.
and again, you can't use a browser to test out your e-books... i know, i know, the format wonks tell you that "it's just .html", which leads you to believe that if the .html works "someplace", it should work _anyplace_, including in an e-book viewer-app, but the fact is that that does not accord with our reality today. it would be very nice if you could use a browser to test stuff. but you can't. so don't even try. you will be fooling yourself.
This must be an issue with devices.
ok, so i'll say it one more time. if you really want to care about what your e-books look like, you can't use this dodge. better just to say "ok, i don't care." -bowerbird

On 2012-10-11 00:07, Bowerbird@aol.com wrote:
jeroen said:
your desire to try to improve them is commendable...
I will continue then...
a lot of hacking is being done in the reader-programs to offset the major lack of power in those hand-helds.
Agreed, but I have a feeling this is a passing phase, and things will sort out in a few years time. (Although I just read about a 10-dollar, ultra-low powered eBook reader that has no rendering engine at all, just memory for pre-rendered pages).
none of the people who make e-books for a living will have anything to do with calibre, not even to just "read".
But everybody in the "scene" of pirated books is using it. (Maybe those two facts are related) I know it wrecks my books...
nook for p.c. is also quite squirrely, and sadly, so is a.d.e. (if it weren't for its d.r.m. lock-in which locks in libraries, a.d.e. would have no customers at all; readers hate a.d.e.)
Fully agree here...
there is really only one .epub platform that matters at all, at least at this time, and that's apple. so you need to test on an ipad. i recall you dissing apple, as proprietary, and i understand that. but if you wanna go where people are...
Well, the main reason I personally dissed Apple (and I've owned several of their machines before, and still have a Mac 512k in the attic), is that I believe the deliver a very bad _service_ to their customers. Technology wise, their machines are good. I will try to do some testing on iPads then (enough friends who have them).
the other thing that most people would have to think about is whether their .epub converts nicely to .mobi by kindlegen. because kindle is where the vast majority of people are now.
I will try that one. On this side of the Atlantic, kindle isn't as popular as ePub, but still, most PG "customers" are in the US.
but since you're working from a master-file, you should not chain your conversions. instead, write mobi-friendly .html. and feed _that_ to kindlegen. separate it totally from .epub.
Chaining conversions is a pain, that is what I complained about several times.
that will also allow you to generate another version for kf8.
For that I will need the spec of both. I thought it was pretty closed, but maybe there are some pointers.
don't listen to anyone who tells you that kf8 is just like .epub. to put it bluntly, they do not know what they're talking about. .epub has an .xhtml base, whereas kf8 jumped up to .html5. (people will tell you .epub3 does .html5; don't believe them.)
ePub3 is the xml-variant of html5, but ePub3 isn't there yet.
so if you don't want to -- or cannot -- handle a thing yourself, you need to just tell people "sorry, you cannot have that now"...
I think that should be answer to some of the complaints, with a proper explanation of the state of technology. Jeroen.

that will also allow you to generate another version for kf8.
For that I will need the spec of both. I thought it was pretty closed, but maybe there are some pointers.
I don't think anyone other than Amazon (well, maybe Calibre) tries to directly generate mobi files. Rather, what they do is create an epub file and then feed that to kindlegen to create the mobi file. The epub in turn ideally contains some Amazon-specific tweaks, primarily to get the "Start" and "TOC" tags right. Amazon has been incredibly sucky about publishing actually useful documentation about what they actually support or don't support in their flavor of "epub." But what they have published (and not all of that is correct) can be found at: http://www.amazon.com/kindlepublishing mobiread and other forums including DP have insights (and flames) Someone somewhere *does* understand mobi internals, see for example "mobiunpack" a python script which turns mobi into epub. Search http://www.mobileread.com on "mobiunpack", also http://wiki.mobileread.com/wiki/Mobi_unpack . [These tools only work on non-DRM -- they are not piracy tools.] Then the epub derived from the mobi can be examined using Sigil for example. This is useful, for example, to try to reverse engineer what the epubmaker chain is actually doing to your code, so that you can try to work around the epubmaker transformations. See also: http://wiki.mobileread.com/wiki/MOBI -- if, god forbid, you insist on bit-twiddling yourself.

"James" == James Adcock <jimad@msn.com> writes:
This is useful, for example, to try to James> reverse engineer what the epubmaker chain is actually doing James> to your code, so that you can try to work around the James> epubmaker transformations. Why should you need to reverse engineer epubmaker, when you can directly read the source code? epubmaker is GPL (except, of course, the calls to kindlegen). Carlo

Or better yet find out what it wants for input so it doesn't need to do transformations. Code generating code from code will always be an uncertain proposition. On Thu, Oct 11, 2012 at 12:36 PM, Carlo Traverso <traverso@posso.dm.unipi.it
wrote:
"James" == James Adcock <jimad@msn.com> writes:
This is useful, for example, to try to James> reverse engineer what the epubmaker chain is actually doing James> to your code, so that you can try to work around the James> epubmaker transformations.
Why should you need to reverse engineer epubmaker, when you can directly read the source code? epubmaker is GPL (except, of course, the calls to kindlegen).
Carlo _______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d

Why should you need to reverse engineer epubmaker, when you can directly read the source code? epubmaker is GPL (except, of course, the calls to kindlegen).
I can read the code, but I am not a python programmer, so that doesn't get me very far. I've tried some python debugging environments to see if that helped either, and didn't get very far. For me it's easier just to check to see what epubmaker is generating and why, and then try to reverse-engineer the mindset of the developer -- so as to avoid it.

On 10/11/2012 08:12 AM, Jeroen Hellingman wrote:
Agreed, but I have a feeling this is a passing phase, and things will sort out in a few years time. (Although I just read about a 10-dollar, ultra-low powered eBook reader that has no rendering engine at all, just memory for pre-rendered pages).
The rendering engines will improve. What will not change is the screen size of mobile devices.
I will try that one. On this side of the Atlantic, kindle isn't as popular as ePub, but still, most PG "customers" are in the US.
Only one in every 3 PG customers come from the US. (according to Alexa) About 20% of dowloads are epub. About 12% of downloads are kindle. -- Marcello Perathoner webmaster@gutenberg.org

but since you're working from a master-file, you should not chain your conversions. instead, write mobi-friendly .html. and feed _that_ to kindlegen. separate it totally from .epub.
You are better off making a "mobi-friendly" version of your epub, since that will support more of the "advanced" features of Kindles automatically, such as navigational aids. In practice, I don't find that Mobi8 "incompatibilities" are any greater than the myriad epub platform incompatibilities already out there. Certainly there are some extraordinarily sucky epub implementation out there.
don't listen to anyone who tells you that kf8 is just like .epub.
If you try it, I think you will find that mobi8 incompatibles are in practice not more or less of a problem than what you will find with the other epub platform incompatibilities.
(and, as i said up above, the platform to shoot for is apple's.)
Seriously? Go read Elizabeth Castro's rants about Apples' gratuitous incompatibilities, particularly sucky implementation of fonts - and Elizabeth Castro is an "Apple Centric" developer no less. Certainly *do* check to see how your work runs on Apple - so you can also see how Apple's incompatibilities break your work. While you are out it check out the sales specs for the share of commercial ebooks actually being sold on Apple - Amazon is widely reported to have 90% of the market.
similarly, it does no good to say "i'm following the specification", since the viewer-apps don't give a tinker's damn about the spec. i know this is not what people would like to hear. but it's true.
Also a true statement about HTML in general. No HTML browser actually implements the spec. What the major browsers have done is work together over the years to reduce incompatibilities in what they do implement.
participants (6)
-
Bowerbird@aol.com
-
don kretz
-
James Adcock
-
Jeroen Hellingman
-
Marcello Perathoner
-
traverso@posso.dm.unipi.it