At Internet Tablet Users blog, I’ve posted a short and a long version discussing how the combination of the 8-ounce Nokia 770 Internet Tablet — with its 800-pixel-wide super-high-resolution screen — with FBReader is the best-ever e-book reading experience. Of course, some may dispute that conclusion.
In a private communication, Jon Noring points out that FBReader can’t provide multiple paths through a book, facilities for which were first laid out in the Open eBook 1.0 specification in 1999. Nor does it offer “out of spine” rendering, such as separate pop-up windows for footnotes, as Microsoft Reader has since its inception.
Jon also is eager for a standard e-book format that expands to include MathML and SVG, and features such as a required table of contents to provide for greater accessibility. With a text-to-speech engine being ported to the 770, portable “talking books” are not too far in our future. Jon doesn’t believe FBReader leads us towards the real potential of e-books. That’s why he’s pushing the Open Reader format, and for e-book reading programs to provide this sort of capability.
I myself have wanted Flash-like animation capabilities since 2000, when I joined the OEBF, paying my $1000 membership fee out of my own pocket simply so I could lobby for that provision in the publication structure spec. And I don’t disagree with Jon’s assessment at all.
It’s simply that FBReader on the 770 provides the biggest screen and best color display and most words on a page of any e-book reading program on a non-e-book-only device. It lets you choose any font you want for reading, specify font sizes in third-of-a-point increments (eg., by pixels that are 1/225th of an inch in size), set margins by pixel size, and use different specs for every structural element (title, text paragraph, footnote, quote, etc.) in your book.
To quote myself in that long version mentioned above, “When you control the precise size of the type, and the font, and other subtler aspects that affect your visual appreciation of the text on-screen, there’s a tremendous personal gratification. (You probably recognize the opposite feeling, the one you get when you go to a website and just feel utterly antagonized with the small typesize or noisy design or some other unreadable and unchangeable aspect.)”
So I think Jon and I are both right. FBReader is the best we have, and it pretty much maximizes the experience of single-path formatting. FBReader can’t handle OEBF-style documents, but it’s open-source software — all it lacks is a committed programmer to add that capability. And it handles Russian and Chinese so it’s already got a better international scope than any other free-standing, multiple-device program.
I don’t dislike dedicated e-book readers, and some good ones look like they’re coming down the pike. (I wonder which ones have the OEBF multiple-path, out-of-spine capabilities?) However, just as a super-nice handheld computer like the OQO is too expensive for me to justify (old model’s lowest price: $1300), I feel that $300-plus (the Hanlin, the Librie, the Cybook, and I’d guess the iRex too) for a device that doesn’t do anything else is out of line, and thus not for me.
But your mileage may vary.
I agree wholeheartedly with Roger’s comments.
We have to differentiate between an ebook format, and the reading system (hardware+software) used to display that ebook format.
I’ve not tried the FBReader reading system — I look forward to trying out the Nokia 770 — but knowing Roger, I trust his judgement that the FBReader reading system does what it does very well (the screen shots are intriguing) and incorporates nifty features that improve the reading experience for the end-user. Of course, the reading experience is aided by the Nokia device itself, as Roger has noted.
My private comments to Roger were focused more on the underlying format as I understand it (I assume it is the FictionBook 2.0 specification.) My focus is on the future of the digital publication industry — what is the best design approach for a “universal” digital publication format. The long path in studying the issue led me in 1999 to the OEBPS framework specification (which I’ve contributed to for several years now), and then to the OpenReader framework which essentially is a “next-generation” OEBPS, fixing several deficiencies in the already six year old OEBPS spec.
It is disappointing that FBReader did not embrace the OEBPS paradigm, but rather took a different approach, which appears to place everything, including metadata, style sheets and encoded images, into a single XML document (and if my observation is correct may infringe on a Microsoft patent.) Granted, the name of the format, “FictionBook” implies that it is not intended to be a more general format and so focuses on simpler structured documents. On the positive side, the markup that is used (which appears heavily influenced by TEI) is better than XHTML for structuring book documents — it even has markup to support verse (poetry).
At first glance, I do believe it possible to readily convert a FictionBook 2.0 publication into a simple OpenReader Publication (and vice versa.) I’m even intrigued with OpenReader providing native support for the FictionBook 2.0 vocabulary since one goal of OpenReader is not to be stuck to XHTML but to support other and better vocabularies for structuring digital publication documents. So I look forward to talking with the FictionBook and FBReader folk to discuss this possibility.
Roger,
Your message seems to be conflating three different things: 1. the eBook format; 2. the display features of an eBook application; and 3. the hardware capabilities of the platform upon which the eBook application is running. It might be helpful to break out the requirements for each of the three, and lobby the appropriate venues for the features of each you want. I’m not suggesting you haven’t done this, but the above message makes it sound like it’s all of a piece. This reminds me a bit of the arguments heard in HTML circles (which come originally from SGML circles) about separating content from presentation, though in this case it’s also about the hardware — a lot about the hardware.
At some point when I have a budget I’d like to get my hands on a Nokia 770, and at some point when I have a bit more time I’d like to participate in discussions with Jon and others on the markup of the OpenReader XML format, as its success will have a lot to do with how well it supports the features of a really functional eBook reader application. When Jon feels he has the time he should ping me and we can perhaps get a start on it, if he’s interested.
oh please, let’s not let jon noring decide
what an e-book should and should not do.
multiple paths through a book might be
a useful gimmick, but it certainly hasn’t
been a “requirement” for paper-books…
and it’s not as if it can’t be implemented
in any number of ways, not just jon’s…
likewise can we scrutinize everything else
that jon wants his “superformat” to do…
i wish jon the best of luck in his efforts to
bring the world the kind of capabilities that
he wants e-books to have. but to hear him
dissing other people, because their vision is
different than his, strikes me as eminently
counterproductive, in the extreme…
_especially_ when jon’s vision is still vapor.
bring a format to market, jon, with
a viewer-program and authoring tools.
_then_ do your hype and marketing.
if you way really _is_ cost-effective
— which i highly doubt — it’ll catch on.
-bowerbird
While you are right, Murray, there is the point that someone working on FBReader has to implement the capability to read some format and to make the program work on a particular platform and device.
FBReader can take a file in the following formats and render it:
– fb2 e-book format (style attributes are not supported yet)
– html (sans tables)
– Plucker (also sans tables)
– Palmdoc (aportis doc)
– zTxt (Weasel format) and
– plain text format
I have files authored in OEB 1.0 that I can put into free and commercial converters and create a file in Microsoft Reader .lit format to be read on a Windows box (and guess what — Microsoft funded their creation). I wish I could take the same source file (or set of files) and create something akin to the lit file which FBReader could display on a Linux box — but someone from the FB2 or FBReader side is going to have to make that happen.
(BTW, that was the real dream of the Open eBook Foundation — to create a single format that could be converted easily into files for specific readers on different platforms. The OEB spec is for a publisher’s format, not a distribution/reader’s format. OpenReader, on the other hand, seems to be a reader’s format.)
So, would I like FBReader on, say, a PocketPC as much as on a Nokia 770? No, clearly not. On the 770, FBReader rocks and that’s a function both of the hardware, the controls within FBReader and how well FBReader exploits the system it’s on. And is it FBReader’s fault that no one has written a converter from OEB to FB2 or to Plucker format? Well, not really, but it would be an even better program if the developers could read an OEB file directly, as two now-defunct programs did. Barring that, they or some like-minded programmers could build a converter from OEB to a FBReader-accepted format. That might be the best of all possible worlds, one source file converted to a compatible format for a Linux reader, and converted to a different format for a Windows reader, without requiring the Linux or the Windows developers to cross platforms.
In the end, as you say, the reading experience is all of a piece. (You sort of say that, anyway.) And I don’t know where to pull these pieces apart. So, I’ll repeat myself in pointing out that the combination of FBReader’s display controls and integration with the Nokia 770 and its fabulous screen (and other capabilities) make for the best reading experience around.
.pdf? that format won’t go away soon. if at all.
.html? same thing there. a huge installed base.
.ascii? well, it will always be with us, won’t it?
plucker? as long as there are pda’s, plucker lives.
if you really want “one-file format to rule them all”,
the proponents of that file-format are simply gonna
have to create converters to/from all other formats.
either that or convince everyone in the world to
create content in a format that you can convert.
in the meantime, it’s a joy to see a program handle
such a variety of formats. too bad it ain’t cross-plat.
-bowerbird
rocketbook? now burning into its second stage.
mobipocket? as deep as amazon’s deep pockets.
oeb? already deprecated by openreader, isn’t it?
openreader? will live forever and over, won’t it?
what? openreader hasn’t even been _born_ yet?
no! say it isn’t true! surely you must be joking!
david rothman has been hyping it for years now!
(almost 2 years now, to be exact, which makes it
1/3 as old as the o.e.b. format, which now requires
an update to a “next-generation” format. funny, eh?)
-bowerbird
Bowerbird is certainly on a roll! Hopefully he can define the word “diss” to see if that is an accurate description of my first comment above. I invite him to point out exactly where I “diss” FBReader/FictionBook 2.0. (Well, maybe in what Roger conveyed in his original message — but pointing out problem areas in another format, when backed up by reasons, is not “dissing”. In general, the word “diss” is used to obfuscate rather than clarify.)
Also, I vaguely recall another ebook format being touted for almost 2.5 years, called ZML (for “zero markup language,” now called “Zen markup language.”) Hopefully Bowerbird can give everyone an update on when we can expect to see “ready for prime time” ZML authoring and viewing applications. Also, how many publishers, authors, and end-users are excited by the potential of the ZML format and waiting with bated breath to give it a test drive? How many people are helping Bowerbird with the ZML initiative? Is it a SourceForge project yet? Will the codebase be open source, donated to the public for the public good? For one of the first announcements of ZML, refer to this TEN article on Topica. Why Bowerbird has been silent recently on ZML, especially in light of this discussion where I would assume he would be proud to bring it up as a better alternative, is mysterious. Maybe he doesn’t want to brag, which is noble, but that doesn’t help him nor anyone else.
Certainly, anyone can talk about formats. Bowerbird is right: talk is cheap. But it is definitely useful and important to discuss what an ebook format can and should do. It is beyond strange to go ahead and build an ebook system (like ZML) without first studying and understanding if the underlying format will enable the many needs, present and future, of both publishers and end-users. In turn, this requires understanding what they need — public discourse is one tool to ascertain this.
Sure, the ultimate arbiter of the value of a format is whether it is embraced, which in turn requires proper, real-world demonstration that it indeed meets needs. But to blindly charge ahead with some format (e.g. ZML) without fully understanding the needs of both publishers and end-users, is likely to lead nowhere. It’s like building a bridge where no one bothered to survey people whether it will be used enough to justify building it in the first place. The road is littered with all kinds of “apps” that no one ever used, because the developer did not bother to understand the potential user base and meeting their needs. There is value in understanding the important requirements before embarking on a particular path.
Now, Bowerbird may reply that he did do this study, and that his system will meet publisher/author/end-user needs. But he certainly is not demonstrating that he has done this study and cogently explaining his conclusions — he does not say why and how. Nor does he mention how his system will integrate into many publishing work flows. He does not mention what types of publications it will work on and what it won’t work on. He is silent on accessibility requirements, international requirements, multimedia capability, mathematics and vector graphics support, intra- and inter-publication linking, and a host of other important, real-world considerations. This may be an incorrect characterization and I invite him to clarify, but I believe he does not consider any of these important, maybe because, in my estimation, ZML cannot fully meet (if at all) these various requirements. So, if they can’t be met with ZML, then they must not be important!
Ultimately, I hope that Bowerbird will return to a more civil tone rather than just “dissing” others. I am trying to maintain a cordial and informative discussion (as best I can) to benefit others — but all others hear from Bowerbird is static, rather than providing useful, positive and interesting insights which will help others gain a better understanding of the various issues at hand regarding ebook formats, and what publishers, authors and end-users would like to have.
And Bowerbird should consider submitting an article about ZML to the TeleRead blog (which will get much wider coverage than on Bowerbird’s blog). I think if it is well-written, and argues for ZML rather than argues against other formats, that it will be well received by many.
Anyway, to close out this reply, echoing what Bowerbird said the last time I politely requested he focus on rational and objective discussion: “have a good day!”
jon said:
> pointing out problem areas in another format,
> when backed up by reasons
the “problems” that jon has “pointed out”
— the absence of a “tours” feature and
“pop-up” notes, combined with an inability
to read a vapor format — if i read ’em right,
are not really “problems” except for jon.
besides, i’m sure that the fictionbook format
_could_ support those features, if it wanted,
but the programmer just hasn’t included them.
that’s no call for criticism, though. very few
e-book viewer-programs have these features.
further, since fbreader is open-source, jon can
“solve” those “problems” himself, if he wants.
i don’t have a nokia770 to know how well this app
works, but to my eyes, as an e-book programmer,
it appears to be highly capable. and roger loves it.
so why not give the programmer a pat on the back?
why go out of your way to point out what it won’t do?
there will be lots of time to suggest improvements.
for now, why not just applaud the progress made?
anyway, jon, thanks for giving my poor blog a link.
with a half-dozen posts in the past year, it’s pretty
pathetic. maybe i’ll start using it more in 2006…
if people really want to see what i’ve been writing,
a better place would be the “bookpeople” listserve —
http://onlinebooks.library.upenn.edu/webbin/bparchive
— where blissfully, openreader is discussed very rarely.
i’ve probably made 100+ posts there in the last year,
many of them long, so there’s lots of bowerbird there.
as for z.m.l., there’s no need to discuss it in this place,
thank you very much. it’ll be coming out of beta soon,
and people who want to discuss it will have the chance.
but i will say that i have done _extensive_ research
on the feature-set, as jon knows, which is offered at:
> http://onlinebooks.library.upenn.edu/webbin/bparchive?year=2004&post=2004-01-08,3
i have even boiled it down to an actual test-suite,
which you can see in its plain-text form at this u.r.l.
> http://snowy.arsc.alaska.edu/bowerbird/test-suite/test-suite.zml
and then view in an .html form at this u.r.l.
> http://snowy.arsc.alaska.edu/bowerbird/test-suite/test-suite.html
this .html is of “first-draft” quality only, but gives people
an idea of how zen markup language is able to transcend
the monosized-and-monostyled format of plain-ascii-text
to deliver typographical niceties such as big bold headers,
a hotlinked table of contents, hotlinked footnotes, and so on.
another example, for “alice in wonderland”, is given here:
> http://snowy.arsc.alaska.edu/bowerbird/alice01/alice01/alice01.zml
> http://snowy.arsc.alaska.edu/bowerbird/alice01/alice01/alice01.html
> http://snowy.arsc.alaska.edu/bowerbird/alice01/alice01/alice01.pdf
you’ll note this one includes a .pdf as well. like the .html version,
the .pdf was generated with one click of a button from the .zml…
letting writers write without the hassle of doing heavy markup
is the hallmark of zen markup language, and it’s an idea whose
time has come. we’re seeing it on wikis, in blog software, and
all over. there’s very little room for heavy markup in the future.
if anyone is interested in working on an open-source effort to
bring markup-free writing to the masses, i’d encourage you to
join up with jon gruber, over at http://www.daringfireball.net
in his “markdown” project. lots of good people involved in that,
including remarkable boy genius aaron swartz (now college age).
as for my being “rational” and “civil”, i think i _am_,
although it’s fairly tough to appear positive when one
is continually having to combat the rosy glow of vapor,
which is usually my objective here in teleread comments.
i mean, really, haven’t e-books endured _enough_ vapor?
i think most readers see this as honesty poking through,
and not the big bad bowerbird picking on noring/rothman.
but you can take a deep breath now, jon. i’ve got to
get some work done between now and the year-end,
so i won’t be bothering you here for a little while. :+)
have a nice day! and a happy holiday season!
-bowerbird
oh yeah, please convey my hearty congratulations
to the fbreader programmer for a job very well done!
-bowerbird
Bowerbird, one small comment; you mention, in your zml document, that “ebooks don’t need hyphenation”. That’s only true if you’re writing in English. In Russian (and possibly other languages), hyphenation *is*, indeed, a requirement – so you might want to consider how your format will handle that.
LM
larisa said:
> In Russian (and possibly other languages),
> hyphenation *is*, indeed, a requirement –
> so you might want to consider
> how your format will handle that.
larisa, thanks for making this point…
i was referring there to end-line hyphenation,
where a hypen is artifically injected into a word
to split it across lines. not “required” hyphenation.
and my format will handle hyphenation;
it’s just my recommendation that creators
steer away from it in the first place, since
there are better ways to get tight lines
when you are doing the layout on the fly.
but this is not the place to discuss z.m.l.
this thread really should be directed back to
roger’s main point, which is that fbreader is
an excellent e-book viewer-app on the nokia770.
-bowerbird
May I say this; I think the developers should be able to read an OEB file directly. Why not build a converter from OEB to a FBReader in conventional set-up? Thanks.