Two examples of EPUB3 Manga
MURATA Makoto
Here goes. I am grateful to the author (Kuratsuka Riko) and
members of the Japanese EPUB project supported by MIC.
http://epub-revision.googlecode.com/files/harukoJPEG.epub
http://epub-revision.googlecode.com/files/harukoHTML.epub
Comments welcome.
--
Praying for the victims of the Japan Tohoku earthquake
Makoto
Hadrien Gardeur
- the ability to break up the page into multiple panels (for smaller screens) with transitions between the panels
- a mapping between text/image to enable search
MURATA Makoto (FAMILY Given)
> HTML file ?
Yes, that is a possibility. I still do not know which of the three
possibilities: HTML Manga, SVG Manga, or JPEG Manga is better. I am
aware of some advanced use of HTML5 for Manga.
We should try SVG manga and study pros and cons. If I have time,
I will create another example.
Cheers,
Makoto
Hadrien Gardeur
Yes, that is a possibility. I still do not know which of the three
possibilities: HTML Manga, SVG Manga, or JPEG Manga is better. I am
aware of some advanced use of HTML5 for Manga.
We should try SVG manga and study pros and cons. If I have time,
I will create another example.
MURATA Makoto
> this effort. How could we start a group effort on comics/manga for EPUB ?
One possibility is to have an IDPF workshop dedicated to fixed layout
such as Manga in October (around the EPUB Asia-Pacific Exchange
Conference in Taiwan), as suggested by Bill McCoy in the previous
workshop. I am wondering what I can do.
Daniel Weck
SVG only:
http://www.bifter.co.uk/issues/8.svg
HTML presentation:
http://www.bifter.co.uk/issue/8/
Cheers, Daniel
Bill McCoy
--
bmc...@idpf.org
MURATA Makoto
It is true that most of the existing e-manga uses fixed layout. However,
to overcome the screen size problem, adaptive-layout manga has been
tried. I would not be surprised if future e-manga heavily uses adaptive-
layout.
Unfortunately, most of the adaptive-layout manga is not publicly
available. But here are some examples. Change the
window/font size and you see the layout change.
http://bizpal.jp/epub/contest01/Download?id=a5741e72-b9bd-4281-bdae-f9cf3fc0bf37
http://bizpal.jp/epub/contest01/Download?id=dc3f0d4b-52bf-4e5c-abd1-9be75de8fd3a
I am wondering how the next workshop should be organized. I agree
that we should focus on publication types that typically use fixed-layout
but I also think that we should not eliminate the use of adaptive-layout.
Technologies required for such adaptive-layout may well be different
from those discussed in the previous workshop.
Regards,
Makoto
2011/7/25 Bill McCoy <bmc...@idpf.org>:
--
Bill Kasdorf
--Bill Kasdorf
Bill McCoy
Grazioli, Frank - Hoboken
_________________________________________________________________________
Frank Grazioli | John Wiley & Sons, Inc. | Professional & Trade Group | +1 201 748 6436
Leonard Rosenthol
Leonard Rosenthol | PDF Architect · Principal Scientist | Adobe Systems Incorporated | p. 408.657.PDFS | c. 215.808.4978 | leon...@adobe.com
Hadrien Gardeur
MURATA Makoto
> Designing a complex solution that would fit (in theory) a little bit better with our idea of "pre-paginated content" might be the wrong direction if we'd like to have the widest adoption possible.
I have the same worry. But I also have other concerns. First,
EPUB3 allows too many possibilities (HTML-and-JPEG, SVG-and-JPEG,
and directly-JPEG) as simple solutions. Do these too many
possibilities make manga authoring and implementation works
difficult? Second, people rely on complicated Javascript and CSS for
adaptive "pre-paginated content". Do such complicated EPUB manga
cause interoperability problems? It appears that we are already
preparing topics for the next workshop!
Hadrien Gardeur
I have the same worry. But I also have other concerns. First,
EPUB3 allows too many possibilities (HTML-and-JPEG, SVG-and-JPEG,
and directly-JPEG) as simple solutions. Do these too many
possibilities make manga authoring and implementation works
difficult? Second, people rely on complicated Javascript and CSS for
adaptive "pre-paginated content". Do such complicated EPUB manga
cause interoperability problems? It appears that we are already
preparing topics for the next workshop!
Bill McCoy
Bill Kasdorf
This is an issue we have been dealing with in the nextPub/PRISM-to-EPUB Mapping Committee (predominantly magazine publishers wanting to use EPUB 3 as a distribution standard). The issue specifically comes up in terms of ads in magazines (e.g., the inside front cover) which are almost universally supplied as PDFs but which even so are largely bitmaps (big color images are common, obviously, plus text). The recommendation that came out of our call this week was that instead of providing PDFs with fallbacks to image files that are Core Media Types, the best strategy would be to provide these as SVGs (even though those SVGs would be largely just bitmaps under the hood). That enables those ads to be spine-level content documents, which is important, because from the magazine’s point of view, they are structurally parallel to articles (in fact, in the current PRISM scheme, they are considered a type of article), not components of articles. We also thought that if a publisher or advertiser had a problem with SVG, the second choice would be simply an XHTML content document that contains the image in a core media type.
Thought this might have a bearing on this discussion, though it is not about manga and typically involves only isolated single pages.
--Bill Kasdorf
From: epub-work...@googlegroups.com [mailto:epub-work...@googlegroups.com] On Behalf Of Bill McCoy
Sent: Wednesday, July 27, 2011 10:04 AM
To: epub-work...@googlegroups.com
Subject: Re: Two examples of EPUB3 Manga
It would be awesome if someone interested in manga with technical chops had a look at a title fulfilled to the B&N Nook Color magazine application. Folks who know have indicated that it is very basic fixed-format EPUB which has bitmap images as spine items. No DRM apparently (who knew B&N was so progressive!). I hope to prevail upon Roger Webster of B&N to present about their solution at our intended workshop but any advance fact-finding can only help.
Leonard Rosenthol
Reply-To: "epub-work...@googlegroups.com" <epub-work...@googlegroups.com>
Date: Wed, 27 Jul 2011 02:53:09 -0700
To: "epub-work...@googlegroups.com" <epub-work...@googlegroups.com>
Subject: Re: Two examples of EPUB3 Manga
MURATA Makoto
> Technically I believe it's illegal EPUB 2 and EPUB 3 because bitmap images
> aren't allowed in the spine but this could be either a) bug-fixed into
> legitimacy (wrt EPUB 3, before the concrete has hardened) or b) if it isn't
> too burdensome SVG containers pointing to images could be at spine level
> which is perfectly OK EPUB 3 and might add some value (esp. if CTM
> manipulation of the base image data was in some cases desirable). I believe
> that with spine-level fallbacks accessibility via XHTML text alternatives
> could be provided although SVG would also provide intrinsic fallbacks.
This spine-level falback is exactly what I did in
http://epub-revision.googlecode.com/files/harukoJPEG.epub
Every JPEG item references to a navigation document, which is HTML.
> I don't share Makoto's worry because I think there are different types of
Which of my worries are you talking about? I have too many ;-)
If you are talking about "Do these too many possibilities make
manga authoring and implementation works difficult? ", one way
to address is to create an EPUB manga profile without changing
EPUB3.
Regards,
Makoto
--
Roger Webster
My two cents: I meant to push for spine-level inclusion of images in ePub 3, and it got past me; I would vote yes. I would also say that we already know that full-page images are a key use case – the real question is whether they are/will be key for ePub (I think “yes”). FYI, the B&N magazine format is nearly legal ePub; the main outlier being that we do, in fact, use images as spine items. I couldn’t talk about this particular point last summer when it was being developed due to secrecy requirements around Nook Color development, but it’s no secret now.
We don’t (currently) describe these magazines as ePubs, though they do actually render in Adobe Digital Editions (though, of course, the images don’t scale).
--Roger Webster
From: epub-work...@googlegroups.com [mailto:epub-work...@googlegroups.com] On Behalf Of Leonard Rosenthol
Sent: Wednesday, July 27, 2011 7:56 am
To: epub-work...@googlegroups.com
Subject: Re: Two examples of EPUB3 Manga
cbr/cbz, however, is just a collection of images – there is no TOC, no metadata, nothing just a bunch of image files. They even have to be in alphabetical order since they are processed that way. Converting a cbr/cbz viewer into an EPUB viewer – even just a limited one – would require a bunch of work (parsing all the relevant XML "toc" files) let alone handling HTML and/or SVG. It's also more work on the producer/creator – though most of it could be done via "templates".
If we were to consider comics (or other full page image formats) as a key use case for EPUB, then I think we should think about what Bill suggested in terms of allowing raster image formats in the spine. I can't see that as a burden on viewers – they already know how to display them – and would be an easy spec change.
I've written a cbr/cbz->PDF converter that I use for my own purposes. Might be interesting to modify it to output EPUB and see what the results look like in various viewers…. (now if I just had spare time :).
Leonard
From: Hadrien Gardeur <hadrien...@feedbooks.com>
Reply-To: "epub-work...@googlegroups.com" <epub-work...@googlegroups.com>
Date: Wed, 27 Jul 2011 02:53:09 -0700
To: "epub-work...@googlegroups.com" <epub-work...@googlegroups.com>
Subject: Re: Two examples of EPUB3 Manga
Manga/comics are mostly paginated but many proprietary formats also have another layout where the page is divided in multiple elements and transitions are added between each of these elements. Picture books could have the same requirements, but unlike other publications where most of the content will be in an HTML "page", manga/comics will rely almost entirely on images.
Another important thing to keep in mind: most comics/manga are already illegally distributed using .cbr/.cbz files which are essentially images in a ZIP or RAR package. Moving from .cbr/.cbz to EPUB isn't that far of a stretch and if the implementation is easy enough, many existing comic viewers/readers would also add EPUB support. Designing a complex solution that would fit (in theory) a little bit better with our idea of "pre-paginated content" might be the wrong direction if we'd like to have the widest adoption possible.
Hadrien
This electronic mail message contains information that (a) is or
may be CONFIDENTIAL, PROPRIETARY IN NATURE, OR OTHERWISE
PROTECTED
BY LAW FROM DISCLOSURE, and (b) is intended only for the use of
the addressee(s) named herein. If you are not an intended
recipient, please contact the sender immediately and take the
steps necessary to delete the message completely from your
computer system.
Not Intended as a Substitute for a Writing: Notwithstanding the
Uniform Electronic Transaction Act or any other law of similar
effect, absent an express statement to the contrary, this e-mail
message, its contents, and any attachments hereto are not
intended
to represent an offer or acceptance to enter into a contract and
are not otherwise intended to bind this sender,
barnesandnoble.com
llc, barnesandnoble.com inc. or any other person or entity.
Bill Kasdorf
Remember, though, that there’s an issue around “deconstructing” a manga/comics pages, so that, for example, panels can be displayed individually, or in a different arrangement, on different devices (e.g. phones). So while the issue of manga/comics does seem like a very special case of page-for-page fidelity, bitmaps of entire pages, etc., I’m concerned that this may not address the needs of manga/comics/graphic novel publishers as it really should.
This discussion (and Makoto’s immediately preceding e-mail, suggesting a special Manga EPUB spec) reinforces my feeling that we ought to first be discussing the full spectrum of fixed/adaptive page layout concerns and _then_ decide how we want to carve out separate working groups. The example of ads in magazines I sent out earlier is an obvious case where a single EPUB will need to address the full range of a truly single-page bitmap (an ad) combined with reflowable content that needs to be adaptive (most articles) while perhaps doing that adaptation within a fixed context (e.g., a spread)—concerns common to textbook and cookbook publishers, and many more, as well.
Having said that, I defer to my esteemed colleague Bill M who does in fact make a strong case for pursuing adaptive and fixed issues in parallel. If we do so, though, there needs to be a very good mechanism for keeping those two groups in synch and aware of each other’s work.
--Bill Kasdorf
Bill Kasdorf
Roger, can you discuss the issues around those images being handled via XHTML or SVG spine items, which means they _could_ be legal EPUB 3 without a change in the spec? I may be being naïve, but that doesn’t seem to be too difficult when you’re talking about a single image like an ad.
On the other hand, are there really any practical issues for reading systems around enabling any of our four core media types for images as spine items?
--Bill Kasdorf
From: epub-work...@googlegroups.com [mailto:epub-work...@googlegroups.com] On Behalf Of Roger Webster
Sent: Wednesday, July 27, 2011 11:35 AM
To: epub-work...@googlegroups.com
George Kerscher
Dear All,
In the examples, having a mechanism for describing the images that present ads, comics, etc. for persons with disabilities needs to be present. Just a reminder, grin.
Best
George
From: epub-work...@googlegroups.com [mailto:epub-work...@googlegroups.com] On Behalf Of Roger Webster
Sent: Wednesday, July 27, 2011 9:35 AM
To: epub-work...@googlegroups.com
MURATA Makoto
is spine-level inclusion of images WITHOUT providing fallback HTML.
If we allow it, we should probably also make navigation documents
optional so that HTML-free EPUB is possible.
Regards,
Makoto
2011/7/28 Roger Webster <rweb...@book.com>:
--
Leonard Rosenthol
etc.)?
Leonard
>> like in various viewersŠ. (now if I just had spare time :).
Roger Webster
Last year, the answer was simply “overhead.” Our current magazine viewer implementation is not browser-based, so no SVG and no XHTML. The XHTML would not have difficult to parse, but we decided to strip things down as much as we could to allow overlapped image/page loading and get decent page-turn/swipe performance. A few items got thrown over the transom in that exercise.
--Roger
MURATA Makoto
> In the examples, having a mechanism for describing the images that present
> ads, comics, etc. for persons with disabilities needs to be present. Just a
> reminder, grin.
First, I have a very high respect to DAISY.
One of my two examples uses the navigation HTML document as fallback for
every JPEG file. But I do not think that that example is really accessible.
Can manga be accessible when the script is not available? For existing manga,
publishers do not have script as characters.
Regards,
Makoto
MURATA Makoto
> Why would "HTML-free EPUB" be better than existing formats (PDF, cbz/cbr,
> etc.)?
I don't know. I am just pointing out that fallback-free spine-level
image files combined with
a navigation document does not look better than spine-level image
files having the navigation
document as fallback.
Regards,
Makoto
Matt Garrish
Not if you only provide an SVG (or other image format) rendition. I believe
this was the use case for a container allowing one or more renditions of the
same content, so that an accessible xhtml version could be bundled.
It's not clear to me if that absolves the author from making any effort to
make the SVG version minimally accessible or not, since it seemed to be
implied in discussions that providing two renditions was a suitable way to
achieve the accessibility requirement, but the requirement on SVG content
that it adhere to the W3C accessibility note is not relaxed anywhere (i.e.,
an xhtml version might provide a better reading experience, but it would
seem to still be required that the SVG also provide minimal compliance,
which might just be the script and no panel descriptions, for example).
The advantage of SVG as an XML format is that it has intrinsic accessibility
features that can be employed, and would I assume be why it has core status
for content and other image formats don't. Promoting JPEG or GIF or PNG up
to core content status isn't as easy as readers rendering the images if the
core trait of accessibility is going to be maintained. By embedding these
image format in an xhtml document you at least can build in descriptions
through the methods that xhtml exposes (although
longdesc/describedAt/describedBy usage is a bit up in the air at this
point).
Matt
-----Original Message-----
From: epub-work...@googlegroups.com
[mailto:epub-work...@googlegroups.com] On Behalf Of MURATA Makoto
Sent: July-27-11 12:13
To: epub-work...@googlegroups.com
Subject: Re: Two examples of EPUB3 Manga
>
Bill McCoy
Leonard Rosenthol
>accessibility
>
but it's just that.
There are a variety of issues with SVG accessibility that the W3C are just
starting to look into (once they finish with Canvas accessibility issues).
Is it better than a raster image? Of course! But it's not a panacea.
Leonard
Leonard Rosenthol
Reply-To: "epub-work...@googlegroups.com" <epub-work...@googlegroups.com>
To: "epub-work...@googlegroups.com" <epub-work...@googlegroups.com>
Subject: Re: Two examples of EPUB3 Manga
Bill Kasdorf
In so many of these discussions (not just this one, technology discussions in general), people should remember, at least silently, to almost always add that little phrase "but it takes work." . . . ;-) Same issue with the semantics in EPUB 3, to point out an obvious, even glaring, example. I encounter lots of folks who say "oh, good, EPUB 3s will be accessible and conform to DAISY!!" As if every EPUB 3 will be ipso facto fully accessible. Not if you don't make them so, they won't be. . . . In fact, in talking with people who seem otherwise reasonably on top of EPUB 3, it's apparent that they don't even seem to be _aware_ of the EPUB 3 Structural Semantics Vocabulary (http://idpf.org/epub/vocab/structure/). It takes work!
--Bill Kasdorf
-----Original Message-----
From: epub-work...@googlegroups.com [mailto:epub-work...@googlegroups.com] On Behalf Of Leonard Rosenthol
Matt Garrish
I had to go back and look again[1], and you technically haven't broken any
specification rules by doing this, but you have (at least to me) broken the
whole spirit of content fallbacks.
Perhaps the wording of this section should be a little more explicit about
content equivalence of fallbacks? (Even if it would be one of those
"unverifiable by machine" restrictions like we have for progressive
enhancement, etc.)
[1]
<http://idpf.org/epub/30/spec/epub30-publications.html#sec-fallback-processi
ng-flow-manifest>
Matt
-----Original Message-----
From: epub-work...@googlegroups.com
[mailto:epub-work...@googlegroups.com] On Behalf Of MURATA Makoto
Sent: July-27-11 12:13
To: epub-work...@googlegroups.com
Subject: Re: Two examples of EPUB3 Manga
>
Hadrien Gardeur
I would encourage others to offer the own answers to Leonard's question ("why would 'HTML-free EPUB' be better than existing formats (PDF, cbz/cbr, etc.)?").
IMO there are at least three candidate reasons:1. EPUB offers an attractive balance of capabilities and simplicity. Vs. PDF, EPUB has packaging that's well-separated from content representation and standard ZIP and XML toolchains can be used. PDF is an extremely complex format in which packaging and content aren't well-modularized and practically speaking requires specialized tooling to author and manipulate. Vs. cbz/cbr, it has much stronger metadata, has reading order that's not determined by somewhat fragile things like alphabetical order, HTML content can be included as a fallback, etc. It can be seen that for bitmap-based digital magazines, even Adobe has not used PDF but created a ".issu" format, and Woodwing has created its own similar variant. One might inquire why Adobe created a ".issu" format instead of using (and if necessary extending) PDF.
2. EPUB can be augmented with HTML5-based interactivity and rich media, these other formats cannot.
3. EPUB is increasingly well supported by Reading Systems and browser-based Reading Systems are relatively straightforward, so if EPUB is chosen there is less new work to do and existing content distribution workflows can be potentially utilized. Including (dare I say it) DRM protection if that is desired. Of course PDF has much of this advantage too.
MURATA Makoto
> One of my two examples uses the navigation HTML document as fallbackI had to go back and look again[1], and you technically haven't broken any
specification rules by doing this, but you have (at least to me) broken the
whole spirit of content fallbacks.
Perhaps the wording of this section should be a little more explicit about
content equivalence of fallbacks? (Even if it would be one of those
"unverifiable by machine" restrictions like we have for progressive
enhancement, etc.)
[1]
<http://idpf.org/epub/30/spec/epub30-publications.html#sec-fallback-processi
ng-flow-manifest>
Matt
> In the examples, having a mechanism for describing the images that present
> ads, comics, etc. for persons with disabilities needs to be present. Just
a
> reminder, grin.
First, I have a very high respect to DAISY.
One of my two examples uses the navigation HTML document as fallback for
every JPEG file. But I do not think that that example is really accessible.
Can manga be accessible when the script is not available? For existing
manga,
publishers do not have script as characters.
Regards,
Makoto
Bill McCoy
...
3. EPUB is increasingly well supported by Reading Systems and browser-based Reading Systems are relatively straightforward, so if EPUB is chosen there is less new work to do and existing content distribution workflows can be potentially utilized. Including (dare I say it) DRM protection if that is desired. Of course PDF has much of this advantage too.
I'm not so sure about that point. If we really want to drive adoption we need to convince the existing comics viewers. They could add support for OPF & eventually SVG, but I doubt that they would turn their apps into fully compatible EPUB reading systems.Hadrien
Agree that it may be hard to convince existing comics viewers makers because their proprietary solutions give them a "lock" on distribution and of course they've already implemented support for their own / existing formats. I think EPUB could be more compelling as a path for publishers and more general eBook solution providers to create additional and broader distribution options that potentially come with less "tax". And ultimately consumers may prefer to be able to use a single solution for reading esp. in geographies like Japan where books, magazines, and comics can blur together to some degree. Some comics viewer makers may see this future and decide better to jump on the open bandwagon, which we should of course encourage, but I wouldn't make getting their support a sine qua non.
Hadrien Gardeur
In reality, manga publishers have image files only. They rarely havescripts as character strings. If we recommend them to use EPUB,we should allow fallback-free image files in the spine. I alsowould like to make navigation documents optional. I hope thatfuture light-weight EPUB manga reading systems will be very cheap(e.g., 30 USD) and have fairly large screen.
Hadrien Gardeur
Agree that it may be hard to convince existing comics viewers makers because their proprietary solutions give them a "lock" on distribution and of course they've already implemented support for their own / existing formats. I think EPUB could be more compelling as a path for publishers and more general eBook solution providers to create additional and broader distribution options that potentially come with less "tax". And ultimately consumers may prefer to be able to use a single solution for reading esp. in geographies like Japan where books, magazines, and comics can blur together to some degree. Some comics viewer makers may see this future and decide better to jump on the open bandwagon, which we should of course encourage, but I wouldn't make getting their support a sine qua non.
Matt Garrish
> No matter what you write, alibi fallback is always possible.
Of course, someone could try whatever we say, but it’s the validity of the solution that’s alarming to me.
You used it for JPEG, but someone could equally well put a PDF in the spine and fall back to a nav document and call it a valid EPUB, too. In effect, it’s a means of allowing anyone to decide they don’t want to use a core type and validly ignore the standard (leaving only the threat of irate customers whose reading systems spit junk data out at them as a deterrent).
Matt
MURATA Makoto
After all, specifications are not allmighty. All what we can do is to make accessible contents
very easy to create. No specs can prohibit non-accessible contents. If we try, we make things
worse by implicitly encouraging alibi accessibility. This is what is happening right now.
Regards,
Makoto
MURATA Makoto
Issue 155: Allowing image files in the spine WITHOUT fallback
http://code.google.com/p/epub-revision/issues/detail?id=155
Issue 156: Make navigation documents optional
http://code.google.com/p/epub-revision/issues/detail?id=156
Regards,
Makoto
matt.g...@bell.net
Absolutely, but my issue with this kind of fallback is more of a general, cross-cutting concern (i.e., not limited to accessibilty). The question it leaves me pondering is why we have a specification that defines core media types and requires that non-standard resources fall back to them if there is no expectation that the fallbacks be anything more than empty files or junk files (like the nav for content).
I agree that content equivalence between fallbacks isn't an enforceable concept, but at least if you state it as a requirement then it removes the ability for someone to use EPUB as a wrapper to any content they want. I thought the purpose of fallbacks was to ensure that content renders on all devices exactly so that readers can be assured that they won't have to deal with buying publications they subsequently can't read on their particular device. Maybe I'm being too starry eyed here, though.
When it comes to adding more image types as core, I don't have a huge issue with it so long as accessibility hooks remain. There is no restriction that a CMT can't still fall back to a another CMT (one solution); it just requires reading systems to be built to pass over the image versions if the reader requires an accessible version. I think a rootfile option is a more realistic solution in cases like this (as you say, novelization is the better approach), but we're lacking the semantics to allow a reading system to process multiple renditions and determine their purpose. Will reading systems now even present the second option to a reader or do they take the first publication in the first rootfile and ignore any other? It seems problematic to have accessibility possibly rest on a technique if it's not clearly defined how a reader can even get to the accessible version.
Matt
Date: Fri, 29 Jul 2011 12:56:49 +0900
Subject: Re: Two examples of EPUB3 Manga
MURATA Makoto
> specifications are not allmighty
Absolutely, but my issue with this kind of fallback is more of a general, cross-cutting concern (i.e., not limited to accessibilty). The question it leaves me pondering is why we have a specification that defines core media types and requires that non-standard resources fall back to them if there is no expectation that the fallbacks be anything more than empty files or junk files (like the nav for content).
Mandating fallback from JPEG to HTML makes JPEG-only EPUB
I agree that content equivalence between fallbacks isn't an enforceable concept, but at least if you state it as a requirement then it removes the ability for someone to use EPUB as a wrapper to any content they want. I thought
the purpose of fallbacks was to ensure that content renders on all devices exactly so that readers can be assured that they won't have to deal with buying publications they subsequently can't read on their particular device. Maybe I'm being too starry eyed here, though.
When it comes to adding more image types as core, I don't have a huge issue with it so long as accessibility hooks remain. There is no restriction that a
Brady Duga
But when mandating fallback causesother problems, I do not think that we should mandate fallback.
Mandating fallback from JPEG to HTML makes JPEG-only EPUBpublications impossible and thus prohibit JPEG-only EPUB RSs.
--
MURATA Makoto
>
>
> On Fri, Jul 29, 2011 at 6:53 AM, MURATA
> Makoto <eb2m...@asahi-net.or.jp> wrote:
>>
>> But when mandating fallback causes
>> other problems, I do not think that we should mandate fallback.
>> Mandating fallback from JPEG to HTML makes JPEG-only EPUB
>> publications impossible and thus prohibit JPEG-only EPUB RSs.
>
> This is an odd statement - JPEG-only EPUB RSs are already prohibited.
I raised this point in a teleconf. Bill McCoy responded that we
can later consider dropping some of the requirements
for Manga. I thus hope to drop many of the current
requirements for EPUB manga. I also firmly believe
that such implementations will appear anyway.
Regards,
Makoto
>That's
> the point of the core media types - they must *all* be supported. While it's
> certainly possible to use the OPF spec for something other then EPUB, while
> adding additional constraints and removing existing ones, the thing that
> results is *not* an EPUB, and whatever reads them is not an EPUB reading
> system. We may argue over whether such behavior should be encouraged,
> discouraged or if we should be neutral, but at the end of the day such a
> product is not constrained by our requirements and can do whatever it
> wants.
> --
>
> Brady Duga | Software Engineer | du...@google.com | (760) 462-5972
>
>
--
Hadrien Gardeur
I raised this point in a teleconf. Bill McCoy responded that we
can later consider dropping some of the requirements
for Manga. I thus hope to drop many of the current
requirements for EPUB manga. I also firmly believe
that such implementations will appear anyway.
Bill Kasdorf
[Renamed subject line from “Two examples of EPUB3 Manga”]
Important issue. I just want to point out that we need to be careful not to be too quick to fragment or twig the spec for special interests. Not that that won’t be welcome by those special interests; but because the needs of a special interest group that prompt a fragmentation or twigging in the first place are often shared by others.
My personal concern on this, of course, is that I see a lot of what the magazine folks are doing (thanks to the input from nextPub and IDEAlliance and their diligence in coordinating with us on this) as being important to many other folks that we always said were the core audience for EPUB 3. To state the obvious: the need for magazine publishers to incorporate slideshows and image galleries as remote resources is _absolutely_ shared by textbook, scientific, and scholarly publishers as well. Just one arcane example from one of my clients: in a book on new world archaeology, it would not be uncommon for the author to want to incorporate, for example, 5,000 images of arrowheads, or extensive site maps, as _part of the book_. (There are laser images that “see” through the jungle that can be gigabytes per image.) They want to do this _today_. Sure, one image or one map can be a fallback; but they need a way to provide the full collection as part of the book (it’s part of the research, it will get them tenure! and putting it in some institutional repository and linking to it is just not the same thing), and it will not be practical to put it in the container. And this is something that otherwise looks like a pretty plain vanilla book, an obvious candidate for EPUB. Okay, so these are extreme examples. But the image collections Dianne Kennedy is describing are not. They are totally common.
Twigging and diverging specs are to be pursued with great caution, imho. Better to try really hard to see if there is a way to accommodate their needs in the general spec (at least with the modular extensions that Bill M keeps reminding us is our intention).
That’s why I’m not ready to abandon the idea of coming up with _some_ way that we can at least get these kinds of image collections, specified in some workable way, into EPUB 3.0 alongside audio and video as valid remote resources. I think they will be widely used.
--Bill Kasdorf
From: epub-work...@googlegroups.com [mailto:epub-work...@googlegroups.com] On Behalf Of Hadrien Gardeur
Sent: Friday, July 29, 2011 11:27 AM
To: epub-work...@googlegroups.com
Subject: Re: Two examples of EPUB3 Manga
I raised this point in a teleconf. Bill McCoy responded that we
Bill McCoy
Hadrien Gardeur
I hope (*) that the normative EPUB specification stays broad and that any use cases that require tighter constraints can be crafted as a set of additional restrictions, that in some cases could be elevated into specific profiles. For example PDF has PDF/A and PDF/X which specialize PDF for document archival and graphics arts needs, respectively. But they are strict subsets, i.e. PDF/A and PDF/X documents are by definition also valid PDF documents. This maximizes interoperability and helps avoid fragmentation into dialects.Potentially such profiles could be supersets in the sense of declaring some optional capability required, such as a particular type of video codec - but this doesn't change the validity inheritance relationship.
Such profiles already exist informally with EPUB in that a number of content distributors / Reading System implementers have developed content submission guidelines. As a kind of trivial instance, an online store might for example say that they want EPUBs submitted to have a certain minimum level of resolution of bitmap images, for quality reasons, or a certain maximum level, for size/bandwidth reasons. Such ingestion requirements in effect define profiles of EPUB but the files are still valid.
Bill McCoy
Bill Kasdorf
For the record, since I sent that separate e-mail cautioning against “twigging” the spec, I want to say that I exactly agree with Bill M on this. A broad, master spec (which can evolve as modules are added) that can then be subsetted makes the most sense to me. If it ain’t that, it ain’t EPUB.
--Bill K
From: epub-work...@googlegroups.com [mailto:epub-work...@googlegroups.com] On Behalf Of Bill McCoy
Sent: Friday, July 29, 2011 2:32 PM
To: epub-work...@googlegroups.com
Subject: Re: Two examples of EPUB3 Manga
Hadrien,
MURATA Makoto
I understand your concern. In other committees designing other formats,
I have often argued against profiles (subsets). This is NOT because
features in such subsets are useful for users of the full set. But
rather because application programs can support only some of the
features without rejecting any document in the full set. For example,
iPhone supports OOXML and PDF. Such application programs
can be light-weight.
But the EPUB3 spec often imposes too much burden to
reading systems. I understand that people care fidelity
among different implementations. However, as a result,
EPUB3 does not allow light-weight implementations. Probably,
some people remember that I was against mandating
the support of several features in the 2nd F2F.
Here is one possible approach, although it is too late for 3.0. First,
remove all requirements on reading systems from the existing
specifications and relax some of the requirements on EPUB
publications (e.g., fallback chains mandated for JPEG).
Second, create a new document "Requirements for High-End
Reading Systems", which contains the removed requirements.
Third, create another document "Requirements for Light-Weight Reading
Systems for Manga", which contain lighter requirements on reading systems
and also shows which syntactical construct in EPUB is not supported.
Regards,
Makoto
2011/7/30 Bill Kasdorf <bkas...@apexcovantage.com>:
--
rka...@sympatico.ca
As I read these exchanges I am wondering how much we are drifting towards or away from this ideal. As far as I see EPUB3 or EP3 right or wrong I see it as ONE file created by a Content Producer relating to a variety of devices in a variety of ways rather than a variety of files relating to individual devices in individual ways. Am I wrong in this belief? Are we changing something fundamental here?
What I liked about Peter's solution is that it was a cross device solution. So much of what I'm reading here seems highly individuated. I don't mind (in fact like) the idea of multiple solutions in one file but is that what we are really talking about here? When I read about 'light" EPUB etc. I get nervous about what that means to a 'standard'.
BK
Sent via BlackBerry from T-Mobile
MURATA Makoto
Leonard Rosenthol
>
chose to implement only those parts of the respective standards that met
their own personal needs. They didn't ever pick a specific subset that
implement that - it is a very "pick one from column A, two from column B"
approach to standards implementation - and it's a daily thorn in user's
sides!
The whole point of a standard is interoperability - and that means folks
need to implement the ENTIRE standard, not just the parts they like.
Leonard
MURATA Makoto (FAMILY Given)
> >
> But it does NOT support everything required by the standard :(.
Yes, I see nothing wrong.
> Apple
> chose to implement only those parts of the respective standards that met
> their own personal needs. They didn't ever pick a specific subset that
> implement that - it is a very "pick one from column A, two from column B"
> approach to standards implementation - and it's a daily thorn in user's
> sides!
>
> The whole point of a standard is interoperability - and that means folks
> need to implement the ENTIRE standard, not just the parts they like.
My definition of interoperability is different from yours. To me, it is
important that a single EPUB publication displays reasonably well
in many environements. Fidelity is less important to me, since
it can only be achieved by limiting our concern to equally powerful
implemetations and eliminating other implementations.
Cheers,
Makoto
Leonard Rosenthol
Clearly...
>To me, it is
>important that a single EPUB publication displays reasonably well
>in many environements. Fidelity is less important to me,
If I was the author of a set of content, I would want to ensure that users
can see my content (in the way that I intend it) on any device that they
choose. If they can't see every other word, or only half the images - and
that changes the entire meaning of the content, that wouldn't be a good
thing!
>since
>it can only be achieved by limiting our concern to equally powerful
>implemetations and eliminating other implementations.
There are clearly other ways to address this problem, such as the use of
"subset profiles". I see nothing wrong with defining a "EPUB for Comics"
that is a valid subset of EPUB but would define the set of functionality
that a comic reader would need. Then authors could choose to target that
subset and readers/Uas could be developed that only targetted it.
Because without a FORMAL DEFINITION of something - neither authoring tools
nor readers/consumers would know what to do...
Leonard
MURATA Makoto
>>important that a single EPUB publication displays reasonably well
>>in many environements. Fidelity is less important to me,
>
> If I was the author of a set of content, I would want to ensure that users
> can see my content (in the way that I intend it) on any device that they
> choose. If they can't see every other word, or only half the images - and
> that changes the entire meaning of the content, that wouldn't be a good
> thing!
In Japan, quite a few authors of Manga refuse e-book since
it does not allow intended rendering. Things are gradually
changing, but publishers started to mandate one particular
reading system.
Meanwhile, as a user, I would like to read manga even when
the rendering is different from what the author intended.
>>since
>>it can only be achieved by limiting our concern to equally powerful
>>implemetations and eliminating other implementations.
>
> There are clearly other ways to address this problem, such as the use of
> "subset profiles". I see nothing wrong with defining a "EPUB for Comics"
> that is a valid subset of EPUB but would define the set of functionality
> that a comic reader would need. Then authors could choose to target that
> subset and readers/Uas could be developed that only targetted it.
At present, EPUB3 mandates certain behaviors while allowing
RSs not to implement some features (e.g., CSS can be safely ignored).
> Because without a FORMAL DEFINITION of something - neither authoring tools
> nor readers/consumers would know what to do...
I think that fidelity and base conformance should be separated.
By the way, this discussion is not at all specific to EPUB.
I have seen this discussion in many committees since 1986
(without significant progress). People might want to see
what ODF and OOXML do. ODF mandates the support
of some features. OOXML introduced interesting mechanisms
called "Application Descriptions".
Peter Sorotokin
But is it bad? I think having many reading systems that can open only a targeted subset of epubs would be a bigger problem.
Complexity: from the typography and publishing perspective - if measured by the regular criteria used for printed books - epub3 is still too simple, not too complex. We still cannot capture a lot of features that are used in print workflows all the time.
Peter
MURATA Makoto wrote:
So here is my problem with some of this discussion and maybe its due to my programmatic ignorance but in my 'idealistic" view of EPUB 3 I am assuming a 'standard' that will basically work on all devices - albeit not with all features. When we developed MPS Mobile we recognized that not all devices would support all features we had such as video, graphic linking etc. but could support core values within the basic file.
As I read these exchanges I am wondering how much we are drifting towards or away from this ideal. As far as I see EPUB3 or EP3 right or wrong I see it as ONE file created by a Content Producer relating to a variety of devices in a variety of ways rather than a variety of files relating to individual devices in individual ways. Am I wrong in this belief? Are we changing something fundamental here?
What I liked about Peter's solution is that it was a cross device solution. So much of what I'm reading here seems highly individuated. I don't mind (in fact like) the idea of multiple solutions in one file but is that what we are really talking about here? When I read about 'light" EPUB etc. I get nervous about what that means to a 'standard'.
BKSent via BlackBerry from T-Mobile
From: Bill McCoy <whm...@gmail.com>Sender: epub-work...@googlegroups.comDate: Fri, 29 Jul 2011 11:32:29 -0700
ReplyTo: epub-work...@googlegroups.com
Subject: Re: Two examples of EPUB3 Manga
Hadrien,
Right, my position is that the overall EPUB spec should change to allow use cases and/or the use cases should adjust to EPUB's requirements, enabling profiles to be strict subsets.
In the case of manga, I'm not yet personally convinced that requiring a navigation document, fallbacks, and even SVG stubs in the spine would be fatally burdensome. Sure it's a bit more complex than CBR/CBX but it's still way less complex than PDF and there are benefits to all three constructs.
--Bill
On Fri, Jul 29, 2011 at 11:25 AM, Hadrien Gardeur <hadrien...@feedbooks.com> wrote:
I hope (*) that the normative EPUB specification stays broad and that any use cases that require tighter constraints can be crafted as a set of additional restrictions, that in some cases could be elevated into specific profiles. For example PDF has PDF/A and PDF/X which specialize PDF for document archival and graphics arts needs, respectively. But they are strict subsets, i.e. PDF/A and PDF/X documents are by definition also valid PDF documents. This maximizes interoperability and helps avoid fragmentation into dialects.
Potentially such profiles could be supersets in the sense of declaring some optional capability required, such as a particular type of video codec - but this doesn't change the validity inheritance relationship.
It's a very reasonable way to deal with these issues, but it won't solve the problem with manga. With the current spec, an EPUB 3.0 with bitmap files, no fallback and no navigation document wouldn't be valid.
Such profiles already exist informally with EPUB in that a number of content distributors / Reading System implementers have developed content submission guidelines. As a kind of trivial instance, an online store might for example say that they want EPUBs submitted to have a certain minimum level of resolution of bitmap images, for quality reasons, or a certain maximum level, for size/bandwidth reasons. Such ingestion requirements in effect define profiles of EPUB but the files are still valid.
I would separate such profiles into two categories:- the ones you describe are "private profiles", where the client doesn't need to be aware of these requirements and can consume the file directly- manga/comics as previously described in this thread would be a "public profile" where a client might explicitly decide to support strictly this profile and not its superset
Such public profile need to advertise their profile, ideally through their media type.Hadrien
--
Peter Sorotokin
I have big problem with this definition of interoperability. Lack of fidelity is what prevents EPUB from addressing higher-end publishing. Unless we want to only cover trade books, we need fidelity. Image-based manga viewers should not be called EPUB reading systems.
Peter
"MURATA Makoto (FAMILY Given)" wrote:
> >
> But it does NOT support everything required by the standard :(.
Yes, I see nothing wrong.
> Apple
> chose to implement only those parts of the respective standards that met
> their own personal needs. They didn't ever pick a specific subset that
> implement that - it is a very "pick one from column A, two from column B"
> approach to standards implementation - and it's a daily thorn in user's
> sides!
>
> The whole point of a standard is interoperability - and that means folks
> need to implement the ENTIRE standard, not just the parts they like.
important that a single EPUB publication displays reasonably well
implemetations and eliminating other implementations.
Makoto
Hadrien Gardeur
But is it bad? I think having many reading systems that can open only a targeted subset of epubs would be a bigger problem.
Complexity: from the typography and publishing perspective - if measured by the regular criteria used for printed books - epub3 is still too simple, not too complex. We still cannot capture a lot of features that are used in print workflows all the time.
Peter Sorotokin
However, when we get to rendering, EPUB Reading System needs to provide at least some level of fidelity. Something that can open only manga EPUBs structured in some limited ways should not be advertized as an EPUB Reading System. Reuse the technology – sure – but don’t dilute the value of the EPUB “brand”.
Peter
rka...@sympatico.ca
BK
Sent via BlackBerry from T-Mobile
MURATA Makoto (FAMILY Given)
>addressing higher-end publishing. Unless we want to only cover trade
>books, we need fidelity. Image-based manga viewers should not be called
>EPUB reading systems.
First, when fidelity is important, why use EPUB? Use PDF.
Second, why should the manga publishers and users have to suffer?
Cheers,
Makoto
MURATA Makoto (FAMILY Given)
I think that it is a great advantage. Now, iphone users can open OOXML
documents. Nobody complains.
> Complexity: from the typography and publishing perspective - if measured by the
>regular criteria used for printed books - epub3 is still too simple,
>not too complex. We still cannot capture a lot of features that are used in
>print workflows all the time.
The combination of Javascript, DOM, HTML5, and CSS3 is already
prohibitively difficult. Who implements the full set of EPUB3?
I think that you are just talking about typographical features of
existing Adobe products.
Cheers,
Makoto
Bill McCoy
Peter Sorotokin
Now, that something else could either be developed to be interoperable or
everyone could roll their own. We are trying to do something interoperable.
Manga publishers and users do not need to suffer at all. Manga reading
system developers may need to suffer, though, if and only if they want to
claim to be EPUB-compliant.
This is the same on the web, BTW. Creating and consuming HTML is easy.
Writing a browser is very hard. You would not call manga viewer a web
browser, even if it used HTML-based format, right?
I could turn the table and ask - why InDesign users have to suffer? They
want to design for all devices and platforms - why should they be forced to
worry about reading system differences any more than necessary.
Peter
On 7/31/11 2:56 PM, "MURATA Makoto (FAMILY Given)"
MURATA Makoto
> PDF is not reflowable and marginally interactive, so we need something else.
Hmm. I do not think that reflowable formats for a variety
of reading systems can provide fidelity.
> Now, that something else could either be developed to be interoperable or
> everyone could roll their own. We are trying to do something interoperable.
Since we have different definitions of "interoperability", let us avoid
this word.
> Manga publishers and users do not need to suffer at all. Manga reading
> system developers may need to suffer, though, if and only if they want to
> claim to be EPUB-compliant.
Calling such implementations non-conformant hampers the adoption
of EPUB and encourages vendor-specific extensions to EPUB.
> This is the same on the web, BTW. Creating and consuming HTML is easy.
> Writing a browser is very hard. You would not call manga viewer a web
> browser, even if it used HTML-based format, right?
Yes, I do. There are many browsers on mobile devices that support
very small subsets of the web technology. In my understanding,
HTML has never called such browsers non-conformant.
>
> I could turn the table and ask - why InDesign users have to suffer? They
> want to design for all devices and platforms - why should they be forced to
> worry about reading system differences any more than necessary.
Certainly, they shouldn't suffer. How can we make
different groups happy? I think that the answer is
to get rid of requirements on RSs from the base spec
and to create different requirement documents for
different groups of users.
Regards,
Makoto
> Peter
>
> On 7/31/11 2:56 PM, "MURATA Makoto (FAMILY Given)"
> <eb2m...@asahi-net.or.jp> wrote:
>
>>> I have big problem with this definition of interoperability. Lack of fidelity
>>> is what prevents EPUB from
>>> addressing higher-end publishing. Unless we want to only cover trade
>>> books, we need fidelity. Image-based manga viewers should not be called
>>> EPUB reading systems.
>>
>> First, when fidelity is important, why use EPUB? Use PDF.
>>
>> Second, why should the manga publishers and users have to suffer?
>>
>> Cheers,
>> Makoto
>
>
--
Peter Sorotokin
<eb2m...@asahi-net.or.jp> wrote:
>> But is it bad? I think having many reading systems that can open only a
>> targeted subset of epubs would be a bigger problem.
>
> I think that it is a great advantage. Now, iphone users can open OOXML
> documents. Nobody complains.
>
We are talking about very different uses here. First of all, it is not
publishing: if people were sold these OOXML files advertized as specifically
viewable for iPhone, there would have been a ton of complaints. And iPhone
OOXML viewer attempts to implement features that are in a wide use, not
features that are used in a particular segment of the market. You could
create manga using OOXML format as a starting point, but it would not be
correct to claim to be an OOXML viewer if all you could view was that
manga-oriented OOXML subset.
People complain bitterly about missing features in our EPUB SDK. I do not
see how they would not complain about even a more stripped down system.
>> Complexity: from the typography and publishing perspective - if measured by
>> the
>> regular criteria used for printed books - epub3 is still too simple,
>> not too complex. We still cannot capture a lot of features that are used in
>> print workflows all the time.
>
> The combination of Javascript, DOM, HTML5, and CSS3 is already
> prohibitively difficult.
Yes. Sadly that's the price for being aligned with web standards, not
necessarily for having good set of features that are needed for publishing.
> Who implements the full set of EPUB3?
Well evaluate it in couple years. It is too early to tell right now. That's
where the alignment with web standards helps - to some extent.
> I think that you are just talking about typographical features of
> existing Adobe products.
I am talking about typographic features that were in wide use in publishing
even before Adobe existed.
Peter
>
> Cheers,
> Makoto
Peter Sorotokin
> 2011/8/1 Peter Sorotokin <psor...@adobe.com>:
>> PDF is not reflowable and marginally interactive, so we need something else.
>
> Hmm. I do not think that reflowable formats for a variety
> of reading systems can provide fidelity.
>
Fidelity is not a Boolean value. To be reflowable you have to give up some
fidelity, but not nearly all.
>> Now, that something else could either be developed to be interoperable or
>> everyone could roll their own. We are trying to do something interoperable.
>
> Since we have different definitions of "interoperability", let us avoid
> this word.
>
That would be very hard, because this is the primary reason for the
standard. Authoring tools need to create something that would work in the
viewer. Users need to be able to have some idea if the content is going to
work or not before paying money.
>> Manga publishers and users do not need to suffer at all. Manga reading
>> system developers may need to suffer, though, if and only if they want to
>> claim to be EPUB-compliant.
>
> Calling such implementations non-conformant hampers the adoption
> of EPUB and encourages vendor-specific extensions to EPUB.
I disagree. If your player cannot play all DVDs *by design*, don't call it a
DVD player. That only helps the standard. I want to proliferate
implementations only as long as they work.
>
>> This is the same on the web, BTW. Creating and consuming HTML is easy.
>> Writing a browser is very hard. You would not call manga viewer a web
>> browser, even if it used HTML-based format, right?
>
> Yes, I do. There are many browsers on mobile devices that support
> very small subsets of the web technology. In my understanding,
> HTML has never called such browsers non-conformant.
You could always render HTML in many different ways, so technically speaking
you are right about mobile devices (although iPhone & Android proved that
there limitations were in many cases just limitations of the implementers,
not devices; most of these browsers are dead now). But again, this is not
what I am talking about. HTML-based manga viewer would not read all HTMLs,
however poorly, it would only render whatever subset was used for manga.
Such thing could not be called HTML user agent.
>>
>> I could turn the table and ask - why InDesign users have to suffer? They
>> want to design for all devices and platforms - why should they be forced to
>> worry about reading system differences any more than necessary.
>
> Certainly, they shouldn't suffer. How can we make
> different groups happy? I think that the answer is
> to get rid of requirements on RSs from the base spec
> and to create different requirement documents for
> different groups of users.
See, you are saying "different groups of users", but users (and publishers)
would be served just fine by a full-featured EPUB renderer. And I do not see
any need to split the spec to serve different requirements and limitations
of reading systems implementers.
Peter
Cramer, Dave
books to cookbooks. They are all distributed to the same wholesalers and
retailers (I believe our contracts require us to offer the same books to
every account). I can only imagine the confusion if each genre required a
different format, and if the retailer had to filter based on the device
used by the purchaser.
For any given book, we won't use every feature of EPUB 3. But across our
catalog we might use most of them. It will depend on that particular book,
and you never know what might happen. A recent bestselling murder mystery
included the Riemann zeta function. I would have loved to use MathML for
that, but I can't--yet. So even a reading system for novels may need to
support MathML, SVG, or who knows what?
I hope for a world where we can create content based on a single spec, and
know that it will be rendered faithfully no matter where it is read (I'm
talking about you, Amazon!). I understand we don't live in such a world,
and may never get there, but every small step will make a difference for
publishers and readers.
--Dave Cramer
MURATA Makoto
I cannot help asking a frank question. No offence is intended,
but I just want to talk about reality. In my understanding,
Adobe does not plan to support EPUB3 in the near future
but does plan to implement extensions for adaptive layout
even if they are not endorsed by IDPF. I will call such an
implementation an EPUB reading system, as long as
it does not reject correct EPUB3 publications. Will you?
Regards,
Makoto
2011/8/1 Peter Sorotokin <psor...@adobe.com>:
--
Leonard Rosenthol
MURATA Makoto
I also think that we should avoid different formats for different
genres. But I do think that we shouldn't force every implementation
to support all genres.
Now, implementors of CBZ or CBR manga show little interest
in EPUB. I am afraid that your hope ("rendered faithfully no matter
where it is read") rather hampers format unification but increases
variations of EPUB such as the B&N magazine form.
Regards,
Makoto
2011/8/1 Cramer, Dave <Dave....@hbgusa.com>:
--
Peter Sorotokin
> Peter,
>
> I cannot help asking a frank question. No offence is intended,
> but I just want to talk about reality. In my understanding,
> Adobe does not plan to support EPUB3 in the near future
> but does plan to implement extensions for adaptive layout
> even if they are not endorsed by IDPF. I will call such an
> implementation an EPUB reading system, as long as
> it does not reject correct EPUB3 publications. Will you?
Certainly the priorities on viewing side are determined not solely by a
desire to adhere to standard, but by business needs as well. However, we are
not going to claim EPUB3 compliance until we implement all *required* EPUB3
features. So the answer is, no, it is not a compliant EPUB3 Reading System
until it adheres to the standard.
Peter
>
> Regards,
> Makoto
>
Hadrien Gardeur
However, when we get to rendering, EPUB Reading System needs to provide at least some level of fidelity. Something that can open only manga EPUBs structured in some limited ways should not be advertized as an EPUB Reading System. Reuse the technology – sure – but don’t dilute the value of the EPUB “brand”.
Hadrien Gardeur
We publish many kinds of books, from manga to novels to children's picture
books to cookbooks. They are all distributed to the same wholesalers and
retailers (I believe our contracts require us to offer the same books to
every account). I can only imagine the confusion if each genre required a
different format, and if the retailer had to filter based on the device
used by the purchaser.
Levantovsky, Vladimir
A standard is not the law, there is no punishment for not following it. Any RS vendor can implement a hand-picked set of features and release a device on the market. If you don’t claim a compliance to any particular standard, and the product serves its purpose and satisfies its users, and it sells – it’s all fine.
However, if a device implements limited functionality *and* claims to be standard-compliant – this is the case I’d have problems with. There is clearly a market benefit of selling a device that claims compliance to a widely recognized standard, and the price for it is to implement the features required by that standard. In some cases, profiles are required because they address real physical limitations (e.g. bandwidth limits for video/audio, encoding latency in video conferencing, etc.) but the profiling in general is harmful since it creates market fragmentation, and should IMHO be avoided whenever possible.
So , when it comes to devices that can only support limited capability Manga EPUBs – I agree with Peter. Call it “Manga viewer” or “comics viewer” – I don’t care, but don’t call it “EPUB Reading System”. I don’t see how creating a limited capability EPUB profile would help either authors or end-users – these are the constituencies we need to care the most.
Thank you,
Vladimir
From: epub-work...@googlegroups.com [mailto:epub-work...@googlegroups.com] On Behalf Of Hadrien Gardeur
Sent: Monday, August 01, 2011 5:24 AM
To: epub-work...@googlegroups.com
Subject: Re: Two examples of EPUB3 Manga
However, when we get to rendering, EPUB Reading System needs to provide at least some level of fidelity. Something that can open only manga EPUBs structured in some limited ways should not be advertized as an EPUB Reading System. Reuse the technology – sure – but don’t dilute the value of the EPUB “brand”.
MURATA Makoto (FAMILY Given)
You are consistent. In your scenario, the EPUB3 conformant reading
system is a holy grail, which is very often unavailable. You certainly recognize
advantages of other beasts. Do you have any problems with a proposal to
create IDPF-authorized beasts such as light-weight EPUB manga viewers?
Named and controlled beasts are better than uncontrolled beasts.
Regards,
Makoto
Cheers,
Makoto
rka...@sympatico.ca
I continue to find this an engaging and interesting discussion on both sides in making us think through what we are trying to accomplish here. I will therefore ask you a very simple question as I did to Peter recently. Were the IDPF to authorize your Manga EPUB readers what would you see as the minimum of features that would make it EPUB compliant?
BK
Sent via BlackBerry from T-Mobile
From: "MURATA Makoto (FAMILY Given)" <eb2m...@asahi-net.or.jp>
Sender: epub-work...@googlegroups.com
Date: Tue, 02 Aug 2011 20:00:27
To: <epub-work...@googlegroups.com>
Reply-To: epub-work...@googlegroups.com
Subject: Re: Twigging the spec
MURATA Makoto
say nothing about application conformance. (No matter what
the spec says, which organization conducts conformance
testing of application programs?) If application conformance
is defined, it should allow every useful application program
and should mandate nothing.
I also think that conformance falls short of providing fidelity.
For example, since any line-breaking algorithm is allowed,
the number of pages is implementation dependent.
For a group of light-weight manga viewers to exhibit some
fidelity, interoperability guidelines (not conformance requirements!)
would be useful. Such guidelines might include information about
hardware (screen size, resolution, buttons, etc.), user interface
(two-page spread, etc.) and recommended features of EPUB3
(JPEG-in-spine, etc.).
Regards,
Makoto
2011/8/2 <rka...@sympatico.ca>:
--
Leonard Rosenthol
"subsets" of the EPUB standard for specific use cases would be a
worthwhile investment.
Leonard
On 8/2/11 4:00 AM, "MURATA Makoto (FAMILY Given)"
Cramer, Dave
What would possible subsets look like? Would there at least be a core of things that should always work? (CSS 2.1, some subset of HTML5, jpeg, png, gif)? Sometimes it feels like we're moving from a world with .mobi, .lit, OEB, ePDF, and .prc to a world with EPUB-manga, EPUB-fixed, EPUB-daisy, EPUB-simple, EPUB-javascript, etc. Is this progress? Yes. But it feels like we're a long way from a universal format.
Dave Cramer
Garth Conboy
On Aug 2, 2011, at 8:43 AM, Cramer, Dave wrote:
> Have we reached a point where it's so difficult to create a fully-compliant reading system that no one is even going to try? Many content creators will assume that any EPUB reading system supports the full spec.
The spec is likely a couple of months from even being voted on and approved by membership.
So, right now, I don't believe there are any Reading Systems that fully conform to the Proposed Specification -- but, that's quite reasonable at this stage.
I do not view this as an indication that there *won't* be such Reading Systems developed, and I don't view development of such Reading Systems as an insurmountable task.
Best,
Garth
Peter Sorotokin
On 8/2/11 4:00 AM, "MURATA Makoto (FAMILY Given)" <eb2m...@asahi-net.or.jp>
wrote:
> Peter,
>
> You are consistent. In your scenario, the EPUB3 conformant reading
> system is a holy grail, which is very often unavailable.
Yes. And I even agree that it won't likely be available if something is not
relaxed. I we will have to revisit it in a year or so and look at where we
are falling sort and likely to fall short for some time (e.g. obsure
portions of SVG).
> You certainly recognize
> advantages of other beasts. Do you have any problems with a proposal to
> create IDPF-authorized beasts such as light-weight EPUB manga viewers?
Not at all. I just don't think that they should be called EPUB viewers if
they cannot open arbitrary EPUBs.
> Named and controlled beasts are better than uncontrolled beasts.
Certainly.
Peter
Kevin Ballard
-Kevin
On Aug 2, 2011, at 8:43 AM, Cramer, Dave wrote:
Peter Sorotokin
I think what you talking about is metadata about publication type. I agree
would be very useful - but it is orthogonal to the subset adherence. Even if
we define a subset for manga (say, EPUB/M), some publishers may want to
create some sort of advanced manga which uses features of the full spec.
They would want them to look like manga, but they would not want to mark it
as EPUB/M-compliant.
Peter
MURATA Makoto
Takase-san of EAST Co.,Ltd. created a manga example using SVG.
Each page in the given Manga is represented by an SVG document containing
an JPEG file,. Each cell is represented by a rect element in the SVG
document.
A Javascript program allows each rect to be focused in turn.
http://epub-revision.googlecode.com/files/harukoSVG.epub
I am not aware of any EPUB viewer that can render this EPUB
publication as intended. Please download the EPUB package,
unzip it, and use modern browsers to view the SVG file OPS/images/01.svg.
Takase-san will attend the Taipei workshop and give
a talk.
Regards,
Makoto
2011/7/23 MURATA Makoto (FAMILY Given) <eb2m...@asahi-net.or.jp>:
>> What about using directly SVG images instead of embedding these images in an
>> HTML file ?
>
> Yes, that is a possibility. I still do not know which of the three
> possibilities: HTML Manga, SVG Manga, or JPEG Manga is better. I am
> aware of some advanced use of HTML5 for Manga.
>
> We should try SVG manga and study pros and cons. If I have time,
> I will create another example.
Brady Duga
Leonard Rosenthol
Editions, Bluefire Reader and many others) will view the document just
fine including the SVG & image BUT will not play the scripts (because it's
still an EPUB2 reader which doesn't know from scripting).
Apple iBooks, which is the only other EPUB reader that I know that handles
SVG, seems to crash on trying to render the TOC page. I have also
experienced the fact that iBooks prefers to have SVG "inlined" in XHTML
rather than as separate .svg files. You might want to try that and see if
it helps.
As for the scripting, someone with more experience should look at it, but
I would not expect that type of scripting to be allowed in EPUB (or at
least not in all EPUB viewers).
Leonard
Leonard Rosenthol
vectors and rasters) and renders just fine in Adobe RMSDK-based viewers as
well as iBooks.
Leonard
On 9/13/11 11:05 AM, "MURATA Makoto" <eb2m...@asahi-net.or.jp> wrote:
Roger Webster
I concur with Brady: nice example, but (primary interaction/navigation) UI-in-content is not something we’d support.
--Roger Webster
From: epub-work...@googlegroups.com [mailto:epub-work...@googlegroups.com] On Behalf Of Brady Duga
Sent: Tuesday, September 13, 2011 8:16 am
To: epub-work...@googlegroups.com
Subject: Re: Two examples of EPUB3 Manga
It's a very nice example, and I think shows some of the interactions you would want for this type of content. However, I am not a fan of having UI defined in content. I think it would be much better to have marked regions of the document that can be zoomed to using a consistent reader UI. This could be useful for Manga, high-design cookbooks, children's books, etc.
This electronic mail message contains information that (a) is or
may be CONFIDENTIAL, PROPRIETARY IN NATURE, OR OTHERWISE
PROTECTED
BY LAW FROM DISCLOSURE, and (b) is intended only for the use of
the addressee(s) named herein. If you are not an intended
recipient, please contact the sender immediately and take the
steps necessary to delete the message completely from your
computer system.
Not Intended as a Substitute for a Writing: Notwithstanding the
Uniform Electronic Transaction Act or any other law of similar
effect, absent an express statement to the contrary, this e-mail
message, its contents, and any attachments hereto are not
intended
to represent an offer or acceptance to enter into a contract and
are not otherwise intended to bind this sender,
barnesandnoble.com
llc, barnesandnoble.com inc. or any other person or entity.
Bill McCoy
bmc...@idpf.org
Peter Sorotokin
Bill McCoy
Hadrien Gardeur
Bill McCoy
Perhaps it would be good to agree on "what" information needs to be represented to meet publisher and reading system requirements, then the best "how" can be determined. Earlier in this thread it was discussed whether it should be declarative or programmatic and it seems folks agreed declarative was better. PDF article threads are a pretty simple data structure: an ordered list of (page, box) elements. Given this, and assuming fixed format pages (however represented, I agree with you that that's orthogonal) a specific device reading system can then determine for itself how to pan & zoom to give a good experience. But for manga I believe more information may be wanted depending on the content. For example preferred transitions, and given the precedents of keitai manga for things like vibrating effects triggered on particular cells.
Hadrien Gardeur
Perhaps it would be good to agree on "what" information needs to be represented to meet publisher and reading system requirements, then the best "how" can be determined.
Earlier in this thread it was discussed whether it should be declarative or programmatic and it seems folks agreed declarative was better. PDF article threads are a pretty simple data structure: an ordered list of (page, box) elements. Given this, and assuming fixed format pages (however represented, I agree with you that that's orthogonal) a specific device reading system can then determine for itself how to pan & zoom to give a good experience. But for manga I believe more information may be wanted depending on the content. For example preferred transitions, and given the precedents of keitai manga for things like vibrating effects triggered on particular cells.
Cramer, Dave
[1] It's orders of magnitude less work than the HTML+CSS, at least if
you're doing it by hand (ask me how I know!). Saving an InDesign page as
EPS and then SVG is pretty simple.
[2] It might avoid problems with including fonts.
[3] It avoids the stigma of relying on absolute positioning, which this WG
has officially "discouraged" :)
Dave Cramer
On 9/19/11 4:03 PM, "Hadrien Gardeur" <hadrien...@feedbooks.com>
wrote: