ePub3? You mean because of the thousands of ebooks using it? Yes, you should probably really adjust your resources...

Like MegaReader (other competitors created mostly by a single developer, not a company, being left out here), you're losing ground with readers, Micah. This may be acceptable for you because your primary business model seems to consist of selling re-branded Blurefire readers and (re-)selling Adobe SDK licences but you should be well aware that people *do* complain to the companies you've licenced Bluefire to, e. g. libri.de. Of course, for some time, those companies will ignore those complaints but if they actually start losing business due to it, they'll re-evaluate their choices.

Well, we spend everyday, all day, working hard to make our apps better. Doing the best we can. I'm proud of what we've accomplished, but certainly much work to do. By the way, implementing EPUB3 support is a *HUGE* project. Apple's policies on browser engines and Android's fractured browser landsacape make it that much harder. We are working through that...

I've never seen a piece of software that people don't complain about. But I hear you that there is huge pressure on us to match reading systems being made by companies investing many millions. A challenge for a small, bootstrap company for sure.

But, I think we are actually doing a pretty damn good job given the situation. Never good enough, and we need to constantly strive to do better.

In any case, thanks for the constructive criticism. I'm listening.
-Micah

Micah, while I have too many severe issues with BFR to use it, I really appreciate your clear, honest statements here.

I know a bit about the challenges working with the Adobe SDK and I can imagine how things are for a startup (and remember how it was working for one myself, sometimes even sleeping in the company :-) ).

I've parted ways with BFR and may not agree with some of your decisions and priorities but I honestly wish you and your company the best of luck.

Implementing a native code OPDS catalog support feature is on my wish list for 2013, but is a bit low on the list, and there's some big ones before it like full EPUB3 support. So I can't really give you a definitive answer, as we are constantly adjusting where we spend our limited resources to stay in business.

IMHO, don't bother with ePub 3 yet. It's a waste of your time. It's not supported enough and probably won't be as long as the multimedia features are in the specification. And it won't be supported until ADE is updated to handle ePub 3 and every version of ADE is then updated to an ePub 3 capable version.

In regards to feature priorities and making Bluefire Reader better. Here's a recap of recent work, and a list of the things we are working on right now.

We initially released Bluefire Reader for iOS in fall of 2010. In fall of 2011 we released Android.

Here's stuff we did in 2012:
Support for the new iPad Retina display
Support for the new iPhone 5 screen size
Support for iOS6
Support for multiple concurrent user accounts (Adobe ID’s and Vendor ID’s)
Single Sign-on option for Vendor ID customers
Improved PDF performance and reading experience
Support for system fonts, a feature that enables more reading settings and enhanced rendering of ePUB formatting
Online dictionary look-up
Support for external hyperlinks in ePUB and PDF titles
Streamlined highlighting (bypasses Notes panel)
Sharing via Facebook, Twitter and email
Contextual ebook text search results
Collections (iOS only)
Swipe for brightness control (iOS only)
Enhanced side-loading (iOS only)
Annotation export (this one is particularly cool)
Support for Chinese, Japanese and Korean text, including vertical writing and right-to-left page order and Japanese Typography (e.g. Ruby, Kenten, etc)
Enhanced Sign-in workflow

The Asian language features noted above required implementation for support of several specific elements of the ePUB3 spec.

We also contributed to the Readium project in 2012. Readium is an IDPF sponsored open source epub3 reference web app that runs in the browser.

So far this year we've released updates on iOS and Android:
iOS - improved cover image generation, and much better support for large libraries of books (better memory management, smoother scrolling in Library, etc)
Android: lots of stability and performance work was done. Still much work to do, and another release coming soon with more.

Here's what we are working on now:
Adding Pinch/Zoom on images in EPUB
Read Aloud and other accessibility related features
New Web service and app features for syncing location in ebooks across multiple devices
Windows versions of Bluefire Reader
Full EPUB3 support
Other cool open source projects (announcements on that coming in the near future)
Better library loan handling (e.g. show expiration dates in Library views, sort by expiry, Borrowed auto collection, offer to delete when returned or expired, etc)
Better text selection interaction (particularly on Android)
More responsive anchor link interaction
other stuff coming (e.g. revamp of Android UI, Native code OPDS renderer, etc)

The "to do" list is really quite long. Some may disagree with how I've prioritized. Fair enough. Always trying to be smarter about it.
-Micah

Your telling this to a company that is TRYING to support it?? If we target all the companies that are trying to implement ePub3 support, and tell them not to support it because it isn't supported well enough yet....

Ohhhh, the circular logic is making me dizzy!

If you were addressing an ePub creator, and telling him not to create an ePub 3 because the device/reader support isn't there yet is one thing....

I understand you don't like the media support in the spec, but if they (as a company) have plans and priorities that include implementing the standard (which has been around for over a year) then who are we to tell them not to?

Text selection in iOS is a lot better than on Android. It is a tricky thing to implement as the rendering engine we use (RMSDK) generates images of pages, rather than "live" text. So when selecting text, we are actually calculating what words are under your finger, and then updating the bitmap of the page to show a highlight. We will be making it better on Android this Spring. Curious which device you were talking about?

Quote:

Originally Posted by Micah

PDF can be very problematic for text selection. Really depends on how the PDF was contructed (varies *hugely*) Sometimes what looks like text is not actualy text, other times there are no "space" characters between words. Also, RMSDK (our rending engine) only supports the PDF/A spec - other PDF's will often/usually at least render most text, but selection can be problematic in that case too. Are you experiencing this with EPUB or PDF?

Text selection in our app is acheived in a very different way (custom code) than in most iOS apps that leverage Apple iOS API's. This relates to our ability to support DRM (decryption). Some folks find it easy, others find it annoying - in particular due to the differences in the way it works from other apps. Worse on Android at the moment, which is high on our list to improve.

Thanks for the answers, Micah. Like I mentioned, I was talking about both iPad 3 and iPad 1, and I wasn't talking about PDFs but about ordinary EPUB books where I seem unable to highlight text properly. I can twist and turn my finger in all sorts of ways, but it's just not happening. Selecting text everywhere else in iOS is effortless for me. Meanwhile, I have upgraded to iOS 6.1 on iPad 3, and the issues are just as severe as before. Right in the default EPUB offered by Bluefire, Treasure Island. I can shoot a video if you don't believe it's impossible to select text properly here.

At least, what you say above definitely confirms my impression that text selection in Bluefire Reader works very, very differently from the way it works elsewhere in iOS. Unfortunately, the change is for the worse. It's a show-stopper for me, but there are others. For example, there is no possibility to adjust paragraph spacing in Bluefire Reader, something that my fellow MobileRead posters know I'm obsessed about. And you mentioned you're proud of the annotations feature in Bluefire -- and I agree it's pretty fine, but take a look at the same annotations feature in Marvin, and it blows your implementation out of the water. Things like export/import/restore/sharing of annotations don't exist in Bluefire, nor are there any annotations of multiple colours (very useful for me).

The best of luck to you, and I hope all the e-reader apps can continue inspiring one another, each striving to be better than the rest.

@Faterson,
Yes Marlin is truly awesome and impressive. They are solving very different problems than we are in many ways e.g. DRM, library lending, digital transition for retailers, etc. And currently they are focused on iPad only vs iPhone and Android devices as well (though I hope they get there - the more the merrier).

It is not clear to me yet what their revenue model is, or how they are funding development. Do you know? I'm guessing they are venture funded, but I've found no real info on them. Startups with no revenue model often end up either spamming users or selling their info - I hope that does not happen here. The app reminds me a little of Readmill and Subtext both of which I also like quite a bit - for different reasons. Though the angle and business models are fairly different there as well.

Though of course, with any reading system, there is tons of overlap in terms of what makes for immersive and "active" reading. That said, I think we'll see a lot more specialization of reading system apps moving forward. There's just a massive spectrum of potentially useful features that developers have to prioritize, and the mix will vary a lot based on audience, business model, subject matter, etc. e.g. apps for education are likely to focus on different features and UX than for trade retail.

There is no doubt that our particular business model (b2b) means very different priorities and focus than what appears to be going on with Marvin at the moment. But then, given that we do already have a revenue model, and operate in the black, means we'll likely be still plugging away at this for years to come, (I hope) and constantly making the apps better. I expect to see many of the current crop of ereader apps from venture funded startups dissapear in the coming years, or get folded into larger companies - like Stanza at Amazon - which did not turn out all that great IMHO.

FYI, when we originally launched in 2010 our business model was affiliate revenue from OPDS catalogs in the app. Apple put the kabosh on that in early 2011 when they, er, "clarified" their policies on outbound links in ebook apps - coincidentally at the same time they launched iBooks. It was devastating. But we adapted and pushed through. Never a dull moment in ebook land.

Again, I don't know much about the Marlin folks other than that they do some great work. I hope they keep it up. Like you said, there's nothing better than healthy competition to inspire innovation.

Back on the topic of text selection, I hear your frustration about the responsiveness and how it varies from the standard iOS API's. I've a few ideas on how to make that better, and we do plan on experimenting to see how that might work. Also, EPUB3 will use a very different rendering strategy, and we'll be better able to leverage native API's.

Your telling this to a company that is TRYING to support it?? If we target all the companies that are trying to implement ePub3 support, and tell them not to support it because it isn't supported well enough yet....

Ohhhh, the circular logic is making me dizzy!

If you were addressing an ePub creator, and telling him not to create an ePub 3 because the device/reader support isn't there yet is one thing....

I understand you don't like the media support in the spec, but if they (as a company) have plans and priorities that include implementing the standard (which has been around for over a year) then who are we to tell them not to?

I'm not saying not to support ePub 3. But until ADE does, it's a waste of time. The problem is that ADE is the most used ePub reading software there is. It needs to support ePub 3 before it's worthwhile. If we have apps like Blufire supporting ePub 3 before it should be supported, then we'll get people making and releasing ePub 3 and that will do more harm then good as it will fragment eBooks. yes, I have an iPhone 5 and an iPad 1. But the point is, I want eBooks that I can read on these devices or my 650. I do not want to be forced to have to read on the iPad just because someone thought ePub 3 was a good idea when it's not.

I thought innovation and commercial competitiveness were what we wanted with multiple readers/devices. If no company develops support for epub3 because ADE doesn't support it yet, then there will NEVER be support for it. On the other hand, if a company, like Bluefire (nod to the thread we are on) develops support for it and they start attracting a goodly portion of the clientele, then other companies will take notice, and develop it themselves. Someone has to be first!

Usually the first one to a market keeps a large portion of the clientele that the new market developed. The latecomers have to be REALLY innovative to entice those clients away from "what they are used to."

I thought innovation and commercial competitiveness were what we wanted with multiple readers/devices. If no company develops support for epub3 because ADE doesn't support it yet, then there will NEVER be support for it. On the other hand, if a company, like Bluefire (nod to the thread we are on) develops support for it and they start attracting a goodly portion of the clientele, then other companies will take notice, and develop it themselves. Someone has to be first!

Usually the first one to a market keeps a large portion of the clientele that the new market developed. The latecomers have to be REALLY innovative to entice those clients away from "what they are used to."

ADE is the one that has the DRM. The problem is that without the DRM, a lot of publishers won't go for it. So if ADE doesn't do it, it won't happen no matter how many apps get ePub 3.

It appears that blufire as a company disagrees (as do I). I suppose we will see as time goes by.

I kind of agree - with both of you. But if we do a good enough job on desktop apps, (plan to) ADE won't be *as* important.

And in the mean time, we have customers that are very specifically focused on distributing to mobile.

ADE supports a subset of the EPUB3 spec now, and most EPUB3 files should (somewhat) gracefully degrade in terms of the unsupported features (e.g. text an images are fine, but video won't display).

That said, there will be major challenges for the transition to EPUB3 - for consumers, retailers, and publishers alike. Ah, the joy of progress.

But for sure, EPUB3 is not our sole focus, as there are a lot of other important things to do at the same time, and EPUB3 adoption by publishers will take a while, both on the back-end and related to uneven client app support. That and Amazon may well never support it fully, even with Kindlegen transformation.

People make hay about he spec being done for a year. How many years did it take for browsers to have great, and consistent HTML/CSS support across vendors? Some would argue they are not even there yet.

What is currently driving EPUB3 is mostly fixed layout format, and that's because Apple won't accept PDF's for iBooks (for things like children's illustrated books). And while pubs would prefer to distribute one format, they'll need to distribute PDF as well to some channels for some time to come. Luckily, generated multiple different "fixed" formats is a lot easier than making great reflowable content.
-Micah

But can you make a fixed format ePub 3 that would work on say a nook tablet, iPad, iPhone 5? Differing screen sizes/resolutions/aspect ratios is what you have to overcome in terms of fixed layout. Is this even possible?