rickbarry@... wrote:

> I'm wondering how someone who wants to use OR with DRM would do that.
> I'd like to be able to respond to people who, for whatever reason,
> want or need DRM. Archivists, like librarians, are for open access to
> the extent they can get away with it. However, in the archives
> community, manuscripts are often gifted to archives (say personal
> files and letters of an important academic or industrialist to a state
> archives) that would wish to make them accessible, but possibly with
> certain stipulations by the gifter.

The following is a snippet from the message I recently posted to the
e-book community group.

My proposed TPM solution for the OpenReader reference implementation
(ORCA) is to create a modular design with a TPM api. A shared library
(.so or .dll) would be loaded to provide file input to the rendering
engine. The shared library would be responsible for doing whatever is
necessary to decrypt encrypted content, and applying any rights
assertions included with the content. A manufacturer wanting to
implement any sort of TPM could design its own library module using
whatever trade-offs it wants. The shared library would register its
desire to become part of the ORCA instance by indicating the mime type
of files it manages (e.g. application/x-nasty-tpm). It would probably
also need to implement a small subset of functions (e.g. canPrint(),
canCopy(), canSave(), etc.) which would, by default, return true.

In this case, an open source TPM implementation would probably make some
sense, not because it is in any way practical (except to prevent casual
sharing) but because it would help people understand how TPM solutions
could be implemented. It would also permit the design and implementation
of the OpenReader reference implementation without regard to _any_ DRM
proposal, and allow anyone interested (I, frankly, am not) to implement
their own wacky version of TPM.

Everyone,

Today I will be giving a talk about OpenReader in one of the sessions
of the online "Let's Go Library Expo" hosted by Planet Library and
sponsored by OverDrive. The details of the online conference (free to
all) is found at:

    http://www.planetlibrary.info/lgleindex.htm

It includes instructions for how to listen in to the talks.

The schedule of talks is given here:

    http://www.planetlibrary.info/lgle200507schedule.htm

My talk is scheduled at 1:00pm Eastern time (10 am Pacific time) in
the Canton Room. I already have a preliminary outline of what I intend
to discuss at:

    http://www.openreader.org/lets-go-presentation-outline.html


Hope to see some of you there.

Jon

David wrote:
> Jon Noring wrote:

>> O.k., a spine (which can be thought of as the main flow of the book)
>> can be "threaded" together using multiple documents, e.g.
>>
>> chap01.html
>> chap02.html
>> ...
>> chap20.html
>>
>> The OEBPS reading system, then, "combines" these documents to form the
>> spine, which can be loosely thought of as a sort of single
>> "pseudo-document." It's a *powerful* feature (which I won't explain
>> here why.)

> It is, indeed. It also confirms that I had not understood all the
> definition. Now, this raises the problem of how to do this in a useful
> manner, in presence of scrolling.

Of course, each document in the spine can have its own style sheet,
and that can complicate things, too.

But the benefits outweigh the added complication.


>> MS Reader's interface for OEBPS Tours is pretty cool and will give
>> inspiration (it can be made better.) All my MS Reader ebooks, such as
>> the Kama Sutra, takes full advantage of Tours. I'll be happy to
>> forward to you a copy of my LIT Kama Sutra, and you can see for
>> yourself how it works.

> With pleasure. I will attempt to exhume Windows from its partition and
> install MS Reader to take a look.

O.k., let me know when I can email you a copy. I'll also be happy to
zip up the source OEBPS 1.0.1 Publication to it


> Well, after a cursory exploration of Bugzilla, a short discussion with
> one of the developers responsible for this feature and a few glimpses
> through Mozilla's code, I am rather confident that it can be done. It
> seems that the bugs of Firefox's Print Preview are progressively being
> ironed out and that support for @page media is being improved. It also
> seems that the Print Preview may be hijacked into providing page-based
> presentation.
>
> Therefore, there is no good reason not to attempt to provide this
> feature in some discernable future. I have just added it to Milestone 4,
> expected, well, not too soon.

Great to hear! Hope Firefox does get that going.

Jon

Le mercredi 20 juillet 2005 à 14:05 -0600, Jon Noring a écrit :
> David wrote:
>
> > Still, you are welcome to call it OB1.
>
> Hmmm, it probably is better to call it OBM1, or OBM1.7

Well, if you check on our developer documentation, you will realise that
it is the Kenobi release.

>
> > 1) CSS
> >
> >  Currently, we recognize standard w3c CSS. Whenever we can, we map
> > "text/oeb1-css" to "text/css" to attempt to render the document, despite
> > the fact that we have no knowledge of OEB-CSS. Unfortunately, we do not
> > (yet) accept "<link rel='stylesheet' type='text/oeb1-css' ...>". This is
> > a known bug which we expect to fix before Milestone 2.
>
> Ah, ok! I thought the problem was with the MIME type of "text/oeb1-css",
> but you say it is because <link ...> is not yet recognized.
>

Sorry for the poor explanation. The type "text/oeb1-css" is mapped to
"text/css" whenever we can (i.e. if the operating system or a server
determines that a file is "text/oeb1-css"). We just don't do it yet when
this is explicitely written as the "type" argument of a "link" tag.

> Except for two custom OEBPS constructs , all OEB-CSS conforms with
> CSS1/2.

Which obviously proves my lack of familiarity with OEB-CSS, I'm afraid.


> >  The actual interpretation of additional OEB-CSS properties is a low-
> > priority task in the development of OpenBerg, partly because we do not
> > yet understand the meaning, role and articulation of all these
> > properties, partly because some of these do not make sense in the
> > current context (e.g. voice-family), and partly because we must admit we
> > do not even know where to start and hope we can get away with it.
>
> Well, as noted above, only two OEB-CSS constructs are custom -- the
> rest are described in the CSS2 spec.
>
> And, yes, OEBPS defines some voice CSS properties, which, in a visual
> environment can safely be ignored. Brady Duga, should he choose to
> reply, can more authoritatively comment on OEB-CSS (he is the "keeper
> of OEB-CSS" in PSWG.)

Is there any document explaining OEB-CSS other than [1] ? I'm afraid
that the content of interest to me is surrounded by so much, well, noise
that I do have trouble extracting any form of useful information on CSS.

> > 2) Multiple-document spine support
> >
> >  I'm afraid I don't understand what you mean. Perhaps I didn't read the
> > definition of OEBPS 1.2 thoroughly enough.
>
> O.k., a spine (which can be thought of as the main flow of the book)
> can be "threaded" together using multiple documents, e.g.
>
> chap01.html
> chap02.html
> ...
> chap20.html
>
> The OEBPS reading system, then, "combines" these documents to form the
> spine, which can be loosely thought of as a sort of single
> "pseudo-document." It's a *powerful* feature (which I won't explain
> here why.)

It is, indeed. It also confirms that I had not understood all the
definition. Now, this raises the problem of how to do this in a useful
manner, in presence of scrolling.

> Web browsers do not do any merging of documents, mainly because one
> needs some external mechanism (like the OEBPS Package) to specify the
> documents and their order in the merged document. This is why the
> concept of "spine" is somewhat alien to web browser developers.
>
> Of course, MS Reader correctly supports the spine feature of OEBPS.
>
> Hopefully this makes sense.

It does. And it leads to a host of questions.

> > 4) Tours and Guides
> >
> >  We expect to handle this in Milestone 3. However, we do not have a
> > clear idea of a user interface for Tours and Guides, yet.
>
> MS Reader's interface for OEBPS Tours is pretty cool and will give
> inspiration (it can be made better.) All my MS Reader ebooks, such as
> the Kama Sutra, takes full advantage of Tours. I'll be happy to
> forward to you a copy of my LIT Kama Sutra, and you can see for
> yourself how it works.

<insert appropriate joke here about "how kama sutra works" />

With pleasure. I will attempt to exhume Windows from its partition and
install MS Reader to take a look.

> > 5) Scrolling
> >
> > Under CSS2, this is actually a CSS property. We might wish to "force"
> > paged-presentation depending on some user-preference, but we have not
> > decided to do so. Do you think we should ?
>
> Hmmm. Does Firefox have a "page" mode for presenting web pages which
> is activated by some CSS2 or CSS3 property? I don't recall it having
> such a capability, nor do I recall the CSS2/3 property.

No, after checking, I realize that Firefox does not implement the
"@page" mode yet. This feature was discussed some time ago but seems to
have been half-forgotten. The closest thing they have is the rather
buggy "Print Preview". I'll investigate this matter.

<insert_ellipsis />

Well, after a cursory exploration of Bugzilla, a short discussion with
one of the developers responsible for this feature and a few glimpses
through Mozilla's code, I am rather confident that it can be done. It
seems that the bugs of Firefox's Print Preview are progressively being
ironed out and that support for @page media is being improved. It also
seems that the Print Preview may be hijacked into providing page-based
presentation.

Therefore, there is no good reason not to attempt to provide this
feature in some discernable future. I have just added it to Milestone 4,
expected, well, not too soon.

Regards,
  David


[1] http://www.openebook.org/oebps/oebps1.2/download/oeb12-xhtml.htm

--
Read, Write, and Publish Standard eBooks
   Free, Open Software, Open Standards and multi-platform
     The OpenBerg project http://www.openberg.org

David wrote:

> Still, you are welcome to call it OB1.

Hmmm, it probably is better to call it OBM1, or OBM1.7


> 1) CSS
>
>  Currently, we recognize standard w3c CSS. Whenever we can, we map
> "text/oeb1-css" to "text/css" to attempt to render the document, despite
> the fact that we have no knowledge of OEB-CSS. Unfortunately, we do not
> (yet) accept "<link rel='stylesheet' type='text/oeb1-css' ...>". This is
> a known bug which we expect to fix before Milestone 2.

Ah, ok! I thought the problem was with the MIME type of "text/oeb1-css",
but you say it is because <link ...> is not yet recognized.

Except for two custom OEBPS constructs , all OEB-CSS conforms with
CSS1/2.


>  The actual interpretation of additional OEB-CSS properties is a low-
> priority task in the development of OpenBerg, partly because we do not
> yet understand the meaning, role and articulation of all these
> properties, partly because some of these do not make sense in the
> current context (e.g. voice-family), and partly because we must admit we
> do not even know where to start and hope we can get away with it.

Well, as noted above, only two OEB-CSS constructs are custom -- the
rest are described in the CSS2 spec.

And, yes, OEBPS defines some voice CSS properties, which, in a visual
environment can safely be ignored. Brady Duga, should he choose to
reply, can more authoritatively comment on OEB-CSS (he is the "keeper
of OEB-CSS" in PSWG.)


> 2) Multiple-document spine support
>
>  I'm afraid I don't understand what you mean. Perhaps I didn't read the
> definition of OEBPS 1.2 definition thoroughly enough.

O.k., a spine (which can be thought of as the main flow of the book)
can be "threaded" together using multiple documents, e.g.

chap01.html
chap02.html
...
chap20.html

The OEBPS reading system, then, "combines" these documents to form the
spine, which can be loosely thought of as a sort of single
"pseudo-document." It's a *powerful* feature (which I won't explain
here why.)

Web browsers do not do any merging of documents, mainly because one
needs some external mechanism (like the OEBPS Package) to specify the
documents and their order in the merged document. This is why the
concept of "spine" is somewhat alien to web browser developers.

Of course, MS Reader correctly supports the spine feature of OEBPS.

Hopefully this makes sense.


> 4) Tours and Guides
>
>  We expect to handle this in Milestone 3. However, we do not have a
> clear idea of a user interface for Tours and Guides, yet.

MS Reader's interface for OEBPS Tours is pretty cool and will give
inspiration (it can be made better.) All my MS Reader ebooks, such as
the Kama Sutra, takes full advantage of Tours. I'll be happy to
forward to you a copy of my LIT Kama Sutra, and you can see for
yourself how it works.


> 4'') etc.
>
>  Could you be more specific ? :)

Well, at another time as I think of them. :^)


> 5) Scrolling
>
> Under CSS2, this is actually a CSS property. We might wish to "force"
> paged-presentation depending on some user-preference, but we have not
> decided to do so. Do you think we should ?

Hmmm. Does Firefox have a "page" mode for presenting web pages which
is activated by some CSS2 or CSS3 property? I don't recall it having
such a capability, nor do I recall the CSS2/3 property.


> And thanks for the encouragements,

And we are all rooting for your success!

Jon

Thanks Jon,

  Just for the sake of referencing, I'll start by pointing out that we
finally adopted a somewhat readable numbering scheme. Milestone 1 is
therefore the 0.1.x series and the current version is 0.1.7 . Work
towards Milestone 2 will start as soon as we are satisfied that all bugs
have been ironed out. Still, you are welcome to call it OB1.

  Our current estimated target for Milestone 2 is the end of year 2005.

  I will also point out that we do not support LIT at the moment. The
architecture of OpenBerg Reader was designed to allow multi-format and
we have some (small) preliminary work done towards LIT opening, but this
feature is not implemented for now and not even present as a fixed
target in our RoadMap, as we do not know yet how difficult this will be,
not to mention how legal. There is currently one developer working on
this and another one working on the opening of Gutenberg e-books, a
feature we intend to include in Milestone 2.




1) CSS

  Currently, we recognize standard w3c CSS. Whenever we can, we map
"text/oeb1-css" to "text/css" to attempt to render the document, despite
the fact that we have no knowledge of OEB-CSS. Unfortunately, we do not
(yet) accept "<link rel='stylesheet' type='text/oeb1-css' ...>". This is
a known bug which we expect to fix before Milestone 2.

  The actual interpretation of additional OEB-CSS properties is a low-
priority task in the development of OpenBerg, partly because we do not
yet understand the meaning, role and articulation of all these
properties, partly because some of these do not make sense in the
current context (e.g. voice-family), and partly because we must admit we
do not even know where to start and hope we can get away with it.


2) Multiple-document spine support

  I'm afraid I don't understand what you mean. Perhaps I didn't read the
definition of OEBPS 1.2 definition thoroughly enough.


3) Out-of-spine content

  This should be handled in Milestone 2.


4) Tours and Guides

  We expect to handle this in Milestone 3. However, we do not have a
clear idea of a user interface for Tours and Guides, yet.


4') Fallbacks

  This should be handled in Milestone 2.

4'') etc.

  Could you be more specific ? :)

5) Scrolling

  Under CSS2, this is actually a CSS property. We might wish to "force"
paged-presentation depending on some user-preference, but we have not
decided to do so. Do you think we should ?

Regards,
  And thanks for the encouragements,
   David

On Wed, 2005-07-20 at 08:33 -0600, Jon Noring wrote:
> David Teller wrote:
>
> Great work, David!
>
> I tested your Milestone 1 (which I'll call OB1) on a couple OEBPS
1.0.1
> Publications I have (there is no OEBPS 1.1, just to note), and indeed
> OB1 reads the OPF file and renders the spine document (I don't have an
> OEBPS 1.0.1 Publication whose spine comprises multiple documents,
> though.)
>
> Obviously, you can't implement everything, so I'm curious at which
> Milestones do you plan to implement the following OEBPS constructs:
>
> 1) OEB-CSS support. (At present OEB-CSS was not recognized.)
>
> 2) Multiple-document spine support.
>
> 3) Out-of-spine content. (Well, you do support it, but currently there
>    is no way to get back to the spine without closing the book and
>    reopening it. In essence, you presently treat out-of-spine as a
>    simple web-like hyperlink, where the target has the same precedence
>    level as the spine itself.)
>
> 4) Tours, Guides, fallbacks, etc.
>
>
> I also noticed that the presentation of the book was in a single page
> scroll. Is there any possibility to implement page presentation like
> is done for Microsoft Reader, or will the reliance on Firefox limit
> presentation of a document to the single scrolling window paradigm?
>
> Again, great work! The multiple format capability of OpenBerg is
> certainly a huge plus. How do you support MS Reader (LIT)? You must
> use a LIT decompiler to extract the OEBPS Publication?
>
> Jon
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
--
Read, write and publish e-books,
  Free software, Open standards, Open source,
   The OpenBerg project -- http://www.openberg.org

David Teller wrote:

> In addition to this, the OpenBerg project is now proud to announce the
> availability of OpenBerg Reader Milestone 1 for Windows, Mac OS X and
> Linux, all of which may be downloaded from our website.
>
> The current version is 0.1.7, that is Milestone 1 plus a number of
> bugfixes and small improvements. Installers, source code and
> instructions may be found on http://www.openberg.org . Should you meet a
> problem, please be sure to inform us, either through our forums or
> through or bug tracker. Suggestions and Feature Requests are also
> welcome.

Great work, David!

I tested your Milestone 1 (which I'll call OB1) on a couple OEBPS 1.0.1
Publications I have (there is no OEBPS 1.1, just to note), and indeed
OB1 reads the OPF file and renders the spine document (I don't have an
OEBPS 1.0.1 Publication whose spine comprises multiple documents,
though.)

Obviously, you can't implement everything, so I'm curious at which
Milestones do you plan to implement the following OEBPS constructs:

1) OEB-CSS support. (At present OEB-CSS was not recognized.)

2) Multiple-document spine support.

3) Out-of-spine content. (Well, you do support it, but currently there
    is no way to get back to the spine without closing the book and
    reopening it. In essence, you presently treat out-of-spine as a
    simple web-like hyperlink, where the target has the same precedence
    level as the spine itself.)

4) Tours, Guides, fallbacks, etc.


I also noticed that the presentation of the book was in a single page
scroll. Is there any possibility to implement page presentation like
is done for Microsoft Reader, or will the reliance on Firefox limit
presentation of a document to the single scrolling window paradigm?

Again, great work! The multiple format capability of OpenBerg is
certainly a huge plus. How do you support MS Reader (LIT)? You must
use a LIT decompiler to extract the OEBPS Publication?

Jon

[I'm forwarding this to the OpenReader working group forums. It was
originally posted to The eBook Community forum. Give it a whirl!
Requires Firefox 1.0.x to be first installed. This is very interesting
in that it appears OpenBerg essentially relies upon Firefox for the
rendering side of things, which makes sense. More in a followup reply.
Jon]



In addition to this, the OpenBerg project is now proud to announce the
availability of OpenBerg Reader Milestone 1 for Windows, Mac OS X and
Linux, all of which may be downloaded from our website.

The current version is 0.1.7, that is Milestone 1 plus a number of
bugfixes and small improvements. Installers, source code and
instructions may be found on http://www.openberg.org . Should you meet a
problem, please be sure to inform us, either through our forums or
through or bug tracker. Suggestions and Feature Requests are also
welcome.

Oh, and the website has been fixed for compatibility with Safari,
Konqueror and Internet Explorer.

Regards,
  For the OpenBerg Project,
   David Teller

Le mercredi 13 juillet 2005 à 03:48 +0100, David Teller a écrit :
> The OpenBerg project is happy to tell you that the first alpha version
> for OpenBerg Reader Milestone Release 1 is now complete. The source code
> has landed on the server a few minutes ago. Installers and binaries will
> be made available as soon as possible.
>
> As a first Milestone Release, OpenBerg Reader is quite incomplete and
> probably mostly useless. However, it has reached a state in which it is
> well-developped enough to be tried, shown, and commented-upon.
>
> Regards,
>  For the OpenBerg project,
>   David Teller
>
--
Read, Write, and Publish Standard eBooks
   Free, Open Software, Open Standards and multi-platform
     The OpenBerg project http://www.openberg.org



--------------------------------------------------------------------
Post a message:   ebook-community@yahoogroups.com
Unsubscribe:      ebook-community-unsubscribe@yahoogroups.com
Switch to digest: ebook-community-digest@yahoogroups.com
Switch to normal: ebook-community-normal@yahoogroups.com
Put mail on hold: ebook-community-nomail@yahoogroups.com
Administrator:    ebook-community-owner@yahoogroups.com
--------------------------------------------------------------------
Yahoo! Groups Links

[The following announcement was made to The eBook Community by David
Teller. Congratulations on this milestone! Jon]


The OpenBerg project is happy to tell you that the first alpha version
for OpenBerg Reader Milestone Release 1 is now complete. The source code
has landed on the server a few minutes ago. Installers and binaries will
be made available as soon as possible.

As a first Milestone Release, OpenBerg Reader is quite incomplete and
probably mostly useless. However, it has reached a state in which it is
well-developped enough to be tried, shown, and commented-upon.

Regards,
  For the OpenBerg project,
   David Teller

Everyone,

Even though we are now working on a "version 2.0" of the OpenReader
web site, it was decided we do a little rework of the present interim
site. The current draft (which will often change), is at:

    http://www.openreader.org/updatedraft/

The changes include updating the content so it more accurately
reflects where we are today, hopefully resolves ambiguities (such as
those brought up by Terje), and so forth.

We've also moved the "Introduction" to a separate page, so the home
page is now a wonderfully boring "table of contents". As just noted,
we are working on a whole new web site design, with David Rothman
leading the effort (and we are asking for your help!) However, getting
the content updated is an important first step to this final goal.

I'd appreciate any and all feedback regarding the current draft site.
If anyone here with editing skills would like to take a stab at
editing the content (I admit to be a pretty poor writer), let me
know.

Thanks!

Jon Noring
OpenReader Consortium

Lee wrote:
> Jon Noring wrote:

>> Now, equally important, as Lee privately wrote me a couple days ago,
>> we need to come up with a fairly complete list of "product
>> constraints" (which is similar to my call for "requirements"). This
>> will aid in decision-making. How can one make intelligent decisions
>> unless one knows the requirements and constraints? Lee listed a few
>> candidate product constraints posed as questions. Lee, can you repost
>> your list here, or should I do it?

> Here are the questions I sent you earlier, edited only slightly to use
> the name Orca for the user agent (I've got to lobby whenever I get the
> chance). ORF is, of course, the OpenReader Format:

Well, regarding Orca, I really like that name. You have my vote. My
only concern is if the name is taken by any product remotely similar
to what we want to develop, and if the people behind such product
would get their shorts in a knot over our use of the name. I recall
the Firefox people going through this hassle with some name before
they ultimately settled upon Firefox (and I hear there's someone upset
with their using the Firefox name.)

Interestingly, orca.org is owned by someone wanting to sell it for
2000 EUR which is not that steep, but not cheap either (of course, if
some corporate entity or entities fund OpenReader Format and Orca
development, we could then afford that domain.)

In the meanwhile, let's start thinking of a nice logo to go with the
"Orca" brand name (yes, it is a brand name.)

Now, on to Lee's first list of product constraints:

> - Is it important that the OpenReader Format interoperate with
>   existing tool?
>
> - Is it important that ORF encapsulate image files?
>
> - Is it important that ORF encapsulate image files other than JPEG,
>   GIF and PNG?
>
> - Is it important for ORF to compress text files?
>
> - Is it important that ORF feature "zero-latency" decompression (can
>   start emitting decompressed text immediately after receiving the
>   first code word, emitting at least 1 output char for every
>   compressed code word)?
>
> - Is it important that ORF be unencumbered by patents?
>
> - Is it important that Orca be free from license restrictions,
>   including the restriction that it cannot be later restricted?
>
> - Is it important that ORF/Orca be usable on handheld devices?
>
> - Is it important that ORF/Orca be usable on low memory devices?
>
> - Is it important that ORF/Orca be usable on devices with slow
>   processors (do we need to make it usable on an Apple][)?
>
> - Is it important that Orca be cross-platform (MSWindows is
>   important, IBM System 32 isn't important, but how do we order
>   things in between)?

Wow, very good start on a list! I won't begin to share my thoughts on
the above list. Rather, I hope this spurs others to add their own
"questions". With enough people contributing from various viewpoints,
we should begin seeing a clearer picture emerge of the things that
will decide the fundamental conceptual design of both the OpenReader
Format and Orca.

O.k., everybody, share your questions similar to how Lee phrased them
above.


> Personally, I prefer the term "product constraints" for the answers
> to these types of questions, as opposed to "product requirements".
> The word "requirements" implies a binary decision: a feature is
> required or it is not, a requirement is satisfied or it is not;
> failure is not an option. In reality, these types of issues are
> usually tradeoffs. BZip2 is probably the most efficient unencumbered
> compression method, but it is not zero-latent. The LZ77 variant used
> in PalmDOC _is_ zero-latent but it is not very efficient.
> Compression efficiency can be improved by using larger window sizes,
> but that makes it harder to run on low-memory devices. So as we
> develop product goals, it's worthwhile to identify them as critical
> (must be achieved), important, or desirable so when there is a
> conflict between two constraints we can figure out which wins, or
> how much effort should be put in to achieving some goal (there are
> some features, which I would categorize as "kind of nice", that I
> would include only if the incremental cost of including them is
> virtually zero). For example, a mechanism to incorporate TPM into the
> OpenReader format is probably quite important, but any implementation of
> TPM in Orca is probably unnecessary.

An excellent summary.

Your comments on TPM remind me that we need to add one or two "product
constraint" questions regarding TPM and the OpenReader Format, e.g.,

  - What general types of TPM should the OpenReader Format not inhibit?

(I use the phrase "not inhibit" since ORF 1.0 will probably not
include TPM of our own design/making -- that's for a future
development effort or one done in parallel to ORF development by some
allied group interested in TPM. But ORF should not, by its fundamental
design, get in the way or make it more difficult to add a TPM layer
(however "layer" is defined.) This requires us to visualize the
various types of TPM and how one would implement each within the ORF
encapsulation. Each different approach to TPM requires some type of
"hooks" to interact with the base ORF.)


> None of these questions are technical, but all of them effect technical
> decisions. Indeed, every technical proposal we have heard so far implies
> how the author prioritizes these issues. So let's start by deciding what
> features are required, which are important, which would be nice and
> which are irrelevant. Only then can we make reasonable technical design
> decisions.

As I look at Lee's list, the last three items, which more or less
center around truly legacy hardware/OS, as well as real obscure
stuff now being marketed, stand out in my mind as being very important
to discuss early on, since they have profound impact on both the
OpenReader Format encapsulation design, and Orca's codebase design.

Jon

Jon Noring wrote:

>Now, equally important, as Lee privately wrote me a couple days ago,
>we need to come up with a fairly complete list of "product
>constraints" (which is similar to my call for "requirements"). This
>will aid in decision-making. How can one make intelligent decisions
>unless one knows the requirements and constraints? Lee listed a few
>candidate product constraints posed as questions. Lee, can you repost
>your list here, or should I do it?
>
>

Here are the questions I sent you earlier, edited only slightly to use
the name Orca for the user agent (I've got to lobby whenever I get the
chance). ORF is, of course, the OpenReader Format:

- Is it important that the OpenReader Format interoperate with existing
tool?
- Is it important that ORF encapsulate image files?
- Is it important that ORF encapsulate image files other than JPEG, GIF
and PNG?
- Is it important for ORF to compress text files?
- Is it important that ORF feature "zero-latency" decompression (can
start emitting decompressed text immediately after receiving the first
code word, emitting at least 1 output char for every compressed code word)?
- Is it important that ORF be unencumbered by patents?
- Is it important that Orca be free from license restrictions, including
the restriction that it cannot be later restricted?
- Is it important that ORF/Orca be usable on handheld devices?
- Is it important that ORF/Orca be usable on low memory devices?
- Is it important that ORF/Orca be usable on devices with slow
processors (do we need to make it usable on an Apple][)?
- Is it important that Orca be cross-platform (MSWindows is important,
IBM System 32 isn't important, but how do we order things in between)?

Personally, I prefer the term "product constraints" for the answers to
these types of questions, as opposed to "product requirements". The word
"requirements" implies a binary decision: a feature is required or it is
not, a requirement is satisfied or it is not; failure is not an option.
In reality, these types of issues are usually tradeoffs. BZip2 is
probably the most efficient unencumbered compression method, but it is
not zero-latent. The LZ77 variant used in PalmDOC _is_ zero-latent but
it is not very efficient. Compression efficiency can be improved by
using larger window sizes, but that makes it harder to run on low-memory
devices. So as we develop product goals, it's worthwhile to identify
them as critical (must be achieved), important, or desirable so when
there is a conflict between two constraints we can figure out which
wins, or how much effort should be put in to achieving some goal (there
are some features, which I would categorize as "kind of nice", that I
would include only if the incremental cost of including them is
virtually zero). For example, a mechanism to incorporate TPM into the
OpenReader format is probably quite important, but any implementation of
TPM in Orca is probably unnecessary.

None of these questions are technical, but all of them effect technical
decisions. Indeed, every technical proposal we have heard so far implies
how the author prioritizes these issues. So let's start by deciding what
features are required, which are important, which would be nice and
which are irrelevant. Only then can we make reasonable technical design
decisions.

Jon Noring wrote:

>Since GPL has been discussed here recently, a few of you may be
>interested in the following article (an interview with Eric Raymond
>of Linux fame) which discusses that we don't need GPL anymore:
>
>http://www.onlamp.com/pub/a/onlamp/2005/06/30/esr_interview.html
>
>
>Jon
>
>
What a terrific interview! (Jon, you ought to post this to
ebook-community, where I'll bet it will really provoke some
controversy.) Whether you agree with Mr. Raymond's conclusions or not,
you have to respect his willingness to answer questions directly without
trying to side-step them. I wish I could find a politician who would do
that.

Of special note is Mr. Raymond's comment that "What a lot of people have
not figured out yet--though the W3C and IETF are moving in this
direction--is that open standards depend on open source reference
implementations. It is extremely difficult to specify everything that
needs to be specified in a technical standard;..." For this reason, I'm
cross-posting this message to the development list as well, for that's
where discussions of licensing are most relevant.

The whole premise of licensing is based, fundamentally, on an
enforceable legal right. The notion is that if I have a right to prevent
dissemination or use of _something_ I can permit you to disseminate or
use it in exchange for some consideration (money, your agreement not to
charge money, your agreement not to share it further, your first-born
child, whatever), and prohibit its dissemination/use without such an
agreement. A license is a contract, so it requires legal consideration
on both sides (so the first-born is probably _not_ valid consideration).
If the licensor has no legal right to prevent a use the license is not
binding, even if both sides agreed to the contract.

In software, the most common legal basis for licensing is copyright law.
Thus, if the OpenReader Consoritum wants to exercise some sort of
control over the use of its work product it needs to claim a copyright
on it. Ordinarily this would not be a problem as U.S. copyright law, and
that of most nations who are signatory to the Berne convention,
automatically assigns a copyright to every work of authorship, whether
you want one or not. (That's right, this message is copyrighted by me,
and if you quote part of it without asking my permission I have the
right to sue you.) But automatic copyrights attach to the author, so we
would need to either get an assignement of copyright from the original
author, or each document should contain a header with contact
information for that author so that individuals or corporations that
what to negotiate a license different from the OpenReader license can
contact the individual who actually holds the rights.

  From the perspective of OpenReader two questions have to be resolved:
what work product _can_ be restricted, and what restrictions, if any, do
we want to place on that work product.

I have argued in the past that the ZIP Archive Format cannot be
restricted because there is no legal basis to do so. I believe that the
same is true for the PDF format. The same will be true of any format
specification we come up with as well. This is why discussion of
licensing is more appropriate for the development list; because when it
comes to format specifications the only way we can control them is to 1.
make them so complete and compelling that people _want_ to adopt them
without changes, and 2. create a reference implementation that is so
good that people will want to incorporate that code rather than writing
their own.

This second method is particularly important when selecting a licensing
scheme for the OpenReader reference implementation. If we want to
maintain at least some degree of control over the formats, we need to
license the reference implementation on the most liberal of terms. Given
this, what restrictions, if any, do we really want to place on use of
OpenReader code? And what are the restrictions placed on other code we
may want to use and how to those restrictions affect our decisions?

I don't think that an "attribution"-type license is required. I don't
care if no-one knows that I wrote a specific piece of code, and I don't
think most open-source developers care either. On the other hand, if we
choose to impose any restrictions at all on use of our source code we
should maintain some sort of contact information in our files so we can
field requests from people who want to use the code without those
restrictions.

Some people have suggested that the attribution aspect is the prime
motivator for BSD/MIT/Apache types of licenses. I disagree. I believe
that the prime motivator for those types of licenses is fear of
product-liability lawsuits. If you're writing open-source code that
might someday find its way into an air traffic control system, and if a
bug in your code cause a 747 to fly into a mountain side, you want to be
damn sure that everyone knows that "THE SOFTWARE IS PROVIDED 'AS IS',
WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE"

I'm not terribly impressed with licenses designed principally to avoid
dubious legal entanglements. Disclaimers are pretty ineffectual in tort
claims, which are based on negligence, and it's hard to make a product
liability claim stick where the product is a gift and the recipient is a
sophisticated user (and anyone incorporating source code _is_ a
sophisticated user).

I would suggest that any source code developed by contributors to
OpenReader simply be dedicated to the Public Domain. Source code used by
the OpenReader reference implementation should be carefully selected so
that it does not inhibit our goal of widespread adoption (the BSD/MIT
license should be acceptable, the full GPL or othe copyleft licenses
would not be). And the OpenReader reference implementation should be
designed in a modular fashion so if we need to use code with a dubious
license in the short term it can be easily and quickly replaced when
more liberally licensed code becomes available.

Lee wrote:

> This discussion is blurring the line between the OpenReader format,
> and a reference implementation of an OpenReader user agent, but most
> of the discussion seems to be oriented towards the user agent
> question.

I think part of the reason this is so is that it is difficult to talk
about the format without also getting into the user agent issues. They
are inextricably linked. For example, one could come up with a whiz-
bang encapsulation specification which, when implemented in real life,
will place an unusually high level of processing requirements on the
user agent platform.

There is also the issue of the end-user reading experience that we
would like to accomplish. This has an impact on user agent design, and
we have to make sure the format+encapsulation is up to the task.

Again, linkage.

Now, we could certainly modularize the entire "OpenReader" spec
into component parts (making it a "suite"), and this is very
intriguing.

For example, here's a split we could make into three interrelated
specs:

1) OpenReader Encapsulation Specification (ORE Specification).

    This would simply define how we encapsulate one or more digital
    publications, independent of the particulars of the underlying
    framework(s). We make no mention of OEBPS or whatever. (We may have
    to define the general nature which the frameworks must possess.)
    This will allow other initiatives outside of OpenReader to use ORE
    without the baggage associated with publication frameworks and user
    agent conformance.

2) OpenReader Format Specification (ORF Specification).

    This would define how we use ORE to create conforming ORF. We'd
    list the approved publication frameworks (which can be expanded
    in the future) and any restrictions we want to place on them if any
    (there are two frameworks I'd like to support for ORF 1.0: OEBPS
    1.2, and XHTML 1.1 "Web", both somewhat constrained as I've talked
    about previously.) We may also list some ORF publication conformance
    requirements, such as how much we tolerate encapsulating
    non-conforming publications (e.g., do we require that every
    framework publication be checked at this stage and no encapsulation
    must be done if it is not 100% conforming to our requirements, or
    do we let some stuff slide by?)

3) OpenReader User Agent Conformance Specification (ORUAC Spec.)

    This would define the conformance requirements for any user agent
    which wants to call itself "OpenReader conformant". It will be tied
    in with supported frameworks, so there is a fairly close linkage
    with the ORF Spec, maybe to the point we'd merge the two specs into
    one. Nevertheless, for the time being let's consider them separate
    from one another.

    An example conformance requirement, at least for OEBPS 1.2
    Publications, would be the requirement that "out-of-spine",
    manifest-listed content be rendered upon demand as part of the
    publication (except as disallowed by DRM and where circumstances
    beyond the control of the user agent prevent access to the
    resource) and that it be presented to the reader in such a way
    that (clearly) differentiates it from the main flow (the "spine")
    of the publication.

    The primary reason we would like to develop our own reference
    implementation of an OpenReader User Agent (which Lee likes to
    call "Orca", a name I love!) is so that we can demonstrate the
    conformance requirements in action, and to establish them as the
    "norm". For example, when HTML was invented, the Mosaic browser was
    developed in parallel to demonstrate HTML in action and to
    establish the "norm" in visually rendering HTML. (Even if this
    were not the intent as described, this is what happened.) The
    momentum this created is with us today, where web browsers
    essentially follow the lead which Mosaic established (such as
    default visual rendering in the absence of CSS.)

    Of course, should we not be able to develop our own reference
    implementation, or work closely with some organization to build
    one, the ORUAC will at least put down on e-paper our expectations.


> Whatever the outcome of the format wars, we will need to come up with a
> User Agent that will render an OpenReader-formatted document.The primary
> requirement of the OR User Agent (I really like the name Orca -- lets
> see if we can come up with a way to make that acronym fit :-)) will be
> to render documents that are in the OREF (OpenReader Encaspulation
> Format). Let's pretend for the moment that the OpenReader format ends up
> being an archived, compressed encapsulation of the OEBPS 1.2
> specification, and that we have a User Agent which can render that. What
> should the User Agent do when presented with a non-OR-conforming
> document (e.g. one which encapsulates an OEPBS 1.0.x publication which
> is not compatible with 1.2)?

Possibilities for the "ORCA" acronym?

    "OpenReader Conformant (User) Agent"
    "OpenReader Consumer (User) Agent"


Now, regarding what the ORUA must do when confronted with a
non-conforming ORF document, that's a very good question! It is also
one which is guaranteed to get different passionate views (I recall
this being discussed in the early days of OEBPS development -- it was
certainly passionate.)

<joke>In my ideal world, I'd prefer that when ORUA is given a
non-conforming ORF, that it be required to barf on it, spit it back in
the face of the user, and tells them in no uncertain terms this is
what the publisher wanted to do to you.</joke><smile/>

O.k., maybe I'm getting a little carried away... <laugh/>

A more reasonable view, but still tough:

1) Require all ORF to be conforming (no and's if's or but's), but say
    nothing about verification other than it is recommended. That some
    will not heed the requirement is something we can't enforce at this
    level. (I see OpenReader helping developing ORF checking tools --
    we may be able to license for use the great OEBPS checking tool
    developed by Preceive Software, which I assisted with, or develop
    our own. It would be a good idea to promote encapsulation tools
    which include conformance verification -- this establishes the
    positive "mind set" that it is a good idea to create conforming ORF.)

2) When encountering some serious ORF non-conformance conditions that
    are easily checked by any ORUA (list to be determined), ORUA *must
    cease* processing the ORF and provide an error message to the user
    about the non-conformance condition.

    For example, I'd *require* (my personal view) that if the documents
    are not well-formed XML or do not follow our other XML document
    requirements such as UTF-8/16 conformance, the ORUA must cease
    processing and present an accurate error message of the problem to
    the user (XML non-conformance is easy to check since all ORUA which
    process XML-based frameworks must parse the docs anyway so XML
    errors will be readily discovered -- btw, doesn't XML require all
    XML processors to terminate when processing a non-well-formed XML
    document? -- anyone?)

    Any publisher worth their salt will always test out their
    publications in existing ORUA before selling them, and if they see
    the error message, especially in the UA associated with the
    OpenReader Consortium, they *will* fix the problem. THAT'S WHAT WE
    WANT. There are certain non-conformance conditions which we must
    not tolerate since such sloppiness can destroy the whole intent of
    OpenReader to bring conformity and predictability to both
    production and to the end-user reading experience.

3) For all other non-conformance issues we will say that ORUA *should
    not* render the ORF. This is not the same as "must not", and if some
    ORUA wishes to go ahead and try to render the Publications, it may
    go ahead. The OpenReader police will not beat down the doors of such
    ORUA developers and haul them off to be tortured in the soft comfy
    chair, ala Monty Python. <smile/>


Interestingly, I believe that ORUA developers, knowing that they are
not required to try to handle exceptions (non-conformance conditions,
such as quirky HTML) will find it easier to develop user agents. It
should lead to leaner and faster code. No need to try to render quirky
HTML -- everything is nicely standardized. This is what W3C is trying
to do -- move the web world towards stricter standards. We should do
likewise, and the stakes are quite high for what we are trying to
accomplish.

Regarding "Orca", Lee's cool name for OpenReader's proposed reference
implementation user agent, I believe it needs to set the standard for
conformance and, for as many errors as it will easily spot, will not
render ORF (even if the codebase used allows it to!), and will provide
the needed error message(s). This will force other ORUA to do likewise
since we'll set the tone and momentum.

Some might say this strictness will work against OpenReader being
embraced by publishers, UA developers and end-users, but I believe the
opposite is true. Strict conformance leads to predictable rendering --
a benefit to publishers and end-users. It also makes life easier for
UA developers who don't have to program for weird exceptions -- they
know what they will be getting, and know how it is to be rendered.

There's also the principle that if we loosen things up too much in
the beginning, it will be like opening Pandora's box or letting the
genie out of the bottle -- it will be very difficult to undo the
process in the future if we determined we were too lax.

Thus the conservative position is to be pretty strict at the
beginning, and then as we learn from field experience and user
feedback, we can always relax selected things.


> Because almost all the code will already be in place, I would support
> making the User Agent forgiving enough to render the earlier format
> despite the fact that it is not truly in the OpenReader format (I'd like
> to make it flexible enough to render XML documents that aren't even
> OR-compliant). Thus, the User Agent would be an OEBPS-compliant reading
> system even though the OpenReader format may be a sub- or super-set of
> OEBPS 1.2, or even a whole new paradigm completely.

Well, I can see this. But my view is that if given an OpenReader Format
document, it needs to terminate processing when encountering one of
among a list of certain exceptions. That the User Agent code base is
capable of being more forgiving for rendering non-ORF documents is a
different matter -- I have no difficulty with that. Just because it can
be done, though, does not alone justify that it should be done.

Of course, we may not be that far apart, unless you believe that when
Orca encounters an ORF with non-well-formed XML documents, that it
should try to render it. That's where I personally draw the line. If
any of the XML instances within ORF is not at least well-formed, then
I believe Orca should terminate processing and provide an error
message to the end-user saying the XML is bad. This forces publishers
to at least provide well-formed XML documents, which I believe is the
minimum we should require of publishers. Is this such an onerous
burden? I don't think so, especially in that XML tools are getting to
be more prevalent and easier to use. Even the smallest publisher can
easily verify documents for well-formedness, such as using W3C's
validator.

There are other non-conformance conditions I would be more forgiving
on and let slide, but not XML well-formedness since that is
fundamental to the OpenReader philosophy -- my personal view.


> The goal of the OpenReader format is to come up with an open,
> single-file format that can be freely used by any User Agent. As I see
> it, the goal of the OpenReader format is to make good on the earlier
> promises of the OEBF, which now seem to be abandoned. The goal of the
> OpenReader User Agent (Orca) is to make sure that the OpenReader format
> is practical, and that there is a least one User Agent which can use the
> OpenReader format natively. The term "OpenReader" tends to lump these
> two projects together, so you need to always be clear just which one
> your talking about. When Jon says OpenReader he is almost always talking
> about a file format. When I say OpenReader I'm almost always talking
> about the User Agent.

Yes, I agree. We need to put a name on the User Agent reference
implementation side of the house, which has several benefits. And I
do love "Orca" as the name! (Of course, we need to check to see who
else is using the name 'Orca' in case we get into a trademark
conflict. I do notice that orca.org is held by some cybersquatter, so
it conceivable could be obtained, but don't know their asking price.

Jon Noring

Brady Duga wrote:

>On Jun 29, 2005, at 11:20 AM, Jon Noring wrote:
>
>
>>Well, the decision has to be made whether OpenReader will be a truly
>>100% conforming OEBPS Reading System per the "rules" of OEBPS 1.2.
>>

[remainder snipped]

Might I suggest that this thread properly belongs in the
openreader-devel group?

This discussion is blurring the line between the OpenReader format, and
a reference implementation of an OpenReader user agent, but most of the
discussion seems to be oriented towards the user agent question.

The OpenReader format clearly has the opportunity to start with a clean
slate (although whether or not that opportunity should be acted upon is
an open question). The OpenReader format could be a simple encapsulation
of an OEBPS 1.2 publication, it could be an encapsulation of a
constrained version of an OEBPS 1.2 publication, it could be the
adoption of PDF/A, with our without additional constraints (requiring a
certain level of tagging, e.g.), or it could be a totally new
publication structure (BAD IDEA!).

Whatever the outcome of the format wars, we will need to come up with a
User Agent that will render an OpenReader-formatted document.The primary
requirement of the OR User Agent (I really like the name Orca -- lets
see if we can come up with a way to make that acronym fit :-)) will be
to render documents that are in the OREF (OpenReader Encaspulation
Format). Let's pretend for the moment that the OpenReader format ends up
being an archived, compressed encapsulation of the OEBPS 1.2
specification, and that we have a User Agent which can render that. What
should the User Agent do when presented with a non-OR-conforming
document (e.g. one which encapsulates an OEPBS 1.0.x publication which
is not compatible with 1.2)?

Because almost all the code will already be in place, I would support
making the User Agent forgiving enough to render the earlier format
despite the fact that it is not truly in the OpenReader format (I'd like
to make it flexible enough to render XML documents that aren't even
OR-compliant). Thus, the User Agent would be an OEBPS-compliant reading
system even though the OpenReader format may be a sub- or super-set of
OEBPS 1.2, or even a whole new paradigm completely.

The goal of the OpenReader format is to come up with an open,
single-file format that can be freely used by any User Agent. As I see
it, the goal of the OpenReader format is to make good on the earlier
promises of the OEBF, which now seem to be abandoned. The goal of the
OpenReader User Agent (Orca) is to make sure that the OpenReader format
is practical, and that there is a least one User Agent which can use the
OpenReader format natively. The term "OpenReader" tends to lump these
two projects together, so you need to always be clear just which one
your talking about. When Jon says OpenReader he is almost always talking
about a file format. When I say OpenReader I'm almost always talking
about the User Agent.

Finally, OpenReader.org is back online. It was down for almost ten
days (or so) due to a comedic plethora of snafu's that occured during
a server configuration upgrade. We came this close (pinching fingers
together) in looking for an alternative server host.

Jon

As most everyone will observe, the current OpenReader site is in sore
need of a redesign, to make it look more professional, as well as to
update the content, which is beginning to get dated and not exactly
expressing where we stand today. (Over the last year, as the OpenReader
vision has matured, the focus has shifted somewhat, plus we have gained
new insights, including feedback from our supporting organizations and
individuals. The web site does not reflect these small changes.)

David Rothman is in charge of updating the content (although a few of
us, including Lee Passey, Rick Barry, and yours truly, will assist --
of course, feel free to volunteer, such as to help edit the content.)

We plan to add a "blog" page, which David is expert at administering
(his Teleread blog is one of the most well-known and most oft-visited
in the ebook and digital library arenas: http://www.teleread.org/blog/ )

However, we still need help to redesign the layout of the site to give
it a professional, "industry standards consortium" look and feel.

So, is anyone here willing to lead with the graphics design and
general layout of the site? Of course, we are now approaching a few
individuals to head this task, but you are certainly welcome to step
forward and volunteer. It can certainly be a group thing. I will help
with the final markup and CSS to assure the pages are well-structured
XHTML 1.1, which is not only expected since OpenReader is committed
to strict adherence to XML standards, but it's a good idea to meet
accessibility requirements. And as mentioned above, David Rothman will
lead with the content side of things, as well as provide guidance to
the web designer(s).

Let me know in private your interest in helping out.

Thanks!

Jon Noring

[cc: David Teller -- this will be forwarded separately to the
OpenReader-Format and OpenReader-Devel groups]


Oops, I forgot to answer David's following comment in a prior reply on
The eBook Community:


David Teller wrote:

> I will start by a short note on the relative roles of OpenReader and
> OpenBerg. As far as I know, I'd say that OpenReader tries to find
> the perfect open standard and improve the already-existing standards
> -- without implementing any of them, as of yet -- while OpenBerg is
> mostly a matter of implementing good open standards -- without
> creating or improving them. Of course, OpenReader's standard is so
> feature-rich that we probably will never be able to implement it in
> full, at least unless someone lends us the support of full-time
> developers.
>
> Regarding the choice of a wrapping format, now. OpenBerg is
> currently using unwrapped OEBPS for development purposes. Whenever
> we find the time to work on this, we will add support for a simple
> Zip wrapper, as this is a simple mean for distributing books.
> Whenever OpenReader publishes their specification of "standard"
> wrapper format, we will attempt to implement them. Quite likely,
> this will not entail any technical issue.

David, you're doing a great job in developing OpenBerg! I look forward
to seeing a mature alpha or early beta of it (it'd have to be a
Windows version for me -- don't yet run a Linux box.)

Since the OpenReader format will support OEBPS 1.2 (more specifically,
to encapsulate OEBPS 1.2), then OpenBerg will certainly be able to
quite easily extract the OEBPS 1.2 Publication and render it.

The vision we have for OpenReader is that we *want* to see competing
reading systems, both open source and commercial/proprietary, so long
as they all follow the general rendering conformance requirements we
will establish as part of the format. (This is not the same as the
"feature set", but related to it.)

This is not unlike HTML and web browsers, where expected rendering
behavior has been pretty well established and both web authors and
end-users have developed expectations -- Mosaic helped to establish
the general conformance requirements and user expectations for web
browsers.

Certainly, the OpenReader Consortium is exploring developing its own
open source reference implementation of an OpenReader "user agent"
(reading system). This activity is being led by Lee Passey and
discussion (which has just started) can be followed at the YahooGroup
'OpenReader-Devel'.

We have also informally talked to a couple organizations about
developing a proprietary "user agent" implementation of an OpenReader
user agent (why not! -- we want both open and proprietary to compete
side-by-side with each other, just as we have IE, Opera, Mozilla/
Firefox, etc., competing with each other in the web universe.)

The important thing is that we have *one* open standards digital
publication specification, meeting OpenReader principles, that all the
competing systems will render in predicatable fashion. Let the
end-user have the freedom to pick the "user agent" and platform of
their choice, and get good rendering results for the OpenReader
formatted documents they possess.

This exploration by the OpenReader Consortium in developing our own
reference implementation "user agent" is not necessarily a
"competition" with OpenBerg. I prefer to think that we are working
together for a common goal. We welcome David Teller to continue
posting updates of OpenBerg development activity to
"OpenReader-Devel", and to leverage the help of those developers who
are already subscribed there (a lot of sharp people in that group.) It
may be, that after seeing the "beta" in action, we might embrace
OpenBerg to form the core codebase of our reference implementation.

But it is too early to make that commitment since we have not yet
formally incorporated the OpenReader Consortium, and we need to get a
better idea about the OpenReader format (particularly what constraints
we will place on OEBPS 1.2 to conform with OpenReader -- OEBPS 1.2 is
a little too loose and still a little buggy requiring constraints to
firm it up and to prepare us for the next generation framework without
having to support buggy legacy stuff that we'd rather not support.) We
are still building the membership base of the nascent organization,
and each member will contribute their own requirements set to the
format development process (these sets will then all be condensed,
sorted and reconciled with each other according to OpenReader
principles.)

Hope this sufficiently answers David's comment.

Jon Noring
OpenReader Consortium






--------------------------------------------------------------------
Post a message:   ebook-community@yahoogroups.com
Unsubscribe:      ebook-community-unsubscribe@yahoogroups.com
Switch to digest: ebook-community-digest@yahoogroups.com
Switch to normal: ebook-community-normal@yahoogroups.com
Put mail on hold: ebook-community-nomail@yahoogroups.com
Administrator:    ebook-community-owner@yahoogroups.com
--------------------------------------------------------------------
Yahoo! Groups Links

Everyone,

The openreader.org web site has been down for over a week due to a
snafu in a domain server move (GoDaddy apparently screwed up some
data).

This morning the (supposedly) correct data was resubmitted (DNS
servers plus some other data -- I don't fully understand all of this),
so if this resolves the problem, openreader.org should be back up
within 24-48 hours as the updated info propagates through the Internet.

However, should the server continue to be down, we will have to move
the hosting for openreader.org.

Anyone here willing to host openreader.org in case we can't get it
back online anytime soon? If so, reply in private.

Thanks!

Jon Noring
OpenReader Consortium

On May 10, 2005, at 6:47 AM, Terje Hillesund wrote:

> The Preliminary Implementation Roadmap at OpenReader.org says
> that "scrolling display" might be included in version 1.0 of
> the user
> agent as an End-User page level typography feature. I hope that
> scrolling will be included as an option (page turning being default),
> mostly for navigational purposes.

Seconded. One of my interests in OpenReader is to have a browser that
can be paged or scrolled. This is really a user preference, but I
think there are 3 core modes: line-scrolled, page scrolled, and
paged. The difference here is how much text gets moved, and the
visual clues associated with the movement. Lack of such features is a
pet peeve of mine vis-a-vis the WWW.

Lee Passey wrote:
> Jon Ferraiolo wrote:
>> Jon Noring wrote:
>>> Michael Day wrote:

>>>> MathML has mode and display attributes for controlling whether it
>>>> should be rendered inline or as a separate block.
>>>>
>>>> Why not take a look at the XHTML+SVG+MathML DTD available from
>>>> the W3C?

>>> As noted in my latest reply to Leonard's message, I finally got a
>>> chance to look at the content model for W3C's XHTML+MathML+SVG
>>> (XMS) profile DTD. (I used UltraXML 3.3 to get a tree view of the
>>> DTD, which otherwise would be a bear to figure out because of its
>>> modularity.)
>>>
>>> According to that profile, <math> and <svg:svg>, when used within
>>> an XHTML 1.1 host, are effectively classified as "BlockOrInline",
>>> and can thus appear at both the Block level and at the Inline
>>> level. The following are legal (leaving out namespace
>>> declarations):
>>>
>>> <body> <svg:svg> ... </svg:svg> </body>
>>>
>>> <p>This is a <svg:svg>[cool vector graphic of 'test']</svg:svg>
>>> paragraph with an embedded SVG graphic.</p>
>>>
>>> (Same applies for <math>.)
>>>
>>> But <img> and <object>, which I classify as being similar in many
>>> respects to fragment objects of <math> and <svg:svg>, may only
>>> appear Inline.
>>>
>>> So I find the decision by those who built the XMS profile to allow
>>> both <math> and <svg:svg> to be "BlockOrInline", while <img> and
>>> <object> are only "Inline", to be curious. Maybe it is <img> and
>>> <object> which should be allowed to be "BlockOrInline". The new
>>> XHTML 2.0 chucks the <img> tag in favor of the <object> tag, and it
>>> appears that <object> will only be allowed to appear Inline (as
>>> part of the "Text Module". So the mystery, at least to me,
>>> remains.)

>> Jon, I share your concerns about why svg:svg (BlockOrInline) should
>> be treated differently than html:img (Inline). When we designed the
>> SVG language, the thrust of the effort was that SVG was an alternate
>> image format to PNG, JPEG and GIF. In fact, the MIME type for SVG was
>> defined as image/svg+xml. (Although people on the SVG WG generally
>> think it should have been application/svg+xml nowadays.)
>>
>> Just for consistency reasons, I would argue that the XHTML+SVG+MathML
>> DTD made a mistake and that it is more important that svg:svg be
>> consistent with html:img (and html:object) than valuing the
>> XHTML+SVG+MathML DTD as a precedent. My opinion is that if the world
>> wants svg:svg to be a block-level element when embedded in HTML, then
>> convince the HTML working group to allow html:img and html:object as
>> BlockOrInline also.

Jon, thanks for your feedback on this topic!

Lee replied:

> I have a real practical problem with anything being identified as
> BlockOrInline. In a User Agent, when I encounter a block element, I know
> that I must move the pen to a point at the extreme left margin of the
> drawing area, and below the last thing I drew. I apply my margins,
> indentations, and alignment values, and begin rendering. If I encounter
> an inline element, I begin drawing at the current pen location
> (adjusting, if necessary, any previously drawn text if alignment is
> bottom). But what do I do if I encounter an element that is defined as
> BlockOrInline?
>
> I suspect that the practical effect of this configuration is that
> BlockOrInline elements will be (should be?) rendered as if they were
> inline elements, but permitted inside block elements (such as <body>)
> which do not otherwise permit inline content. The practical consequence
> is that if you have an <svg:svg> block that you want presented in a
> block fashion you will have to encapsulate it inside a <div> anyway.
>
> I agree with Mr. Ferraiolo that <svg:svg> should be inline only, just as
> <img> and <object> are, and suggest that in the reference implementation
> we treat it that way.

Well, it seems we have some agreement on this.

I, too, believe that <svg:svg> (how about <math>?) should only appear
inline to be consistent with XHTML <img> and <object>.

As was done for OEBPS 1.2 (whose Basic vocabulary is a pure and clean
subset of XHTML 1.1), it's easy for us to subset the XHTML+MathML+SVG
(XMS) profile for our purposes. Restricting <svg:svg> (and I assume
<math>) to only appear Inline is such a subset process.

We will need to build our own DTD which reflects the subset of the XMS
profile we want to support, which really isn't difficult (question:
should we subset the full SVG spec, version 1.1/1.2?) In addition, we
might want to consider adding a couple tags to support other features
we'd like. For example, I'd like to include support for the
<xi:include> tag from the new W3C Recommended "XInclude" Specification:

    http://www.w3.org/TR/2004/REC-xinclude-20041220/

(For XInclude, I'd only support the Basic Inclusion mode as seen in
the example of appendix C.1 -- we can always expand XInclude support
later if there's a clamor for the other modes.)

Jon Noring

Jon Ferraiolo wrote:

>  At 02:03 PM 5/9/2005, Jon Noring wrote:
>
> > Michael Day wrote:
> >
> >> MathML has mode and display attributes for controlling whether it
> >> should be rendered inline or as a separate block.
> >>
> >> Why not take a look at the XHTML+SVG+MathML DTD available from
> >> the W3C?
> >
> > Thanks, Michael.
> >
> > As noted in my latest reply to Leonard's message, I finally got a
> > chance to look at the content model for W3C's XHTML+MathML+SVG
> > (XMS) profile DTD. (I used UltraXML 3.3 to get a tree view of the
> > DTD, which otherwise would be a bear to figure out because of its
> > modularity.)
> >
> > According to that profile, <math> and <svg:svg>, when used within
> > an XHTML 1.1 host, are effectively classified as "BlockOrInline",
> > and can thus appear at both the Block level and at the Inline
> > level. The following are legal (leaving out namespace
> > declarations):
> >
> > <body> <svg:svg> ... </svg:svg> </body>
> >
> > <p>This is a <svg:svg>[cool vector graphic of 'test']</svg:svg>
> > paragraph with an embedded SVG graphic.</p>
> >
> > (Same applies for <math>.)
> >
> > But <img> and <object>, which I classify as being similar in many
> > respects to fragment objects of <math> and <svg:svg>, may only
> > appear Inline.
> >
> > So I find the decision by those who built the XMS profile to allow
> > both <math> and <svg:svg> to be "BlockOrInline", while <img> and
> > <object> are only "Inline", to be curious. Maybe it is <img> and
> > <object> which should be allowed to be "BlockOrInline". The new
> > XHTML 2.0 chucks the <img> tag in favor of the <object> tag, and it
> > appears that <object> will only be allowed to appear Inline (as
> > part of the "Text Module". So the mystery, at least to me,
> > remains.)
> >
> > Jon
>
>  Jon, I share your concerns about why svg:svg (BlockOrInline) should
>  be treated differently than html:img (Inline). When we designed the
>  SVG language, the thrust of the effort was that SVG was an alternate
>  image format to PNG, JPEG and GIF. In fact, the MIME type for SVG was
>  defined as image/svg+xml. (Although people on the SVG WG generally
>  think it should have been application/svg+xml nowadays.)
>
>  Just for consistency reasons, I would argue that the XHTML+SVG+MathML
>  DTD made a mistake and that it is more important that svg:svg be
>  consistent with html:img (and html:object) than valuing the
>  XHTML+SVG+MathML DTD as a precedent. My opinion is that if the world
>  wants svg:svg to be a block-level element when embedded in HTML, then
>  convince the HTML working group to allow html:img and html:object as
>  BlockOrInline also.
>
>  Jon Ferraiolo Adobe Systems, Inc. Editor SVG 1.0 spec


I have a real practical problem with anything being identified as
BlockOrInline. In a User Agent, when I encounter a block element, I know
that I must move the pen to a point at the extreme left margin of the
drawing area, and below the last thing I drew. I apply my margins,
indentations, and alignment values, and begin rendering. If I encounter
an inline element, I begin drawing at the current pen location
(adjusting, if necessary, any previously drawn text if alignment is
bottom). But what do I do if I encounter an element that is defined as
BlockOrInline?

I suspect that the practical effect of this configuration is that
BlockOrInline elements will be (should be?) rendered as if they were
inline elements, but permitted inside block elements (such as <body>)
which do not otherwise permit inline content. The practical consequence
is that if you have an <svg:svg> block that you want presented in a
block fashion you will have to encapsulate it inside a <div> anyway.

I agree with Mr. Ferraiolo that <svg:svg> should be inline only, just as
<img> and <object> are, and suggest that in the reference implementation
we treat it that way.

> agent as an End-User page level typography feature. I hope that
scrolling will be included as an option (page turning being default),
mostly for navigational purposes...
Being a scholar browsing quite a lot of literature every week, quick
and easy text navigation is very important.

Hear, hear! In fact, I'm in favor of the agent being able to serve up the text
in a variety of ways--and that's just one example. To me, the program should be
just about as flexible as a word-processor and go far beyond the scrolling
option, font size, leading and the rest. I'm itching for all the flexibility of
uBook and more. Keep the feedback coming! Don't let the techies go for the
easiest way. And meanwhile I hope you'll keep spreading the word about us and
encouraging hardware companies and others to support our work. The more
resources we have, the faster we can give people what they want.

David Rothman | davidrothman@...
Strategy and External Relations director for OpenReader







Terje Hillesund wrote:

>The Preliminary Implementation Roadmap at OpenReader.org says
>that "scrolling display" might be included in version 1.0 of
>the user
>agent as an End-User page level typography feature. I hope that
>scrolling will be included as an option (page turning being default),
>mostly for navigational purposes.
>
>There are many forms of reading, the reading of a text from a to z by
>turning the pages (e.g. in a novel) is only one of many forms. The OR
>user agent will be designed to meet requirements of reading of
>journals, reports, textbooks and a great variety of texts. When
>reading journals and reports many people like to quickly leaf through
>the publication to see what it is all about.
>
>An optional vertical scroll-bar a the right side (as in Adobe Reader)
>of the text window is very useful when you want to flick through a
>report: You can read a little here and there, look at figures and
>tables, browse the pages for familiar names and concepts, look at
>what references and links are used, read the conclusion and then
>scroll back to couple of the most promising sub-chapters. In just a
>few minutes you have a pretty good idea of what the report is about
>and you can decide if you want to read parts of the report, the whole
>report, store it (in the OE library) or throw it away.
>
>Being a scholar browsing quite a lot of literature every week, quick
>and easy text navigation is very important.
>
>Any comments?
>
>
>Terje Hillesund
>Associate Professor
>University of Stavanger
>
>Latest article:
>"Digital Text Cycles: From Medieval Manuscripts to Modern Markup"
>http://jodi.ecs.soton.ac.uk/Articles/v06/i01/Hillesund/
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
>
>
>



--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.8 - Release Date: 5/10/2005

The Preliminary Implementation Roadmap at OpenReader.org says
that "scrolling display" might be included in version 1.0 of
the user
agent as an End-User page level typography feature. I hope that
scrolling will be included as an option (page turning being default),
mostly for navigational purposes.

There are many forms of reading, the reading of a text from a to z by
turning the pages (e.g. in a novel) is only one of many forms. The OR
user agent will be designed to meet requirements of reading of
journals, reports, textbooks and a great variety of texts. When
reading journals and reports many people like to quickly leaf through
the publication to see what it is all about.

An optional vertical scroll-bar a the right side (as in Adobe Reader)
of the text window is very useful when you want to flick through a
report: You can read a little here and there, look at figures and
tables, browse the pages for familiar names and concepts, look at
what references and links are used, read the conclusion and then
scroll back to couple of the most promising sub-chapters. In just a
few minutes you have a pretty good idea of what the report is about
and you can decide if you want to read parts of the report, the whole
report, store it (in the OE library) or throw it away.

Being a scholar browsing quite a lot of literature every week, quick
and easy text navigation is very important.

Any comments?


Terje Hillesund
Associate Professor
University of Stavanger

Latest article:
"Digital Text Cycles: From Medieval Manuscripts to Modern Markup"
http://jodi.ecs.soton.ac.uk/Articles/v06/i01/Hillesund/

Hello, Terje. Great to read of your priorities! There are indeed other
forums where the essential social issues can be discussed. But first I
can't resist pointing you to a post I made to LISNews--before I saw
your words below:

http://www.lisnews.com/article.pl?sid=05/05/05/105
6255&mode=thread&tid=69

LISNews is one of the best ways to reach tech-minded librarians here
in the United States. I'd love to see you undertake similar efforts in
Europe. Librarians are extraordinarily important, in terms of society
and potentially in terms of popularizing OpenReader. Alas, many U.S.
librarians are accustomed to deferring to vendors. We need to educate
them to use their buying power to favor books and other items in open
formats. I'd love to see ALA endorse OpenReader. Realistically
libraries can't do OpenReader until it exists, they need to work with
here-and-now products, but libraries should let vendors know that the
future will be "open."

Needless to say, if you or others want to do guest contributions for
the TeleRead blog, which is heavy on social issues, I would welcome
that. I've enjoyed your own thoughts on the e-book scene. I in fact
quoted in the TeleBlog your much-justified displeasure with
proprietary formats. http://www.teleread.org/blog/?p=2590

Back to libraries. Interestingly, the original article about TeleRead
(Computerworld, July 6, 1992) suggested libraries as popularizers of
e-books--which is among the tactics, alas, that some of the
Proprietary Formatters are using.
http://www.teleread.org/computerworld.htm

OK, we return you now to our regularly scheduled program--on dev
stuff.

Thanks,
David Rothman | 703-370-6540
http://www.teleread.org/blog
dr AT teleread.org

(Wearing his TeleRead.org hat)




--- In openreader-devel@yahoogroups.com, "Terje Hillesund"
<t.hillesund@c...> wrote:
> I promise to stop joking about the devil, he is no part of this (on
> the contrary you might say)
>
> As I now understand it, sosial issues related to OpenReader have no
> place in neither of the OR groups and are better adressed in the
TeBC
> group. What I have in mind is OpenReader and its relation with open
> access and digital libraries etc.
>
> On the preliminary OpenReader supporters page I see no libraries or
> other "open" initatives. Librariens and libraries are usually
> supportive of openness and could be strong supporters in developing
> the Open Reader format and reader. I also believe digital libraries
> could be important in the diffusion of OpenReader.
>
> But Jon, if this is correctly understood, I will take these
question
> to the TeBc group.
>
>
> Terje Hillesund

Terje wrote:
> Jon Noring wrote:

>> This question is better asked in 'openreader-devel' since this
>> deals not with the format but with the "user agent" (or "reader
>> software") used to present OR formatted publications to the
>> end-user. So I've cc'd 'openreader-devel' on this reply.

> Thank you for clearing this up. This group (the devil group) is for
> discussion of the "user-agent", the "browser", the "reader", or
> whatever you call it, and the other group (the format group) is
> related to questions reading the format standard.
>
> The point is taken, but I'm not sure the distinction will be very
> easy to keep. One of the reasons for this I think is the
> presentation given at OpenReader.org. Here format and the notion of
> typographic presentation seem to be closely related, like in the two
> sentences:
>
> "OpenReader is... distribution format which will be platform-
> independent and capable of high typographic presentation quality."
>
> "It also requires the format be of sufficiently high typographic
> quality.."
>
> I guess that most of what is related to typographic quality (like
> page size, line length, margins, fonts, font rendering, spacing,
> hyphenation etc.) is ether a hardware or a software
> ("browser") question, OR a question of how designers
> ("typographers") use style-sheet properties, and NOT a format
> standard question (other than what styling format to include, which
> is already decided to be CSS).

You are right in that what is written at the OpenReader.org web site
is confusing, and I plan to edit it as soon as possible (to exactly
what, I don't know yet -- suggestions for better wording is *always*
welcome.)

The point is that any candidate "universal" ebook and digital
publication format must be able to internally contain sufficient
detail on document structural/semantic/presentation to *allow* user
agents to present the document with a high degree of typographic
quality (commensurate, of course, with the hardware platform used to
view the document -- it is, for example, difficult for a black and
white screen to present the color red. <smile/>)

Publishers, obviously, are very interested in this since they'd like
to have a lot of capability to specify various default typographical
settings -- such as using CSS -- to "fine tune" presentation. (The
final presentation, of course, is a negotiation process between the
publisher and the end-user, dependent on the end-user's particular
hardware and viewing preferences. XML+CSS provides an excellent
negotiation mechanism for presentation meeting the needs of both
publishers and end-users.)

There are text-oriented formats out there that do not have the
requisite internal detail, which must drive publishers nuts. Plain
text, for example, especially when unregularized (as most plain text
is), is not capable of communicating with any certainty even basic
document structure. Many text-oriented formats have some -- albeit
fairly limited -- internal detail, an example being Mobipocket (which
Lee Passey, who is leading the reference implementation development
effort, can better comment upon.)

In my personal experience as a part-time ebook publisher, I am quite
disappointed by most of the ebook formats out there with respect to
typographic capability of both the format and associated reading
system(s). I don't offer Mobipocket versions of my ebooks, for
example, since there are some things I want to do with regards to
presentation, but can't. It's frustrating. Mobipocket, which as an
ebook system has a lot of good aspects about it (it certainly has
built quite a market share in the PDA ebook scene, so it's doing
something right), is sort of like Henry Ford's "you can have any color
car you want so long as it is black."

OpenReader must be forward thinking, and to think "universally". We
must not be unduly constrained by "here-and-now" thinking. This does
not mean we don't consider the "here-and-now" -- but rather we put it
into its proper perspective and determine what is best for today *and*
tomorrow. We must also be open to alternative solutions, such as how
OpenReader will handle legacy hardware without taking the path of
"lowest-possible-denonimator-to-meet-yesterdays-hardware'.

There are actually several requirements the format should possess to
be considered suitable for universal use -- typographic "resolution"
is just one of them. An article I wrote two years ago covers this
topic: http://www.openreader.org/OEBPS-UCF.html (Although this article
focuses on OEBPS as the "universal format", this applies to
OpenReader, which is intended to be the encapsulation format for the
OEBPS framework, and other similar, compatible frameworks as they are
developed.)


> Further the "Implementation Roadmap" is a bit confusing. Is OR 1.0,
> OR 1.1, OR 2.0 etc. labelling the versions of the format standard
> or, as is more likely, versions of the browser?

Another good point.


> If the latter is the case, I find it extremely confusing to call the
> reader OpenReader as long as OpenReader is the name of the format.
> Why don't we find a proper name (like "Firefox" or "Mosaic" ) for
> the browser and reserve "OpenReader" as the name of the format.

Also a good point. I am open to calling the "user agent"
reference implementation project something other than OpenReader
"FireFerret"? <laugh/>). But in the meanwhile, I need to update the
"Implementation Roadmap", which hasn't been done in a long time. It
clearly applies to our planned "reference implementation" of an
OpenReader User Agent, and so should state that more clearly.

The OpenReader concept was first formulated almost 1.5 years ago, and
it has evolved as a few of us have studied it. The "Implementation
Roadmap", though, has not been updated to keep up with our latest
thinking. Time to do some editing...


> I think we need to sharpen out concept and be more specific when we
> talk of OpenReader. When do we talk of the format and when do talk
> about the reader?

Maybe the best at this time is to use "OpenReader format" to refer to
the format (I've proposed "ORP", meaning "OpenReader Publication
Format"), and "OpenReader User Agent" (ORUA) to refer to any software
to render an OpenReader formatted document. For our proposed
"reference implemention", we might call that "RI" or "ORRI".

(An analogy: In the web world, we have the "HTML format", and we have
"HTML browsers", such as Firefox, Opera, IE, etc.)

Jon Noring

I promise to stop joking about the devil, he is no part of this (on
the contrary you might say)

As I now understand it, sosial issues related to OpenReader have no
place in neither of the OR groups and are better adressed in the TeBC
group. What I have in mind is OpenReader and its relation with open
access and digital libraries etc.

On the preliminary OpenReader supporters page I see no libraries or
other "open" initatives. Librariens and libraries are usually
supportive of openness and could be strong supporters in developing
the Open Reader format and reader. I also believe digital libraries
could be important in the diffusion of OpenReader.

But Jon, if this is correctly understood, I will take these question
to the TeBc group.


Terje Hillesund

--- In openreader-devel@yahoogroups.com, Jon Noring <jon@n...> wrote:

> This question is better asked in 'openreader-devel' since this
deals
> not with the format but with the "user agent" (or "reader
software")
> used to present OR formatted publications to the end-user. So I've
> cc'd 'openreader-devel' on this reply.
>

Thank you for clearing this up. This group (the devil group) is for
discussion of the "user-agent", the "browser", the "reader", or
whatever you call it, and the other group (the format group) is
related to questions reading the format standard.

The point is taken, but I'm not sure the distinction will be very
easy to keep. One of the reasons for this I think is the
presentation given at OpenReader.org. Here format and the notion of
typographic presentation seem to be closely related, like in the two
sentences:

"OpenReader is... distribution format which will be platform-
independent and capable of high typographic presentation quality."

"It also requires the format be of sufficiently high typographic
quality.."

I guess that most of what is related to typographic quality (like
page size, line length, margins, fonts, font rendering, spacing,
hyphenation etc.) is ether a hardware or a software
("browser")
question, OR a question of how designers ("typographers") use
style-
sheet properties, and NOT a format standard question (other than
what styling format to include, which is already decided to be CSS).

Further the "Implementation Roadmap" is a bit confusing. Is
OR 1.0,
OR 1.1, OR 2.0 etc. labelling the versions of the format standard
or, as is more likely, versions of the browser? If the latter is the
case, I find it extremely confusing to call the reader OpenReader as
long as OpenReader is the name of the format. Why don't we find a
proper name (like "Firefox" or "Mosaic" ) for the
browser and
reserve "OpenReader" as the name of the format.

I think we need to sharpen out concept and be more specific when we
talk of OpenReader. When do we talk of the format and when do talk
about the reader?

Terje Hillesund

Terje wrote:

> I'm not much into sub-pixel rendering/antialiasing technologies, but
> I see that such features will be supported by OpenReader. What does
> this actually mean? Does it mean that OpenReader-applications made
> for Microsofts OS will be able to make use of ClearType, or does it
> mean that builders of OpenReader-applications must develope their
> own sub-pixel rendering technologies og does it mean that the
> OpenReader Consortium will develope such features?

This question is better asked in 'openreader-devel' since this deals
not with the format but with the "user agent" (or "reader software")
used to present OR formatted publications to the end-user. So I've
cc'd 'openreader-devel' on this reply.

I don't believe we will require independent developers of OpenReader
user agents ("reader software") to include sub-pixel font
rendering (SPFR) or anti-aliasing. That's a hardware-specific issue,
and of course it is meaningless with speech (audio) presentation.

However, in our planned 'reference implementation' of OpenReader,
we currently include SPFR (probably as a feature the end-user can
conveniently turn on and off), and of course this depends upon the
target platform.

Lee Passey, who leads our Development effort, is not enamored with
SPFR, and understandably so -- it has its flaws, and can actually
make text look worse *depending upon the end-user's hardware setup*.

(I personally like how it looks on my very high-resolution laptop
screen, 1920x1200 resolution -- it makes the text even sharper.)


> I have seen some videos at the Microsoft Typography home site in
> which Bill Hill is talking about the improved ClearType technology
> developed for Longhorn. But I don't quite understand if ClearType
> will be reserved for Microsofts own applications (IE, Ms Reader,
> Word and other Office applications) or if it will be a general
> feature build into the new OS, also useable in an OpenReader
> application.

Microsoft has their own version of sub-pixel font rendering (SPFR)
which they call "ClearType", and they hold a few patents in that area
(dealing with the specifics of SPFR implementation.) However, SPFR and
anti-aliasing are not themselves proprietary -- refer to the SPFR
article by Steve Gibson at http://www.grc.com/cleartype.htm .
(btw, cool demo!)

Of course, for platforms which support SPFR at the windowing level, an
OpenReader reference implementation (RI) won't have to have its own
SPFR built-in (it would be cool to let the end-user turn it on or off
within the RI application, if that is possible.)

Jon Noring

Hello,

I'd like to reply to recent messages and private email from Marcus and
Jaapjan, whose input we greatly appreciate!

As should be obvious, message traffic on both the 'openreader-format'
and 'openreader-devel' groups has been essentially non-existent. The
few messages which have been posted recently (such as Marcus'
excellent comments) have not yet been answered (I plan to, however.)

The reason for this is because both groups are quite new, having only
been recently created, and still have very few members. In addition,
we have not yet promoted the groups publicly. We are now working on
the wording of a public announcement which will be posted to many
Internet forums, and we expect to get quite a number of people to
subscribe to our groups when we start our promotion. We are also in
talks with a number of companies and organizations who have thrown
their support behind OpenReader. Currently, the names of these
companies and organizations have been kept under wraps as we continue
to expand the list of supporters.

It is best to hold off on any comments to the OpenReader groups until
we begin heavily promoting these groups in public and have a good
number of subscribers. Of course, feel free to tell others about these
groups. The more, the merrier!

In the meanwhile, if you have any questions/comments about OpenReader,
do not hesitate to privately email me, jon@.... I look forward
to hearing from you.

Thanks.

Jon Noring
OpenReader Consortium