I just posted the following to 'svg-developers' and 'www-math' forums:



[For general info on OpenReader, refer to
    http://www.openreader.org/
Those interested in following the OpenReader Format Working Group
discussion, join the group 'openreader-format' at YahooGroups:
    http://groups.yahoo.com/group/openreader-format/ ]


The OpenReader format, currently under development by the OpenReader
Consortium, will, in its basic form, essentially be an encapsulation
of an OEBPS 1.2 Publication. In turn OEBPS 1.2 is based on XHTML 1.1,
and provides document extensibility and media fallback mechanisms. For
more information on OEBPS 1.2, refer to

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

We wish to include support for both SVG and MathML in the OpenReader
format.

So what mechanism(s) do the SVG and MathML experts recommend for
inclusion of "islands" of SVG and MathML markup within XHTML 1.1
documents? Also, do SVG and MathML provide their own media fallback
mechanisms [see note below], or will we need to provide that?

(I recall seeing an attempt at an XHTML+SVG+MathML DTD/Schema. I also
recall reading that using the <object> tag for inclusion of SVG and
MathML is not recommended. Are my recollections correct?)

Thanks.

Jon Noring
OpenReader Consortium


[Note: A fallback mechanism is a means to specify a media object, such
as a PNG or JPG image, to act as an optional alternative to rendering
SVG or MathML markup. For example, An OpenReader user agent may use
the fallback media object, instead of rendering SVG/MathML when it is
not capable of doing so, such as when operating on limited capacity
hardware like legacy PDAs.]

I'm forwarding to 'openreader-format' Leonid's reply concerning my
questions about FictionBook 2. At the end of his reply links are
provided so those of us interested may investigate the FictionBook 2
system in action. Thanks, Leonid!


*****

Leonid wrote:
> Jon Noring asked:
>> Leonid wrote:

>> Are you considering a FictionBook 2 standard (based on XML and
>> pretty mature already including DRM) as a base for OpenReader? If
>> not why?  http://www.fictionbook.org/en/docs/schema.html

> I looked at the schema and find it very interesting. Good job!

Has nothing to do with me. Authors' e-mails are mike@...
(Mikhail Matsnev) and grib@... (Dmitry Gribov).


> I can finish answering your question better if you can first answer
> the following questions, which are still unclear to me:
>
> 1) Is the intent of FictionBook 2 to contain a whole publication
>    within a single XML document? Or can a publication have multiple
>    XML documents, each of which is valid to the FictionBook 2 schema
>    and which are interlinked?

As far as I understand in the current form it is supposed to be inside a
single document (zipped - .fb2.zip format).


> 2) Are binary multimedia resources (such as image files) intended to
>    be embedded within the XML document in "MIME" fashion? Or can they
>    be kept as separate files?

They are supposed to be embedded.


> 3) Is there any interest in supporting SVG and MathML in a future
>    version of FictionBook 2, or is there a way to use SVG and MathML
>    in the current version?

I don't know about future plans. I don't think that it is currently
supported.


> 4) Are there plans to support other types of textual documents besides
>    "fiction"? I notice the vocabulary is not quite rich enough to
>    support the needs of technical documents, for example. Of course,
>    the markup vocabulary can be expanded as needed.

I believe authors are working on it (version 2.1 currently under
development).


> 5) Are complex navigational structures planned to be supported? This
>    is a very important requirement of the accessibility community. A
>    navigational structure is special markup (which is either within
>    the document or in a separate file) that provides, in a
>    hierarchical fashion, convenient entry points into the publication.
>    It is a sort of "super table of contents".

No idea.


P.S. To feel a standard better you could download and try (some
open-sourced, some just free) software at

    http://www.fictionbook.org/en/programs/redact.html
    http://haali.cs.msu.ru/pocketpc/scripts.html.en  and
    http://haali.cs.msu.ru/pocketpc/ .

You can also take a look at some ready books (English language as
well) at

    http://www.fictionbook.ru/ .

The full description of 2.0 format version is at

    http://haali.cs.msu.ru/pocketpc/FictionBook_description.html .

Thank you for your attention,

Leonid

[This is a copy of a reply I made to TEI-L. Am reposting here since
there is definite interest in OpenReader eventually supporting a
subset of the TEI vocabulary.]



Sebastian Rahtz wrote:
> Jon Noring wrote:

>> [Native support for TEI-Lite (or some other defined subset of TEI)
>> is being considered for the OpenReader format and for OpenReader
>> user agents.]

> I am not in a position right now to subscribe and get stuck into
> serious discussion; but can I flag the suggestion that we
> develop a _much_ tighter subset of the TEI than Lite for this
> sort of purpose? There has been some discussion about "TEI Tight"
> already (I am not sure where it has got to), and it would be good
> to have a stable target.

Thanks, Sebastian, for commenting upon the interest by OpenReader to
eventually support some subset of TEI, maybe within a future planned
"OpenReader framework" (similar to the OEBPS Framework, but with
better multi-vocabulary support and other improvements. Support for
TEI in the current OEBPS is somewhat difficult for reasons I won't
delve into here.)


> I would expect, for instance, a Tight schema to have no flexibility
> at all in the values for "rend" and "type" attributes,
> simplification of lists, simplified content models for <body> etc.
> Whether one would add syntactic sugar for readability, I am less
> sure (eg <oList> for <list type="ordered">) - probably not.
>
> As it stands, TEI Lite is a fairly serious pain to render easily
> and unambiguously.

I'd be interested to know what aspects of TEI-Lite (and TEI in
general) make direct rendering difficult (even if we were to
augment CSS2/3 with a couple TEI-specific properties)? "Aspects"
include elements, attributes, and content models.

One important point to note about OpenReader is that the planned
reference implementation "OpenReader user agent" (some might call it a
"browser" but we try to avoid using that term) is not going to
restrict itself to the HTML paradigm.

For example, because OpenReader supports OEBPS (and OEBPS includes the
unique and powerful "out-of-spine" feature), it is now possible to
support "non-linear" content such as inline-placed notes and sidebars,
which TEI does have markup for. Currently, the HTML vocabulary has no
defined behavior for how to handle stuff, like notes, placed inline
(CSS can be used to move it out of the main flow, but that's messy,
and support for this in IE6 is horrible.)

An OpenReader user agent, for example, could remove an inline note
from the main flow and place it into a popup window or separate page
(similar to Microsoft Reader LIT handling of OEBPS out-of-spine
content.) (As an aside, it appears that XHTML 2.0 will add support
for inline-placed annotative material such as notes -- it'll be
interesting to see how quickly web browsers will add support for
that!)

TEI's table model is different than HTML's, so I gather, so that's
another issue to deal with, but I don't see this as being major.

Other areas of interest with respect to "how could we do it in TEI"
include support for SVG, MathML and XLink. We are also focusing on
minimizing all presentational markup, so the "TEI-OpenReader" we are
looking for will be strongly structural/semantic.

I look forward to everyone's comments. I also encourage those here
interested in OpenReader, and eventual TEI support, to join the
'openreader-format' group at YahooGroups. We could use your help!

Thanks.

Jon Noring
OpenReader Consortium

[If you don't mind, I'm cc'ing this to the 'openreader-format' list
at YahooGroups, the public discussion group for the OpenReader Format
Working Group, so the members there can study the FictionBook 2
standard.]



Hi Leonid,

> Are you considering a FictionBook 2 standard (based on XML and
> pretty mature already including DRM) as a base for OpenReader? If
> not why?  http://www.fictionbook.org/en/docs/schema.html

I looked at the schema and find it very interesting. Good job!

FictionBook 2 appears to be essentially a type of what we term in
OpenReader a "publication framework". It is interesting in design
and approach, and is quite different than the OEBPS Framework.

As another document "vocabulary" (and not in its role as a
"publication framework" -- there is a difference), FictionBook 2
certainly can be supported within OpenReader. The actual element set
for marking up the textual content of documents is quite simple (a
sort of hybrid between a small subset of HTML and TEI-"Super"Lite)
-- it appears that well over half of all the supported elements are
devoted to publication metadata, passing Dublin Core in detail. So
FictionBook 2 is surprisingly quite metadata rich.

I can finish answering your question better if you can first answer
the following questions, which are still unclear to me:

1) Is the intent of FictionBook 2 to contain a whole publication
    within a single XML document? Or can a publication have multiple
    XML documents, each of which is valid to the FictionBook 2 schema
    and which are interlinked?

2) Are binary multimedia resources (such as image files) intended to
    be embedded within the XML document in "MIME" fashion? Or can they
    be kept as separate files?

3) Is there any interest in supporting SVG and MathML in a future
    version of FictionBook 2, or is there a way to use SVG and MathML
    in the current version?

4) Are there plans to support other types of textual documents besides
    "fiction"? I notice the vocabulary is not quite rich enough to
    support the needs of technical documents, for example. Of course,
    the markup vocabulary can be expanded as needed.

5) Are complex navigational structures planned to be supported? This
    is a very important requirement of the accessibility community. A
    navigational structure is special markup (which is either within
    the document or in a separate file) that provides, in a
    hierarchical fashion, convenient entry points into the publication.
    It is a sort of "super table of contents".


Thanks!

Jon Noring
OpenReader Consortium

Hi all!  Exegenix is in the business of converting "unstructured"
document formats (Word, WordPerfect, PDF etc) into XML, which assists
accessibility... we already support DTDs such as DAISY and would like to
add support for the OpenReader standard.  To this end, could any of you
send us some sample content that we could test against?  You can either
email me your material at sandi@..., or (preferably) submit it
online at
http://www.exegenix.com/solutions/sample/index.html?enter=openreader so
you see the kind of  material we can handle.  Please let us know in the
comments area if you actually want XML output returned to you or if you
are submitting material out of the kindness of your hearts for our
testing and support benefit - if the former, we will return XML files to
you as soon as we've figured out the transformation from our regular
(superset of Docbook) DTD.
Thanks,
Sandi

Thanks,
Sandi

Jon Noring wrote:

> 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
>
>
>
>
> ----------------------------------------------------
> Post a message:   openreader-format@yahoogroups.com
> Unsubscribe:      openreader-format-unsubscribe@yahoogroups.com
> Switch to digest: openreader-format-digest@yahoogroups.com
> Switch to normal: openreader-format-normal@yahoogroups.com
> Put mail on hold: openreader-format-nomail@yahoogroups.com
> Administrator:    openreader-format-owner@yahoogroups.com
> ----------------------------------------------------
>
>
> ------------------------------------------------------------------------
> *Yahoo! Groups Links*
>
>     * To visit your group on the web, go to:
>       http://groups.yahoo.com/group/openreader-format/
>
>     * To unsubscribe from this group, send an email to:
>       openreader-format-unsubscribe@yahoogroups.com
>      
<mailto:openreader-format-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>
>     * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>

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

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

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?

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.

Hello



I'm new to this group and the devil group and I am not quite sure I
understand the difference between the two. Since the format group is the
only one with a minimum of traffic I post my message here.



I am a teacher and researcher at University of Stavanger (Norway) and I have
been interested in e-books and e-book related questions for quite some time.
Some years ago my institution (then called Stavanger University College) was
a member of OEBF and I was participating at the e-book conferences in
Washington and Paris (in 2000 and 2001 I believe it was). At these occasions
I also attended the OEBFPSWG-meetings, but not being an XML-expert I wisely
kept my mouth shut.



One time, however, at a panel session in Paris I asked a question, and that
question was about the development of a common end-user e-book format, which
I truly believed was one of the objectives of OEBF. I felt my question was
ignored or at least not answered by the panel. And I couldn't understand
why. For me the publication structure specification was only the first step
towards a common reader format, moving the business away from the multi
format situation with (at that time) cybook, softbook, rocket, mobipocket,
MS Reader, Glassbook and Adobe (just to mention a few).



So, even if I am not capable of contributing much, I am a strong supporter
of an open e-book reader format. But honestly I am a bit worried about the
progress made by the OpenReader initiative. I am neither quite sure of its
relation with the OpenBerg initiative.



At the moment I'm gathering information on OpenReader and its relation with
open access, digital libraries and, more specifically critical text editions
(on which I am asked to give a lecture and write a paper). Actually I would
like to hear some opinions on these issues, but I don't know if this is the
right place, or if I should ask my questions in the TeBC group?




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/%20>
http://jodi.ecs.soton.ac.uk/Articles/v06/i01/Hillesund/





[Non-text portions of this message have been removed]

I've just read the DTH article on UNC's interest in digitization
(complete with mention of some interoperability and
preservation issues). You might check out:

-- The home page of the OpenReader Consortium
     http://www.openreader.org

-- Our not-yet-released list of endorsers--ranging from leading
e-bookstores to John Perry Barlow and Victor McCrary, the former e-book
standards expert at the National Institute of Standards and Technology
      http://www.openreader.org/supporters.html

For a total solution to the preservation issue, one cannot separate the
formats of popular and "important" works. Today's best-seller or
so-so-seller just might be tomorrow's Great Gatsby.

OpenReader will make possible a graceful evolution in e-books, which,
because of incompatibilities among ephemeral formats, are not yet a
truly serious medium. We'll rely on an XML/CSS/SVGish approach and build
on the production-level work of the Open eBook Forum, except that we
intend to go all the way with a consumer-level format, fit for
everything from junky novels to the most advanced STM publishing. We
will offer sophisticated hyperlinking and, yes, easier searching. And if
need be, we can play nice with PDF/A (warning: it lacks the same
multimedia capabilities and certain other technological advantages that
OpenReader will offer).

OpenReader is foremost an open format, for which anyone will be able to
build a reader. However, we also will develop a reference version of the
reader software.

We'd welcome an endorsement from the UNC administration and faculty, or
at least the former. That would be consistent with the school's interest
in open-access publishing and would make Chapel Hill look very good in
retrospect--and in the present as well. Within the area of format
standards for e-books and other digital publications, you could be the
clearcut leader in the academic community. Along the way, you could help
us shorten this horrid era of proprietary, DRMed e-book formats, which
are about as good for preservation as acidic paper.

Care for a teleconference with me and the main OpenReader founder, Jon
Noring, who has been involved in e-book standards for years, via his
status as an invited expert for the OeBF? I'm at 703-370-6540 in
Alexandria, Virginia. If you wanted, we could also include other
OpenReader founders such as Rick Barry, a respected archivist who
formerly was information services chief at the World Bank, and Lee
Passey, an e-commerce and security expert with a delightful loathing of
Draconian DRM.

David Rothman | davidrothman@...
Strategy and External Relations, OpenReader

P.S. Because of an email glitch, you may receive more than one copy of
this note. If so, my apologies ahead of time.



--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.10.4 - Release Date: 4/27/2005

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

On Sunday 20 March 2005 04:07, Jon Noring wrote:
> Let me provide a short "laundry list" of ways the OpenReader vision
> far surpasses "HTML":
>
> 1) The short-term OpenReader vision encompasses native recognition of
>    XHTML, SVG, MathML, and of course CSS2/CSS3. Longer-term, we are
>    considering native support for TEI-Lite, DocBook and other
>    specialized vocabularies (such as being developed for newspapers --
>    I even see a "Magazine Markup Language", optimized for the special
>    needs of periodicals.)

Question: Why doesn't every vector drawing program support the full SVG
spec? Why is it that most programs (such as OpenOffice) only write SVG but
won't read SVG?

Answer: Because it's VERY hard to implement the full SVG spec. It's easy to
create content in SVG, but very hard to interpret it. The Batik SVG library
is over 8 MiB large, and it supports only parts of the SVG spec!

I really hope that the OpenReader spec wouldn't become impossible to
implement on small, low-power devices. I do want OpenReader to be very
feature-complete, but at the same time I think that making the specs too
big would keep people from adopting it.

Also, we don't want an OpenReader viewer program that takes longer to start
than, and requires more resources than, the operating system of the
computer it's running on. *cough*acrobat reader*cough*

Slapping together a bunch of overlapping standards might not be a good idea.
Instead of supporting DocBook and whatnot, I'd recommend to go for one
internal format. (Then you can have some _external_ converter application
that knows how to convert from e.g. DocBook to the OpenReader format, if
you want to.) That way readers won't have to implement so much.

What you really don't want is OpenReader being a container format (like
avi), because then people would have to be aware of what formats their
OR-viewers support, and that's not going to happen. (Anything more than a
number would be too confusing for people who just want to use it, not
understand it. E.g. "OpenReader 2" is OK, but "OpenReader 1.2 with DocBook
3.4 codec" is clearly not.)


- Marcus

Phil wrote:

> The question is simple, the answer is not so simple. The question is
> why is this format the right one for what I want to do. That is, for
> different values of "I". If we are here we likely appreciate the
> advantage of open standards. But, the "best format" for different
> products (for lack of a better word) could be very different.

You are definitely correct in that the answer is not so simple!


> The "print" version of TUX (www.tuxmagazine.com) is currently a PDF.
> This is not because we like PDFs but because we didn't have a better
> answer based on our schedule. What we need is:
>
>  * Tight typographic controls. This doesn't mean "page must look like
>    X no matter what device is used to display it" but it does mean
>    that we need to be able to "make things look nice" which we all
>    know is not a choice with HTML.

Let me provide a short "laundry list" of ways the OpenReader vision
far surpasses "HTML":

1) The short-term OpenReader vision encompasses native recognition of
    XHTML, SVG, MathML, and of course CSS2/CSS3. Longer-term, we are
    considering native support for TEI-Lite, DocBook and other
    specialized vocabularies (such as being developed for newspapers --
    I even see a "Magazine Markup Language", optimized for the special
    needs of periodicals.)

    For example, a nice example of the power of XHTML+CSS is CSS Zen
    Garden, where (effectively) the same (and quite boring, under-the-
    hood) XHTML document is used for the various demonstration pages.
    By simply swapping the CSS style sheet, one can create marvelous
    and myriad presentational effects: http://www.csszengarden.com/

2) SVG (scalar vector graphics) is an XML-based markup vocabulary that
    allows more complex fixed layouts and graphics, where that is called
    for. Just about anything that can be done in PDF can be done in SVG.
    It is much more accessible and repurposeable than PDF. It is *very*
    interesting that Adobe is a lead developer in the SVG world -- they
    see its advantages.

    Since OpenReader plans to support SVG, and a publisher could put
    their entire publication within SVG (which I hope they don't do), a
    publisher can stay in the more "traditional" turf of what PDF now
    provides. So, in some ways, SVG offers a nice transition from fixed
    page layouts to flexible and dynamic layouts responsive to
    end-users display hardware and reading preferences.

3) We are interested in enabling font embedding within the OpenReader
    format. OpenReader systems, depending upon the end-user's hardware
    and software, may be able to install and use the embedded font.

There's others I could list, but that should suffice for the moment.


>  * Compact file size. This becomes mostly an issue of how graphics
>    can be handled. We want to use vector graphics as much as possible
>    but, for example, an author photo is not going to be vectors unless
>    the author is a robot.

My tests show that using structural/semantic markup (avoiding the
horrid presentational markup we see with, for example, Word dumps
to crappy, pre-Tidyized HTML), we minimize the size of the document to
about the smallest possible. The OpenReader format is currently
envisioned to compress the XML documents.

There's little that can be done to reduce the size of raster images
other than using a lossy compression format such as JPEG, and where
called for, DjVu. It's not really a publication format issue. Of
course, for vector graphics we have SVG.


>  * Ease of use by an end user. Today, most browsers talk to PDF
>    viewers so, while the browser doesn't know squat about a PDF,
>    the uninformed user feels like it does. Any format must work
>    at least this good

There's no impediment for web browsers to do the same when they
encounter an OpenReader Publication (ORP). This is very simple to
enable in most OS that I know of. In my web browser, I have several
plug-ins installed besides Acrobat Reader, and they all work
seamlessly whenever I click on particular file types.

Of course, end-users will have to install an OpenReader "user agent"
or reading system on their hardware, but the same now goes for Adobe
Acrobat Reader.

(What is especially intriguing is that it is possible for Opera,
Firefox, and other web browsers to provide built-in native OpenReader
support if they wanted to since these browsers now have to parse,
apply CSS, and render XML documents -- tasks which comprise the lion's
share of the effort in rendering OpenReader formatted publications.)


>  * Off-line viewing.

I infer you mean the end-user can print it out.

This is definitely possible to do with OpenReader. That is, there's
nothing inherent with the OpenReader format that won't allow this,
but it does get a little more complicated.

OpenReader does give the end-user more capability to tailor the print
version to their preferences and needs (e.g., big print). (Publishers
will provide a general default presentation, and most end-users will
probably just use whatever default presentation is given to them.)

Of course, another route is to provide both PDF-A and OR versions of
one's publication. The PDF-A could be generated from the master work
flow, or from the OpenReader formatted version. For example, refer to
the Prince product by YesLogic for an XML+SVG+CSS to PDF converter --
we've been in touch with the owner of YesLogic and it will certainly
be relatively easy for them, if they choose, to tweak Prince so it
will accept OpenReader as input for ready conversion to PDF. See
http://www.yeslogic.com/ . One can even envision built-in OpenReader
format to PDF-A converters within an OpenReader browser, so the
end-user can generate their own PDF from the OpenReader format they
purchase (if DRM allows them to do so.)


>  * Easy creation. Tux will soon be created in Scribus. Scribus creates
>    PDFs and does a good job of it. But, the scribus internal format
>    is XML-based. So, a tool is needed to produce the final document
>    from this.

If the authoring tool produces structurally-oriented XML markup, it
should be relatively easy for the authoring tool developer to export
it as an OpenReader publication, maybe using XSLT. (That's the whole
purpose in going with structural XML for the master format since it is
repurposeable.)

The issue of how to create an OpenReader formatted publication is
certainly an important topic, but is also pretty complex, and best
discussed separately.


> I don't feel I have listed any surprises up there. For a black and
> white, text and boxes kind of book the requirements are different
> but being able to list them and show the advantages and disadvantages
> seems really important.
>
> You (we) may feel that OpenReader is the right choice but if we can't
> compare it to other options for ourselves then how can we expect to
> convince a big player to get on the bandwagon.

OpenReader's vision is most developed for ebooks, and I know of
several "big players" in the ebook world who see its advantages. I
also believe it to be a superior "on-screen" delivery format for
periodicals and newspapers, since there's nothing inherent in those
markets and publication types which OpenReader won't be able to
handle. There's a lot more commonality in text-based publications than
there are differences, at least from my study of them.


> Well, that's my two cordobas worth.

Very good questions! I know I haven't sufficiently answered your
questions (just returned from a week-long trip and still a little
"foggy"), and probably generated more questions than were answered.
But a good place to start.


Jon

Thanks for your thoughts, Phil. I appreciate your previous encouragement
and will do my best to answer your questions, as long as you realize
that the most definitive responses will come from Jon Noring, the
e-book-standards-setter who has been at it for years. Let's wait for him
to return from vacation--probably tomorrow. He can correct me if I'm
wrong on any of the answers below. I take it for granted he'll add to them.

Beyond the issues you've discussed, let's keep our eye on the prize. We
want to pry e-book formats out of the hands of companies that care less
about long-term preservation than about their short-term profits. Let's
discuss things, but let's also work hard to come up with a robust format
and get a first-rate open source reader out the door in a reasonable
time. Here's to pre-empting those who at times want 15 percent of books'
cover prices! And along the way, let's help linux by forever ripping
apart the connection between formats and OSes. Remember, we already have
the support of major e-book retailers, the former NIST standards leader,
etc. They are "serious" players in the extreme. The missing players are
hardware companies and others with the cash to help us put this on the
fast track. We think they'll help when they understand the potential of
OpenReader--done right--to be the Firefox of e-books and spur hardware
sales.

>Maybe I am missing something but I don't see an answer I am looking
>for. I feel that answer could well be "the answer" that would be the
>key to getting some serious players interested.
>
>
In terms of production format, the serious players in the e-book
business are already interested in this, in effect. We simply want to do
a consumer format based largely on the existing format-exchange standard
approved by giants. It is relevant for other kinds of pubs as well.
Within the Open eBook Forum Jon has long been in the thick of the action
with the Publications Structure Working Group. See
http://www.openebook.org/oebf_groups/pswg.htm. PSWG's OEBPS Version 1.2
is pretty interesting as a starting point, as we see matters; but it
need a wrapper, etc.--plus it's hardly as if this thing is in stone
forever. We're open to suggestions. For more on 1.2, see
http://www.openebook.org/oebps/oebps1.2/index.htm .

>The question is simple, the answer is not so simple. The question is
>why is this format the right one for what I want to do. That is, for
>different values of "I". If we are here we likely appreciate the
>advantage of open standards. But, the "best format" for different
>products (for lack of a better word) could be very different.
>
>
I think you'll find that OpenReader could be very flexible for different
apps, different I's and different boxes. Just within the e-book world
alone, one must deal with hardware ranging from Pocket PCs to linux
boxes hooked up to huge monitors. I'd encourage you to talk to Jon
directly on this--literally talk. Again do remember that in terms of the
"best format" for the e-book world, we're already mostly there if you go
by the production format.

>I understand the concepts. I am not sure there is enough here yet to
>go beyond the standards but I feel that is the key. While getting from
>a number of source documents to OpenReader needs to be addressed, I
>will use what I want to do (with something) as an example of the type
>of information that I feel is needed.
>
>
Re "getting to": This is one advantage of "Open." We want to encourage
supporters to be out there to make the tools for the conversions and
importations, whether in a production or consumer. Already we've drawn
serious interest from someone who wants to get OpenReaders books into
legacy machines like old Palms and even  Rocket eBooks.

>The "print" version of TUX (www.tuxmagazine.com) is currently a PDF.
>This is not because we like PDFs but because we didn't have a better
>answer based on our schedule. What we need is:
> * Tight typographic controls. This doesn't mean "page must look like
>   X no matter what device is used to display it" but it does mean
>   that we need to be able to "make things look nice" which we all
>   know is not a choice with HTML.
>
>
There's always a battle between the causes of reflowability and "just
right," but one way or another things can look nice in OpenReader. Keep
telling Jon your priorities. I'm glad you acknowledge that a page
needn't look exactly the same on every device. Agreed! But whatever
device displays the page--yes, aesthetics should count.

> * Compact file size. This becomes mostly an issue of how graphics
>   can be handled. We want to use vector graphics as much as possible
>   but, for example, an author photo is not going to be vectors unless
>   the author is a robot.
>
>
Jon's the one with the definitive answers, I  suspect that other formats
should be used for photos of nonrobots. ;-) This is sometting for you
and other standards setters to discuss. Remember, the issue really
expands from e-book formats into those for graphics. Great example of
the advantages of a consensus!

Speaking of file size, let's remember the inherent advantages of an
XMLish approach in that area.

> * Ease of use by an end user. Today, most browsers talk to PDF
>   viewers so, while the browser doesn't know squat about a PDF,
>   the uninformed user feels like it does. Any format must work
>   at least this good.
>
>
I'd be POed if that weren't the case. Agree TOTALLY!!!!! Ideally things
can happen in terms of W3C browser standards if they do not already
address the above issue.

> * Off-line viewing.
>
>
Hey, no big deal. (Head nodding!)

> * Easy creation. Tux will soon be created in Scribus. Scribus creates
>   PDFs and does a good job of it. But, the scribus internal format
>   is XML-based. So, a tool is needed to produce the final document
>   from this.
>
>
First off, I can't resist reminding you that the scribus internal format
is just that--a product-specific internal format. By contrast, with
OpenReader, we're already starting out with an industry-approved
XML/CSSish production format.

If we can standardize OpenReader sufficiently, then publishers can
simply take  the production format and apply a wrapper and other
trimmings. No big deal.

Oh, and yes, we're keen on development of tools for both creation and
translation of content to get it in production format or very close.

>I don't feel I have listed any surprises up there. For a black and
>white, text and boxes kind of book the requirements are different
>but being able to list them and show the advantages and disadvantages
>seems really important.
>
>
I would encourage you and others to keep telling us what you need. As to
how these requirements can be met--well, others can join us in listing
the alternatives. But it would be a shame to take the focus and momentum
away from the XML/CSSish approach that some of the best e-book geeks in
the world have spent years perfecting, only to be thwarted by marketers
and lawyers.

>You (we) may feel that OpenReader is the right choice but if we can't
>compare it to other options for ourselves then how can we expect to
>convince a big player to get on the bandwagon.
>
>Well, that's my two cordobas worth.
>
>
Well, again, I've already told how OpenReader already reflects years of
consensus within the book industry, one that is the among the most
finnicky over formats. It's not as if Jon said, "Hey, I like this, I'm
King, let's go with it." In the production standards area he's
reflecting the joint opinion of companies with a cumulative worth in the
tens of billions. Might ain't right. But this won't hurt us in the
marketplace. And as for consumer standards, here's one more reminder of
the endorsements we have among retailers such  as eBooks.com and eBookAd.

Thanks,
David / 703-370-6540

P.S. Tried to call you via both Packet8 and Skype, but either the line
or the circuits were busy. Phil, please feel free to call me.






--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.7.3 - Release Date: 3/15/2005

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.7.3 - Release Date: 3/15/2005


[Non-text portions of this message have been removed]

Maybe I am missing something but I don't see an answer I am looking
for. I feel that answer could well be "the answer" that would be the
key to getting some serious players interested.

The question is simple, the answer is not so simple. The question is
why is this format the right one for what I want to do. That is, for
different values of "I". If we are here we likely appreciate the
advantage of open standards. But, the "best format" for different
products (for lack of a better word) could be very different.

I understand the concepts. I am not sure there is enough here yet to
go beyond the standards but I feel that is the key. While getting from
a number of source documents to OpenReader needs to be addressed, I
will use what I want to do (with something) as an example of the type
of information that I feel is needed.

The "print" version of TUX (www.tuxmagazine.com) is currently a PDF.
This is not because we like PDFs but because we didn't have a better
answer based on our schedule. What we need is:
  * Tight typographic controls. This doesn't mean "page must look like
    X no matter what device is used to display it" but it does mean
    that we need to be able to "make things look nice" which we all
    know is not a choice with HTML.
  * Compact file size. This becomes mostly an issue of how graphics
    can be handled. We want to use vector graphics as much as possible
    but, for example, an author photo is not going to be vectors unless
    the author is a robot.
  * Ease of use by an end user. Today, most browsers talk to PDF
    viewers so, while the browser doesn't know squat about a PDF,
    the uninformed user feels like it does. Any format must work
    at least this good.
  * Off-line viewing.
  * Easy creation. Tux will soon be created in Scribus. Scribus creates
    PDFs and does a good job of it. But, the scribus internal format
    is XML-based. So, a tool is needed to produce the final document
    from this.

I don't feel I have listed any surprises up there. For a black and
white, text and boxes kind of book the requirements are different
but being able to list them and show the advantages and disadvantages
seems really important.

You (we) may feel that OpenReader is the right choice but if we can't
compare it to other options for ourselves then how can we expect to
convince a big player to get on the bandwagon.

Well, that's my two cordobas worth.
--
Phil Hughes, fyl@...  Phone: 505-713-5675
Aptdo. Postal 201, Esteli, Esteli, NICARAGUA

Phil: Let me add my thanks to David's. Back when Yahoo Groups  was e-Groups
and owned by Carl Page et al, there was an option for  having the group without
advertising for something like $5 a month. But that may  have changed when
Yahoo bought eGroups out.  As one of the moderators, I'm  also eager to get to a
non-moderated list as soon as we can. But I don't think  it's a bad idea to
approach this a step at a time.

Let me also reinforce David's message about endorsements. We are working on
several fronts to obtain financing to move ahead with development; but we are
in  the old chicken-and-egg situation in which vendors want to see buy-in
before  they invest, but we can't get buy-in without some of them coming forward
first.

Regards,

Rick Barry
_www.mybestdocs.com_ (http://www.mybestdocs.com)
Cofounder, Open Reader Consortium
_www.openreader.org_ (http://www.openreader.org)
In a message dated 3/18/2005 7:46:17 A.M. Eastern Standard Time,
openreader-format@yahoogroups.com writes:

Date: Thu, 17 Mar 2005 07:10:42 -0600
From: Phil Hughes <fyl@...>
Subject: Thanks, david

Thanks  for the background. I pretty much had the same question but
hadn't gotten  around to asking. This reinforces my interest (and,
thus, the interest of  SSC/Linux Journal/TUX to participate.

I am not a great fan of Yahoo  groups, if for no other reason that the
built-in advertising, so if at some  point you decide to move to
something "more open", whether that be just a  mailman list of want
a web site, I would be happy to donate some resources  to the cause.
--
Phil Hughes, fyl@...  Phone:  505-713-5675
Aptdo. Postal 201, Esteli, Esteli, NICARAGUA






[Non-text portions of this message have been removed]

Marcus Sundman wrote:

>So, what's the status of the project?
>
>
Assuming that they haven't gotten another big project to distract 'em,
we've got some XML/CSS-hip programmers ready to go. It's the money issue
holding us up since we're not a branch of Microsoft or whatever. We'll
do the pure Open Source volunteer route along if need be. But some core
programmers could really speed things up. We'll welcome your thoughts on
finding appropriate sponsors interested in a truly open format.

>What needs to be done next?
>
>
Well, setting up the commitees and populating them. We WANT finnicky
users. Plus programmers who can meet their needs!

>Is there some (rough) schedule?
>
>
Let's get the money and the volunteers. Spread the word. We've already
made progress just with the interest of Phil Hughes! It's a start. Lots
more ahead! I hope you hang in there and keep speaking up, ideally as
one of the standards setters if you can find time after all.

Thanks,
David


--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.7.3 - Release Date: 3/15/2005

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.7.3 - Release Date: 3/15/2005


[Non-text portions of this message have been removed]

So, what's the status of the project?
What needs to be done next?
Is there some (rough) schedule?

- Marcus Sundman

Now the messages are visible to everyone. Nice!

On Thursday 17 March 2005 20:54, davidrothman wrote:
> The reason for Jon's caution is simply that he wants the list to have
> focus and also avoid overwhelming the mailboxes of valuable and busy
> contributors to the OpenReader effort. Yes, moderation is a
> possibility. That does take time, however. Another possible solution
> might even be the creation of a second list--maybe even
> nonmoderated?--once we're further along. Your thoughts?

I don't see how the main list could be forcibly kept very low-volume if
there is a lot to discuss. Perhaps there could be a low-volume
"announcements" list, where some admin could post whenever some important
decision has been made on the main list. That way people who want to follow
everything could lurk on the main list and people only interested in the
results of the discussions could subscribe to the announcements list.

Anyway, this is not something that needs to be done now. After all, there's
only a total of 10 messages on the main list ATM. ;-)


- Marcus Sundman

> Thanks for the background. I pretty much had the same question but
> hadn't gotten around to asking. This reinforces my interest (and,
> thus, the interest of SSC/Linux Journal/TUX to participate.

Jon and I are extremely grateful, Phil. You've made my week--in fact,
my month. Imagine OpenReader running on dirt-cheap tablets, PDAs or
cellphones with embedded linux. The OpenReader effort should serve as
a much-needed reminder to Microsoft of the folly of linking Microsoft
Reader and the related e-book format to Windows. My own belief that
Microsoft really sees its Reader mainly as a way to promote the
operating system and the related DRM. I find that 'tude to be most
insulting to those of us who so passionately care about e-books.

We'll cherish your suggestions of all kinds. Are there any people
you'd recommend our contacting at Motorola, Sun, IBM or other
hardware-related companies with the resources to help us in a major
way? Or what about the initiative to get that $100 computer going?
Those aren't just theoretical matters to me. I'm a former poverty beat
reporter interested in Digital Divide issues, and afffordable e-books
on $100 systems could help vastly. You can email me privately if you
want.

Our dream scenario would be an open source effort spearheaded by
accomplished core programmers (yes, we have some in mind--big linux
fans, by the way). That means money. But even endorsements would help.
Over on the content side, we're already in great shape with
endorsements from eBooks.com and the like. And we're also thrilled
that Victor McCrary, who ran the e-book standards effort at NIST,
likes what we're up to. So does John Perry Barlow, another endorser.

As for the Yahoo Groups issue, that's something for you and Jon and
others to discuss. I personally can see pros and cons either way. Jon
and I aren't the biggest fan of the ads either. We started with Yahoo
Groups because of the time factor and the fact that this would expose
us to a wide range of users. But later on? Who knows? What's more,
maybe the real workers could migrate from Yahoo in time, while we
retained a presence here to keep in touch with Joe/Jane Doe User. I'd
love to see an open source OpenReader kick Microsoft Reader's butt,
the way Firefox is starting to do to Explorer. That means reading
software that newbies can easily use (while geeks can enjoy a rich
feature set--far  more extensive than the pathetic options in
Microsoft Reader).

Reminder: As noted in my previous item, Jon is out of town and having
problems with his laptop/connection, but I'll be pleased to relay
messages. I hope that you two will be talking directly, literally
talking, very soon.

Thanks,
David / 703-370-6540



--- In openreader-format@yahoogroups.com, Phil Hughes <fyl@a...> wrote:
> Thanks for the background. I pretty much had the same question but
> hadn't gotten around to asking. This reinforces my interest (and,
> thus, the interest of SSC/Linux Journal/TUX to participate.
>
> I am not a great fan of Yahoo groups, if for no other reason that the
> built-in advertising, so if at some point you decide to move to
> something "more open", whether that be just a mailman list of want
> a web site, I would be happy to donate some resources to the cause.
> --
> Phil Hughes, fyl@a...  Phone: 505-713-5675
> Aptdo. Postal 201, Esteli, Esteli, NICARAGUA

Hi, Marcus. You could well be right. Let's see what others think about
your proposal. Anyone else care to comment? I do agree with you on the
desirability of all kinds of people being able to know early on about
drafts and comment on them one way or another, before things get
locked up. It isn't just The Right Thing to do. It's the most
efficient way to be responsive to users' needs.

The reason for Jon's caution is simply that he wants the list to have
focus and also avoid overwhelming the mailboxes of valuable and busy
contributors to the OpenReader effort. Yes, moderation is a
possibility. That does take time, however. Another possible solution
might even be the creation of a second list--maybe even
nonmoderated?--once we're further along. Your thoughts?

Be interesting to see how Jon and other people here feel about this
and other options. And what are people's thoughts on the e-mail volume
question? That could influence how tightly Jon moderates messages, if
he does use moderation.

Meanwhile, so you'll know why you're not hearing from Jon, he is out
of town and is having laptop and connection problems. Might be another
few days. If you or anyone else urgently needs to reach Jon, just
email me at davidrothman@... or call me at 703-370-6540 and
I'll make sure he gets the message.

Again, thanks for the continued feedback! - David


--- In openreader-format@yahoogroups.com, Marcus Sundman
<sundman@i...> wrote:
> On Wednesday 16 March 2005 16:07, Jon Noring wrote:
> > David replied to Marcus:
> > > Marcus Sundman wrote:
> > >> Why is this group private? After all, it's called _open_reader,
> > >> right, so shouldn't this group be open and not "members only"?
> > >
> > > Excellent question, Marcus. Jon Noring, OpenReader's original
> > > founder, might be on the road now and out of touch; but I'll
> > > give you my two cent's worth, as a fellow founder.
> >
> > The reason is that this group was originally created for the
> > formal OpenReader Format Working Group to deliberate, and to
> > be able to freely discuss issues.
>
> Would giving the public read access to the mailing list (and the
possibility
> to post messages that go through admin review before appearing on
the
> mailing list) in any way hinder these goals? Or by giving the public
access
> to specification drafts while they are being made, and thus give
people the
> chance to comment on things in an early stage when it's still
"cheap" to
> make larger changes?
>
> I think it'd be completely unacceptable to allow everyone to make
changes to
> some carefully crafted specification, but I do believe it is a
great
> resource to have people commenting on things one do.
>
>
> > Most standards working groups have such private forums where the
messages
> > are not available to the general public. Examples of standards
bodies with
> > this policy include W3C.
>
> The relevant question is whether it's better to have it that way, or
if it's
> better to be more open.
>
>
> - Marcus Sundman

Thanks for the background. I pretty much had the same question but
hadn't gotten around to asking. This reinforces my interest (and,
thus, the interest of SSC/Linux Journal/TUX to participate.

I am not a great fan of Yahoo groups, if for no other reason that the
built-in advertising, so if at some point you decide to move to
something "more open", whether that be just a mailman list of want
a web site, I would be happy to donate some resources to the cause.
--
Phil Hughes, fyl@...  Phone: 505-713-5675
Aptdo. Postal 201, Esteli, Esteli, NICARAGUA

On Wednesday 16 March 2005 16:07, Jon Noring wrote:
> David replied to Marcus:
> > Marcus Sundman wrote:
> >> Why is this group private? After all, it's called _open_reader,
> >> right, so shouldn't this group be open and not "members only"?
> >
> > Excellent question, Marcus. Jon Noring, OpenReader's original
> > founder, might be on the road now and out of touch; but I'll
> > give you my two cent's worth, as a fellow founder.
>
> The reason is that this group was originally created for the
> formal OpenReader Format Working Group to deliberate, and to
> be able to freely discuss issues.

Would giving the public read access to the mailing list (and the possibility
to post messages that go through admin review before appearing on the
mailing list) in any way hinder these goals? Or by giving the public access
to specification drafts while they are being made, and thus give people the
chance to comment on things in an early stage when it's still "cheap" to
make larger changes?

I think it'd be completely unacceptable to allow everyone to make changes to
some carefully crafted specification, but I do believe it is a great
resource to have people commenting on things one do.


> Most standards working groups have such private forums where the messages
> are not available to the general public. Examples of standards bodies with
> this policy include W3C.

The relevant question is whether it's better to have it that way, or if it's
better to be more open.


- Marcus Sundman

Marcus, these are excellent ideas. Thanks for those wonderful
suggestions. If nothing else, I hope that you'll spread around news of
OpenReader's existence and talk it up to people who could help. Glad
to see Jon being responsive in his own reply. - David

--- In openreader-format@yahoogroups.com, Marcus Sundman
<sundman@i...> wrote:
> On Wednesday 16 March 2005 15:37, David H. Rothman wrote:
> > Openreader-format has a member-approval process because among other
> > things we're keen on keeping the format--open.
>
> You might want to restrict the access to post to the list (e.g. by
requiring
> of approval by some admin if the message sender is not a member),
but imo
> everyone should be able to read the messages on the list. Most mailing
> lists have a lot of lurkers who just want to follow the progress and
> perhaps occasionally comment something if the topic touches that
person's
> area of expertise or pet peeve. This can be a great resource, and in my
> experience it has very few, if any, downsides.
>
>
> > Tell us a little about yourself, if you'd like, and the reason for
your
> > own interest in OpenReader, and what you might contribute to the
effort.
>
> I'm just an ordinary guy who likes seeing things done The Right Way(tm).
>
> I want to be able to access any of my reference guides, research papers
> currently of interest, dictionaries, novels etc. pretty much anytime
and
> anywhere. I want to be able to search these, to add cross-references
and
> personal notes here and there in them etc. Furthermore, I dislike page
> flipping (especially a page break in the middle of a complicated
equation
> or something), but I still want to be able to refer to a very specific
> point in the text. I want to have a decent navigation system, be
able to
> open hyperlinked locations in a new view and easily manage all views
i have
> open (e.g. have two views open side-by-side). I want to be able to
see the
> difference between different versions of some particular document,
and to
> see and navigate the change history of documents I've written. And I'm
> never, ever going to buy information that is locked to some particular
> hardware or software that I can't modify myself.
>
> I'd be damned if I let someone create a global e-book format with
the same
> problems that annoy me so much in the current "solutions". ;-)
>
> Although I'm a professional developer I'm afraid I won't have the
time to
> contribute much, so you might want to revoke my membership in this
group.
> I'd very much like to be able to lurk on this mailing list, though,
if this
> is where the important discussions will be taking place.
>
>
> - Marcus Sundman

On Wednesday 16 March 2005 15:37, David H. Rothman wrote:
> Openreader-format has a member-approval process because among other
> things we're keen on keeping the format--open.

You might want to restrict the access to post to the list (e.g. by requiring
of approval by some admin if the message sender is not a member), but imo
everyone should be able to read the messages on the list. Most mailing
lists have a lot of lurkers who just want to follow the progress and
perhaps occasionally comment something if the topic touches that person's
area of expertise or pet peeve. This can be a great resource, and in my
experience it has very few, if any, downsides.


> Tell us a little about yourself, if you'd like, and the reason for your
> own interest in OpenReader, and what you might contribute to the effort.

I'm just an ordinary guy who likes seeing things done The Right Way(tm).

I want to be able to access any of my reference guides, research papers
currently of interest, dictionaries, novels etc. pretty much anytime and
anywhere. I want to be able to search these, to add cross-references and
personal notes here and there in them etc. Furthermore, I dislike page
flipping (especially a page break in the middle of a complicated equation
or something), but I still want to be able to refer to a very specific
point in the text. I want to have a decent navigation system, be able to
open hyperlinked locations in a new view and easily manage all views i have
open (e.g. have two views open side-by-side). I want to be able to see the
difference between different versions of some particular document, and to
see and navigate the change history of documents I've written. And I'm
never, ever going to buy information that is locked to some particular
hardware or software that I can't modify myself.

I'd be damned if I let someone create a global e-book format with the same
problems that annoy me so much in the current "solutions". ;-)

Although I'm a professional developer I'm afraid I won't have the time to
contribute much, so you might want to revoke my membership in this group.
I'd very much like to be able to lurk on this mailing list, though, if this
is where the important discussions will be taking place.


- Marcus Sundman

David replied to Marcus:
> Marcus Sundman wrote:

>> Why is this group private? After all, it's called _open_reader,
>> right, so shouldn't this group be open and not "members only"?

> Excellent question, Marcus. Jon Noring, OpenReader's original
> founder, might be on the road now and out of touch; but I'll
> give you my two cent's worth, as a fellow founder.

The reason is that this group was originally created for the
formal OpenReader Format Working Group to deliberate, and to
be able to freely discuss issues. Most standards working groups
have such private forums where the messages are not available
to the general public. Examples of standards bodies with this
policy include W3C.

However, since then, this group has evolved to become more public
in focus, so I'll reset archive access so they are available to
non-members. In a practical sense, it probably doesn't matter; but
it certainly does leave a certain impression.

Jon Noring

Excellent question, Marcus. Jon Noring, OpenReader's original founder,
might be on the road now and out of touch; but I'll give you my two
cent's worth, as a fellow founder.

Openreader-format has a member-approval process because among other
things we're keen on keeping the format--open.

The Open eBook Forum, aka the Proprietary Formatters Association,
started out just like OpenReader, complete with ballyhoo from Microsoft
as to how the Forum would avoid VHS vs. Beta at the consumer level.
(http://www.microsoft.com/typography/links/news.aspx?NID=567) Well, I
don't have to tell you the rest of the story.

Jon and I would like very much for the OpenReader Consortium to avoid
becoming OeBF II. So we are most interested in the intent of people who
join the OpenReader list. We want them truly devoted to open standards.

I hope this is helpful, Marcus. Tell us a little about yourself, if
you'd like, and the reason for your own interest in OpenReader, and what
you might contribute to the effort.

About us:

1. Jon is moderator of the eBook Community list with more than 2,000
members. He has been in e-books since the early '90s. Jon's been a
leading standards-setter in the Open eBook Forum, so, firsthand, he
knows the horrors of letting the short-term-minded marketers and lawyers
set the tone. The OeBF has benefited from the hardwork and idealism of
brilliant techies, who came up with wonderful production standards but
were not allowed to do a consumer standard. This time around, Jon
doesn't want to be sold down the river again.

2. I myself am a writer who dislikes the idea of Microsoft and friends
siphoning so much money away from publishers and--indirectly--authors.
Format/DRM fees can be 15 percent or more at times. I also dislike the
idea of books being lost becaue of ephemeral formats and the
accompanying proprietry DRM. For more than a dozen years, in places
ranging from an MIT Press information science collection to the
Washington Post op-ed page, I've pushed for well-stocked national
digital library systems.

3. As for Rick Barry, another founder, he's former information services
chief for the World Bank and like me is concerned about the durability
of publications and other texts. He brings us the perspective of an
internationally respected expert in digital archives.

So that's the lowdown. The mission of this list isn't to debate the
desirability of an open format but to get on with the job, and we're
most interested in the participation of *like-minded* people as opposed
to the proprietary format zealots.

David Rothman | davidrothman@... | 703-370-6540



Marcus Sundman wrote:

>Why is this group private? After all, it's called _open_reader,
>right, so shouldn't this group be open and not "members only"?
>
>
>
>
>
>----------------------------------------------------
>Post a message:   openreader-format@yahoogroups.com
>Unsubscribe:      openreader-format-unsubscribe@yahoogroups.com
>Switch to digest: openreader-format-digest@yahoogroups.com
>Switch to normal: openreader-format-normal@yahoogroups.com
>Put mail on hold: openreader-format-nomail@yahoogroups.com
>Administrator:    openreader-format-owner@yahoogroups.com
>----------------------------------------------------
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>



--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.7.3 - Release Date: 3/15/2005

Why is this group private? After all, it's called _open_reader,
right, so shouldn't this group be open and not "members only"?