|
View Poll Results: ePub Creation | |||
I currently produce ePub but not LRF | 12 | 22.64% | |
I currently produce LRF but not ePub | 20 | 37.74% | |
I currently produce ePub and LRF | 9 | 16.98% | |
I currently produce neither ePub or LRF | 2 | 3.77% | |
I will produce ePub when non-Sony devices support ePub | 6 | 11.32% | |
I will produce ePub if Sony stops supporting LRF | 3 | 5.66% | |
I do not plan on ever supporting ePub | 4 | 7.55% | |
I need better tools to support ePub | 15 | 28.30% | |
Multiple Choice Poll. Voters: 53. You may not vote on this poll |
|
Thread Tools | Search this Thread |
01-09-2009, 09:21 AM | #46 | |||||
When's Doughnut Day?
Posts: 10,059
Karma: 13675475
Join Date: Jul 2007
Location: Houston, TX, US
Device: Sony PRS-505, iPad
|
Quote:
Quote:
Quote:
Quote:
Quote:
I appreciate your comments and info, mtravellerh. Thanks. |
|||||
01-09-2009, 10:47 AM | #47 | |
frumious Bandersnatch
Posts: 7,514
Karma: 18512745
Join Date: Jan 2008
Location: Spaniard in Sweden
Device: Cybook Orizon, Kobo Aura
|
Quote:
|
|
Advert | |
|
01-09-2009, 01:31 PM | #48 |
book creator
Posts: 9,635
Karma: 3856660
Join Date: Oct 2008
Location: Luxembourg
Device: PB360°
|
One pretty important point for me, too. I am not a techie, my interests lie in ebook making and I want to be able to make good work and make it as simple as possible so that I can edit fast and transfer those changes as fast and as easy as possible to the various ebook formats.
|
01-10-2009, 02:02 PM | #49 | |
Feedbooks.com Co-Founder
Posts: 2,263
Karma: 145123
Join Date: Nov 2006
Location: Paris, France
Device: Sony PRS-t-1/350/300/500/505/600/700, Nexus S, iPad
|
Quote:
|
|
01-11-2009, 04:42 PM | #50 | |
Wizard
Posts: 3,671
Karma: 12205348
Join Date: Mar 2008
Device: Galaxy S, Nook w/CM7
|
Quote:
=X= |
|
Advert | |
|
01-11-2009, 11:16 PM | #51 | |
Reader
Posts: 11,505
Karma: 8720163
Join Date: May 2007
Location: South Wales, UK
Device: Sony PRS-500, PRS-505, Asus EEEpc 4G
|
Quote:
I'm currently not making EPubs because I use Book Designer and Mobipocket Creator, and can't be doing with yet another converter to use with each book. This may change, as I get round to exploring new tools. |
|
01-11-2009, 11:56 PM | #52 | |
Wizard
Posts: 3,671
Karma: 12205348
Join Date: Mar 2008
Device: Galaxy S, Nook w/CM7
|
Quote:
The nice thing about calibre's ePUB is it takes sony 300KB files size limit =X= |
|
01-12-2009, 01:02 AM | #53 | |
GuteBook/Mobi2IMP Creator
Posts: 2,958
Karma: 2530691
Join Date: Dec 2007
Location: Toronto, Canada
Device: REB1200 EBW1150 Device: T1 NSTG iLiad_v2 NC Device: Asus_TF Next1 WPDN
|
Quote:
I view .epub as an ultimate ebook source format and cringe when I see the resulting .html (xhtml) included therein as output by Calibre (no offense intended) in accordance to the ADE limitation. [RANT] I know the switch --profile="None" exists (and am grateful Kovid has allowed this), but IMHO it is a shame to have this source format be "butchered" i.e. somewhat arbitrarily split, so as to meet this minuscule limitation. I mean what happened, so as to not use MB or GB capacity or storage, since 300KB... KB, I mean, is so 1990's!!!!!!! [/RANT] I'm not shooting the messanger, but just the imposer of the limitation! |
|
01-12-2009, 01:08 AM | #54 | |
book creator
Posts: 9,635
Karma: 3856660
Join Date: Oct 2008
Location: Luxembourg
Device: PB360°
|
Quote:
I WAS already thinking about giving up LRF and even Mobi creation because it is really simple to make mobis and LRFs from the epub files but I think that it would be quite rude to oblige people to convert their books to their preferred format themselves. So as long as there are no bandwidth limits, I will provide those formats. See, we could tell our friends that want IMPs that they could make them easily themselves by downloading mobis and converting them with Nicks wonderful Mobi2imp, but we don't, do we? I think of it simply as a service, I guess. |
|
01-12-2009, 01:19 AM | #55 | |
book creator
Posts: 9,635
Karma: 3856660
Join Date: Oct 2008
Location: Luxembourg
Device: PB360°
|
Quote:
|
|
01-12-2009, 01:52 AM | #56 | ||
GuteBook/Mobi2IMP Creator
Posts: 2,958
Karma: 2530691
Join Date: Dec 2007
Location: Toronto, Canada
Device: REB1200 EBW1150 Device: T1 NSTG iLiad_v2 NC Device: Asus_TF Next1 WPDN
|
Quote:
Quote:
It doesn't mean that, in the future, when and if () my reader gets a firmware upgrade to allow native reading of .epubs, my tune will change. Then I would expect my reader's conversion software to take a perfectly healthy .epub (i.e. no ADE limitation) and then convert it to my reader's required (and maybe somewhat compromised/crippled) support for .epubs. Again my view is skewed in that I view .epub as a source and not for utlimate reading on my reader yet. If I did have a Sony reader capable of viewing .epub ebooks natively, the question I would have to wrestle with is would I want (1) the convenience of a Sony-specific .epub variant over (2) a non-compliant Sony .epub that I would need some software (like Calibre) to re-generate the .epub so that my Sony reader could read it. My answer, would be a resounding endorsement of convenience over a "higher good", but the fact remains that in the foreseeable future the "higher good" can take a back seat, but not for the long haul. The hardware will catch up and the present day .epubs will be viewed in a different light. So do I want the current situation to change? No, but I would want the imposer of the limitation (ADE) to eventually remove that limitation (or raise it sufficiently higher so as to not be a "hinderance" to the way ebooks are scripted in .html). For ebooks with numerous chapters of limited size, this limitation is a moot point. For huge hyperlinked ebooks, like the kind I usually prepare, I just can't appreciate that my source .epub will be in a 100 or so pieces. I don't know, maybe it's just me, but I like to work on the whole rather than the parts. Perhaps, in my perfect world vision, I would like non-compliant Sony (non-split) .epubs to be the norm and then let every ebook reader (BeBook/Sony/iPhone) that can't handle it to re-generate their variant of that .epub ebook (even if it is .lrf for the Sony-PRS500 or .imp for my reader or .prc for the Cybook Gen3/Hanlin/iLiad...). I told you it was a RANT! Last edited by nrapallo; 01-12-2009 at 10:21 AM. Reason: typo |
||
01-12-2009, 09:12 AM | #57 | |
Wizard
Posts: 3,671
Karma: 12205348
Join Date: Mar 2008
Device: Galaxy S, Nook w/CM7
|
Quote:
For me this is only proof of how poor the ePUB spec is. Here is a committee that knows that the majority of their eBooks market are viewed on embedded devices, yet they make no provision for them. Either include them or exclude them but make it clear in the specification. I'm not saying "X" plaftorm can/can't run ePUB. But address the issue by stating what kind of memory is required. And have provisions in the spec for devices that have limited hardware constrains. Another huge gaping hole in the ePUB standard is no one solution for DRM. Maybe that is wishful thinking on ePUB side that DRM will go way but it's here and real. This means more vendors aside from Adobe can spring up with their own DRM solution. Which means buying a book from one vendor will most likely not work with another. How open is that? So now as ePUB consumers we now have to worry about what hardware we buy in addition worry about what DRM the book is using. Arh what a headache. I've said it before and I'll say it again. I cannot get exited over ePUB it is a GREAT idea that was poorly executed. Right now where ePUB stands today is not a valid open solution but yet another tower. So with that said ... I'll stick to MOBI and LIT where I know the eBooks I buy will work on any platform they support. =X= |
|
01-12-2009, 09:19 AM | #58 | |
Reticulator of Tharn
Posts: 618
Karma: 400000
Join Date: Jan 2007
Location: EST
Device: Sony PRS-505
|
Quote:
Every other e-book format that I know the details of contains features which explicitly simplify seeking and incremental rendering. LIT compresses book content in 64k chunks, allowing random-access to compressed data; it contains an index of all explicit page-breaks within the book content; and it uses a simplified CSS rendering model without context selectors, allowing accurate rendering of an element given only its parents. Mobipocket compresses all ebook content in 4k chunks; and it uses a single-level rendering model, allowing rendering with almost no context. In contrast, EPUB: (a) only allows compression on entire file streams; (b) contains no indices aiding incremental rendering; and (c) mandates a rendering model which requires full file context. For example, EPUB allows a file which looks like: Code:
<html> <head> <title>Example</title> <style>.first ~ .last { display: none; }</style> </head> <body> <p class="first">Displayed!</p> [50 MB of content] <p class="last"> Not displayed</p> </body> </html> So unfortunately EPUB / the OCF needs some sort of arbitrary limit on the size of markup streams. It's the simplest solution to the problem without ditching the entire OCF and creating a completely different container format from scratch. I'm hoping that such an explicit -- if yes, somewhat higher -- arbitrary limit will eventually become part of the specification itself. |
|
01-12-2009, 09:27 AM | #59 | |
book creator
Posts: 9,635
Karma: 3856660
Join Date: Oct 2008
Location: Luxembourg
Device: PB360°
|
Quote:
|
|
01-12-2009, 09:30 AM | #60 |
Wizard
Posts: 3,671
Karma: 12205348
Join Date: Mar 2008
Device: Galaxy S, Nook w/CM7
|
@llasram exactly the point (the first point) I was making, but you said much more eloquently.
Last edited by =X=; 01-12-2009 at 09:32 AM. |
Thread Tools | Search this Thread |
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
EPUB Expert Needed: Cant properly export epub from InDesign | crottmann | ePub | 17 | 08-27-2010 10:23 AM |
epub, ePub, EPUB, warum blos ePub? | flowoeB | Lounge | 5 | 11-27-2009 09:37 AM |