AZARDI - free ePub Reader is Released

Our new free ePub Reader, AZARDI, is now available at this download location. We are running a week later than we had hoped, but hey, it's free, and a week ain't so bad in terms of software projects.

There is extensive information on the why's and wherefore's of AZARDI on the main website. Make sure you check it out to see where this application is heading.

Meanwhile if anyone would like to give feedback, this blog is the place to do it.

Comments

[Laisvunas]

Hi,

Just tried Azardi and even at this stage of development it seems to be more usable than Adobe's Digital Editions. Congrats.

Still, I have some critical remarks. It seems to me that the solution to develop desktop Epub reader based on Qt is a fundamental architectural mistake. Epub is HTML based format. This means that almost every element of browser's GUI - tabs, toolbar with Back/Forward/Home buttons, History, Bookmarks, View Source, right-click menu options, addressbar with search functionality (awesomebar) etc. is a relevant feature of a usable Epub reader. If you strive to develop really good Epub reader you will need at some stage to implement these browser-like GUI features; and this means huge amount of work.

But is really needed this implementing of browser-like GUI features? - No, because Epub reader can be based on some quality Open Source browser. There are basically two options here: either to develop Epub reader as browser's extension (as in OpenBerg project) or to take Open Source browser, add to it Epub reader functionality and release under a new name. In both cases you will get a quality reader with every browser GUI element in place.

Unfortunately OpenBerg project died silently - no version compatible with Firefox 3 were released. It seems to me that instead of creating a Epub desktop reader based on Qt you would be better to revive OpenBerg project. It would require much lesser amount of work and resulting application would be much more usable and powerful. If you do not like idea of Epub reader as browser extension, then you could release Firefox browser (under a new name) with Epub reader extension preinstalled.

[Richard Pipe]

This is a "way early" release. We are still gaining experience in Qt, and its limitations (EG. no OTF fonts at present) and are going to be constrain here and there. But for our own use, we do need multi-platform (Linux/Win)desktop. One gentle correction, we are not using Qt in HTML mode, but converting the mimetypes to XHTML (XML not SGML), which an environment like Qt allows us to do. This is of course essential for compliance, and for all the XML stuff to work as XML.

We will shortly be posting test pages which work in XHTML, but not HTML. A common example we come across for various reasons (mostly link targets) is what happens with - Good XML, , excellent XHTML, but arbitrary SGML interpretation.

We are also tracking the powerful Calibre project which uses the same environment PyQt, but with Calibre, the emphasis is on all eBook formats, Libary facilities, format conversion and sync with iPhone/mobile, more than content presentation.

I was meant to put the AZARDI project roadmap up this weekend for comments, but had a "bad weekend", and not enough discussion with Akash and Atul, the main developers who have to do the hard work. So that will come ASAP.

On ADE. Regrettably being better than ADE is not hard, which is probaby why we even contemplated AZARDI. It required about 15 minutes thinking, and six months user frustration. I agree that it is freaky that ADE doesn't have 20% of the navigation strength of a common browser. The lack of a link return button is flabbergasting, and they justify it! We get compliments on our ePubs because we provide return links from notes, and other references (bi-direction links) which shouldn't be necessary, and shouldn't be there because they can cause link loops. ePub production is being customized for Reader inadequacies and diluting the future value of the books.

We have all the issues you mentioned and a lot more in the "master plan". With search we want to go a lot further and incorporate a library search feature, not just insipid book find. While we are not going to get too fussy about "book-like" pagination, we do want really powerful navigation, and sooner rather than later user defined navigation, possibly across multiple library/book bookmarks.

Our first priority is content presentation at as close to 100% standards compliance as we can (sans Daisy at this stage). That means the package, the precise CSS support, the SVG, Inline/Out of Line XML Islands - all the stuff no one is really using - yet. The spec is ambiguous enough to require discussion and debate, and I hope we can engage with at least a few interested people. It boils down to accepted and mutually agreed test cases between interested parties.

Our ideas with library functions include full online connection with multiple libraries (including Amazons new DropBox) so books can be accessed from any reader anywhere and everywhere. This is in preference to importing them into the Reader. That will take a bit of work, but the idea is ubiquitous multi-library access with a common protocol. A little RSS in concept. Inputs welcome.

We have looked at the openBerg project, but 1) we don't have any experience in programming XUL, etc. and 2) Don't want to tie it to a single browser. The morphing to a Mozilla browser has merits which we may look at if Qt/WebKit doesn't cut it. For example we can't let browser behaviour run for SVG and objects without first prevalidating them for correctness and with the manifest - no SVG in the manifest, no show in the viewport. Them's the rules!

If resources permit, we may pick up the OpenBerg project as another ePub reading option in the future once we have a better grasp of everything, because it is a useful project that deserves to live. We debated it internally and one good aspect of Mozilla for us is the MML support, which WebKit doesn't have and probably wont have for a long time, then there is the awesome Firemath extension, and is something we want for AZARDI.

At the moment we are planning on building in a MML to SVG converter to handle this. OK, so only 1% of the eBook/ePub community may care, but addressing academic & education content is a big issue for ePub if it is going to straddle and dominate. We have to make it look easy.

We are a small commercial organization who sees the value of an amazingly good, spec driven ePub reader, rather than a user friendly one. It's the whole "who ya gonna call" scenario. Not the most popular, but there when the ghosts are in the ePub.

while there can really not be too many ePub reader options - which only help demonstrate the ubiquity of the format (and the stupidity of proprietary) - we have to evaluate the browser plug-in approach against Bookworms excellent generic-browser approach, with mobile extensions, etc.; which seems to be the way to go for those who want to access books from anywhere on any device.

Thanks for the encouragement and the comments.

[Laisvunas]

Hi Richard,

Thanks for your exhaustive comment.

Your strict adherence to the spec is right attitude. But please do not try to be more strict than the spec really is.

There are in the spec some things which are discouraged but not more than that. For example, scripting on pages of the publication. Executing of scripts is discouraged in quite strong terms ("should not"), but not forbidden (no "must not"). It seems to me that in such cases your reader should allow everything which is not explicitly forbidden. Don't be as Bookworm which can easily support scripting but does not.

[Richard Pipe]

Laisvunas,

That is a good comment I have never really heard before. "Don't be more strict....".

We will support scripting because without it we cannot support interactive books, one of the big values of education and training e-books, and probably some entertainment books. Powerful navigation/hyperlinking, interactivity, portability, modifiability - these are the e-book extenders, value adders and differentiators from p.

[Laisvunas]

Good support for scripting (javascript and I hope Flash too) would be simply amazing!

It's so rare in all discussions about Epub format and Epub readers to hear appreciation of scripting and interactivity. It seems that both the authors of the spec and most enthusiasts who experiment with format and readers are completely content with non-interactive linear content. That's of course only because good interactive scripted publications are rarity until now.

Azardi project can change this. Keep your good work.

Will wait impatiently for Azardi project roadmap.

[Richard Pipe]

Flash is a secondary issue, mainly because Qt Webkit doesn't support plugins at this time. Similar to the OTF font problem. When / if it comes we will support it. Meanwhile, because a reader is allowed to have its own strategies as long as it complies with the ePub rules, we are going to allow linking to an external resource page. At that time the Reader will switch out of ePub mode to Browser mode, with a warning flag. At present linked pages open an external browser, but we are probably going to allow pages which are in a configuration file, to open in the reader in Browser mode. This is to allow us to push the content envelope, remain ePub compliant, and get that essential interactive value add for education and training content. This will probably be a little controversial, but AZARDI is not trying to become a popular reader, but show that eContent does not have to be passive.

[bookie]

This is a nice looking e-book reader keep up the good work, looking forward for bookmarking support which seem to be the thing that is lacking in most of the readers today at least on the Linux desktop, I would also like to see a lookup feature that lets one use the gnome dictionary to define a highlighted word, a search feature would also be nice, get these in and support tables and css and i think you will definitely be among the best, I will be trying my hand at building epub books and hope this application can be used as a test tool

Finally if it is not too much to ask I would like you to develop an extension for OpenOffice.org to save a writer document as an epub book or a commandline converter for odt to epub.

[Richard Roberts]

your help info does not help in getting exisisting epub text into your reader after several hours i finally gave up and uninstalled your software i have about50 books in epub format and would like to read them so will try elseware if you havesolition please e-mail me thanks Richard

[Richard Pipe]

Richard. Firstly thank you for trying AZARDI, secondly apologies for the wasted time and frustration. Currently AZARDI has a fixed library directory in the installation location and files have to be copied there. Something like c://Azardi/library/

It's crude, but its was done like that for a purpose.
AZARDI was not designed to be a general reader and take over the world, but rather be a reference reader for difficult and challenging content. I will try and clarify that on the download page in the near future.

Our rather slow development map is a larger library system to handle local, network and internet locations. This is currently going a bit slow (read standstill) as the development team are up to their necks in other work. We are trying to get dedicated resource free as soon as possible.

[Richard Pipe]

AZARDI has been used to work in conjunction with eScape and IGP:FLIP. It supports tables and CSS to the extent the Webkit engine does - which is the whole thing. The problem with advanced CSS techniques - as allowed by the spec, is not all readers are as far along. AZARDI is a scrolling/paging reader and doesn't try to do a page render. This is deliberate because as books become more complex and sophisticated, images and layout look terrible on arbitrary pagination.

It is not possible to create an extension to go directly from Open Office to ePub sensibly. If you use eScape, it puts one little step in between the Open Office file and the output. If you use IGP:FLIP - try the sandbox, you can create e-book master pieces.