Re: [ebook-community] IDPF and multipart/related
- Bill Janssen wrote:
>> Unfortunately, IE and Opera are the /only/ browsers that supportThis is a perfect example of how personal biases effect design
>> parsing=20 and displaying MHTML.
> And 80% of the world's browsers, to start with, is bad?
decisions. Apparently you are comfortable reading e-books in a web
browser while sitting at a desktop computer, and therefore believe that
everyone would be comfortable doing so. To me, reading books in a web
browser sucks, and reading while sitting at a desk sucks even more. I
think just about every journalist who has commented negatively about
e-books has said that they don't think e-books will catch on because
they can't imagine someone sitting at a computer to read for enjoyment.
They don't get it, because they don't understand that reading e-books
(at least non-PDF e-books) /doesn't/ mean sitting at a computer to read,
and the e-book community at large hasn't done a very good job of
communicating this fact.
You believe that supporting IE and Opera alone gives 80% market coverage
because 80% of the market has access to IE. I believe that supporting IE
alone provides only 20% market coverage because only 20% of the market
would be /willing to use/ IE as an e-book reading tool.
Your argument is remarkably similar to that used by Michael Hart in
favor of his degraded text format: simple ASCII provides 100% market
coverage if only consumers would just lower their standards enough.
>> I know of /no/ tools that exist to create these files. Even the IENo, that's a lot of programs which do something similar to that which
>> function saves all binary data (such as images) as uuencoded (text) data.
> The fact that you don't know about them isn't an interesting point :-).
> As I remember pointing out to you before, almost all HTML-formatted
> email is multipart/related. Every email-handling library contains
> support for it. That's a lot of tools.
would be required to create and present MIME-based e-books, although
they do contain a fair amount of source code that could be used to
create the necessary tools. (Of course, if the source code has
restrictive licensing, such as the GPL, it would be pretty much unusable
by any commercial enterprise.) You are suggesting that there are a lot
of resources for programmers; you have not identified any existing tools
for producers and consumers.
This is one of the reasons I really ought to be supporting your
MIME-based encapsulation proposal. I'm a programmer well-versed in
Internet protocols and fairly knowledgeable about e-books. Writing some
of the currently non-existent tools required to support a MIME-based
encapsulation scheme wouldn't be difficult for me, so if a MIME-based
format were accepted as a standard I could probably convince one of the
major players to hire me at a premium. It wouldn't be good for consumers
or for producers, but I ought to be able to take advantage of it personally.
Now if the tools to create and manipulate a MIME-based encapsulation
format really do exist, you ought to be able to write a brief set of
instructions telling us how to create an e-book in that format much as
John Rivlin has done for EPUB
Can you do so? If so, please share it with us.
>> From my biasedUnderstand that I am not associated with the IDPF or any e-book
>> perspective, being able to read an e-book in IE, obtained directly from
>> the web without being stored locally has virtually no value.
> That is indeed the problem. Groups like the IDPF are dominated by
> folks biased to the old failed last-century model of the ebook, and
> find it hard to accept that that future didn't, in fact, happen -- and
> won't. Again, the way that you put that seems to me a demonstration
> that you don't quite understand what's happening to publishing and
> communications technology.
publisher or software producer. My interests in e-books are as an avid
reader and technophile; in other words, I am a consumer and nothing
else. As a consumer, I don't believe in the future you are trying to
promote. (When I say "don't believe" I don't mean that I have no faith
in it, nor that I wish that it will not happen; I mean that rational
extrapolation from consumer expectations and technological trends leads
me to conclude that it /will not/ happen).
I want e-books I can read on a device small enough to hold in one hand.
I want e-books whose presentation I can alter easily to accommodate my
failing eyesight. And I want an e-book I can read and enjoy while
sitting on a houseboat in the middle of Lake Powell. I don't think that
the e-book model prevalent at the beginning of this century has failed,
and I don't think that technology is moving in a direction which will
invalidate that model. So far, it seems to me that those who /do/
believe this are a minority of one.
>> So, if you value the option of being able to read an e-book in IE orNo, it /is/ the real situation, based upon my experience as a consumer.
>> Opera only, on a desktop computer, while connected to the Internet with
>> a fat pipe, without regard to the difficulty of creating content ...
> But of course, that isn't the real situation. That's the situation as
> you perceive it to be, much as it was 10 years ago, when the old ebook
> ideas the IDPF is, quite rightly, in existence to protect and preserve,
Whatever your prognostications, you cannot dictate what my needs and
desires should be. While it is possible that you are right and everyone
else in the world is wrong, that's a position I tend to approach with a
great deal of skepticism.
>> I believe that the existence of an IDPF container format is probably dueThose people who agree with what he was proposing seem to think so. You
>> almost exclusively to Mr. Noring's advocacy of the OpenReader format.
>> The IDPF members recognized the need, and fearing loss of control over
>> the format, decided to move forward with it fairly expeditiously.
> I agree. Now, was that a good thing?
think your proposal of using MIME encapsulation is superior. I'm
inviting you to do the same thing Mr. Noring did. Flesh out your
proposal, create a proof of concept, publicize it and let's see how
widely it is adopted. People are not stupid, not even those who disagree
with you. If it truly is better we'll find out soon enough.
Nothing of significance below this line.
I don't think we're going to make much progress by arguing with each
other. But I do invite you to review the OpenReader archives on this
- Bill Janssen wrote:
> I don't think we're going to make much progress by arguing with eachThe OpenReader archives Bill refers to are found at:
> other. But I do invite you to review the OpenReader archives on this
Only part of the discussion focuses on the container format.
- On Wed, 2007-08-01 at 12:26 -0600, Lee Passey wrote:
> Now if the tools to create and manipulate a MIME-based encapsulationWell, that guide is hardly complete. There's nothing on how to create
> format really do exist, you ought to be able to write a brief set of
> instructions telling us how to create an e-book in that format much
> John Rivlin has done for EPUB
> Can you do so? If so, please share it with us.
OPF files, which are way beyond the comprehension of mere mortals.
Anyway, there's a Firefox extension for manipulating multipart/related,
it's called MAF. And it shouldn't be too hard to write a simple Java
applet to do the same.
I certainly agree with your comment, "well, that guide is hardly complete.
There's nothing on how to create OPF files, which are way beyond the
comprehension of mere mortals." While we are now seeing many large trade
and academic publishers working with their conversion houses to upgrade from
OEB to .epub (OCF/OPS), I understand that this is far beyond the resources
that most "mere mortals" would have access to. It is my hope, and I'm sure
the hope of IDPF members, that companies will leverage .epub to create
consumer-grade authoring tools to simply "hit a button" to create a .epub
file. We are beginning to see this with the "export as .epub" feature in
Adobe inDesign CS3 and I'm sure we'll see similar authoring products from
other companies in the near future. The IDPF also plans to help. We are
currently working on releasing validation tools for .epub so companies and
individuals can be sure that their .epub is really .epub.
We're still quite early here (OPS 2.0 isn't even officially approved
yet...early Sept. for voting), but it is our intention to make the creation,
distribution and consumption of .epub files as easy as possible.
International Digital Publishing Forum (IDPF)
(212) 924-9081 direct
(212) 208-0978 fax
[Non-text portions of this message have been removed]
> Anyway, there's a Firefox extension for manipulating multipart/related,I haven't looked too hard at doing it in Java (it's trivially easy to
> it's called MAF. And it shouldn't be too hard to write a simple Java
> applet to do the same.
write a Python program to build MHTML bundles, and at one point I
believe I posted such a "tool" to the OpenReader mailing list), but a
good starting place would be javax.mail.internet.MultiPart (see
part of http://java.sun.com/products/javamail/downloads/index.html).
The JavaMail (and the JAF) code is open source under the CDDL
From a cursory scan of the ChangeLog (the fact that I don't see the
word "related" there :-), it looks to me that you'd still need to add
support for the "related" subtype of "multipart", which basically
involves adding some code to support local resolution of the "cid" URL
scheme from "Content-Location" and "Content-ID" headers in the part
headers. It would be a nice Java class exercise :-).
- In the mean-time, as there was no answer to my post regarding
construction of .opf publications, I'll assume that my OpenBerg Rector
is the only such tool. Or at least the only such open-source tool. Not
that it's available for general use yet, but it's already usable by mere
Well, too bad. I hoped I could draw some inspiration on usability from
Who often feels alone on the open-source e-Book front.
On Fri, 2007-08-03 at 10:10 -0400, Nick Bogaty wrote:
> I certainly agree with your comment, "well, that guide is hardly
> There's nothing on how to create OPF files, which are way beyond the
> comprehension of mere mortals."
- David Teller wrote:
>1. Actually, the creation of OPF files is almost trivial, and well
> On Wed, 2007-08-01 at 12:26 -0600, Lee Passey wrote:
>> Now if the tools to create and manipulate a MIME-based encapsulation
>> format really do exist, you ought to be able to write a brief set of
>> instructions telling us how to create an e-book in that format much
>> as John Rivlin has done for EPUB
>> (http://www.ebooktec hnologies. com/OCFUsingWinZ ip/OCFUsingWinZip.htm.
>> Can you do so? If so, please share it with us.
> Well, that guide is hardly complete. There's nothing on how to create
> OPF files, which are way beyond the comprehension of mere mortals.
within the comprehension of an average clerk/typist. Anyone who claims
it is "beyond the comprehension of mere mortals" is trying to sell you
About three years ago I started writing a simple Java Swing application
that would put a GUI around the OPF creation process. I set the project
aside when I realized that if you know enough to decide what data to put
in which the text fields you know enough to build the OPF file using a
simple text editor. After you've done about two of them you'll be saying
to yourself, "This isn't hard at all."
On the other hand, if a GUI tools is really required, the Mobipocket
Publisher and Mobipocket Creator create OEB publications using an OPF
file. Overdrive's ReaderWorks may do so as well but I'm not certain
about that. At the very least you could use ReaderWorks to create a
Microsoft Reader file and then use ConvertLit to extract a complete OEB
publication including the OPF file. (Actually, any tool that creates
Microsoft Reader files could be used in the same way).
An extremely comprehensive, yet readable, guide to everything you could
ever want to know about creating OPF files can be found at
2. Even if one can't figure out how to build how to build an OEB
publication, that problem is pretty much irrelevant in the discussion of
MIME vs. ZIP. Assuming that I have prepared a valid OEB publication, Mr.
Rivlin's instructions tell me how to create a valid OCF file (aka EPUB,
for the recommended file extension). Assuming that I have prepared a
valid OEP publication, can anyone tell me how I can make a
multipart/MIME file without programming?
> Anyway, there's a Firefox extension for manipulating multipart/related,I find the applet idea intriguing. Of course, the motivation for being
> it's called MAF. And it shouldn't be too hard to write a simple Java
> applet to do the same.
able to read e-books in a browser is to take advantage of the browser's
capability to 1. obtain resources from a network instead of a local file
system, and 2. render the marked-up content. I was not aware that
applets could interact with the host browser that way, instructing the
browser to download and display a given resource. Is this in fact
possible? Could you point me to someplace on the web where sample source
code might be found?
Nothing of significance below this line.
- On Fri, 2007-08-03 at 14:04 -0600, Lee Passey wrote:
> 1. Actually, the creation of OPF files is almost trivial, and wellNo, I'm just stating the obvious: XML has never been meant to be
> within the comprehension of an average clerk/typist. Anyone who
> it is "beyond the comprehension of mere mortals" is trying to sell
human-readable/human-writable except in desperate situations. So, while
typing an OPF file is simple enough, as long as it doesn't involve
*understanding* anything, a task that requires actual *comprehension*,
such as finding the error in an OPF file, is beyond the comprehension of
my students in third year of computer science/engineering.
> About three years ago I started writing a simple Java SwingYep, done that a few weeks ago. Saves even me a number of errors,
> that would put a GUI around the OPF creation process.
especially when you start having books with 100+ resources. Right now,
I'm trying to turn it into something professional-looking.
> After you've done about two of them you'll be sayingThat's a usual mistake made by people with a good understanding of the
> to yourself, "This isn't hard at all."
basics. Yeah, it's probably not hard at all. Except that for most
people, it is.
> On the other hand, if a GUI tools is really required, the MobipocketAnd this is expected to be simple ? Understanding how to *compile*
> Publisher and Mobipocket Creator create OEB publications using an OPF
> file. Overdrive's ReaderWorks may do so as well but I'm not certain
> about that. At the very least you could use ReaderWorks to create a
> Microsoft Reader file and then use ConvertLit to extract a complete
> publication including the OPF file. (Actually, any tool that creates
> Microsoft Reader files could be used in the same way).
ConvertLit took me about 1/2h, and I'm an experienced developer.
> An extremely comprehensive, yet readable, guide to everything youThanks, I'll read it.
> ever want to know about creating OPF files can be found at
> 2. Even if one can't figure out how to build how to build an OEBThat's true.
> publication, that problem is pretty much irrelevant in the discussion
> MIME vs. ZIP.
> > Anyway, there's a Firefox extension for manipulatingActually, I meant for building books.
> > it's called MAF. And it shouldn't be too hard to write a simple Java
> > applet to do the same.
> I find the applet idea intriguing.
> Could you point me to someplace on the web where sample sourcehttp://java.sun.com/products/plugin/1.3/docs/jsobject.html
> code might be found?
>From the top of my mind,