The fifth and last batch of comments from Japanese reviwers
MURATA Makoto
subversion repository rather than the public working draft. We did
not review scripting since it is being discussed.
1.5
State that other prefixes may be used.
2.1.3.2.1 Overview
This subclause should be made non-normative.
2.1.3.2.2
Can @ssml:ph control the alt attribute of the img element?
2.1.3.3 The epub:trigger Element
The XML events spec does not define the set of permissible event
types, but does mention DOM2EVENTS.
This specification does not normatively specify how
language designers should name events (i.e., the values
used in the event attribute).
...
A number of event types are defined in DOM2 [DOM2EVENTS], to
which you should refer for their names and semantics.
DOM2 defines some permissible event types. We believe that the EPUB3
Content Documents spec should explcitly specify which event type is
allowed.
Some event types (e.g., DOMActivate, DOMNodeRemoved) defined in DOM2
might be too much for EPUB. We might also want to define our own
event types (e.g., nextPage, previousPage, currentPage).
What does "visibility property" mean? Reference DOM as the definition.
2.1.4.1.4 Reading System Conformance
The precedence of altimg is unclear. When it is used?
2.1.4.1.3 Reading System Conformance
Do not make the support of MathML (even Presentational) mandatory, since
EPUB3 viewers dedicated to Manga will not support it.
> It must regard the mathml [Publications30] property of the Package
> Document manifest item element as the authoritative definition of
> whether an XHTML Content Document includes embedded MathML.
What happens when a package file contains an item element does not
announce "MathML", but the XHTML content referenced by the item
element does have it? We propose to syntactically disallow such EPUB
publications.
2.1.4.2 SVG
Remove the 2nd note since it adds nothing to the last para ("Reading
Systems must ...").
Why should the @src attribute of the iframe element reference
XHTML? Any problems in referencing SVG or PNG?
2.2.4.1
Replace "the href IRI attribute " by "the href attribute " and replace
"IRI" in the bullet before last by "relative IRI reference".
We propose to use UL rather than OL. If numbers are not usually
generated, the use of OL looks strange. Moreover, when the nav
document is viewed by the browser, it will generate numbers when OL is
used.
2.2.4.2
The EPUB 3 Structural Semantics Vocabulary has many values, and most
of them are probably inappropriate for the nav element. Make clear
which of the values can be used for the nav elements.
3.3.1
Why do we need "Reading Systems that have a CSS Viewport must support
the font-family property."
3.3.2
Drop "Additional details on these list styles can be found in
[CSS3Lists]." unless an updated WD is published before the
publication of EPUB3. We know that this is suboptimcal, but
we can do nothing else.
3.3.4
There are some "characters" that can be rendered appropriately by SVG
fonts but by nothing else. For such characters, it is not possible
for authors to "reference a generic font using the font-family property."
Also, "Such fallback must be a Core Media Type embedded font or generic
font reference." in 5.2.3.2 CSS Style Sheets of EPUB3 Publications should
be reworded as advice rather than a requirement.
3.3.9
Replace "will become" in the last note by "may become"
3.3.10
Duplicate oeb-page-foot and oeb-page-head, since it has not been
widely implemented and nobody would like to promote them.
4.2
""MIME string" should be "media type".
Is it OK to create a PLS document that is never associated with
XHTML contents?
4.2
What does "PLS Documents must be represented and located as defined in
EPUB Publication -- Content Conformance [Publications30] ."
Declaration in the manifest?
B.4.1.3 Features
In the para after the table, replace "1.0" by "3.0", since 1 is
neither the verion of EPUB nor that of DOM/CSS.
We are puzzled by the current choice of required epubReadingSystem features.
We would like to suggest more features:
T2S
PLS
Media-Overlay
Mathml
vertical-lr
vertical-rl
horizontal-tb
direction-ltr
direction-rtl
page-progression-direction-rtl
page-progression-direciton-ltr
two-page-spread
video-aware
audio-aware
MPEG4
color
--
Praying for the victims of the Japan Tohoku earthquake
Makoto
Daniel Weck
On 13 Apr 2011, at 05:57, MURATA Makoto wrote:
> 2.1.3.2.2
> Can @ssml:ph control the alt attribute of the img element?
"control" is not the appropriate term ;) ..but yes, I agree.
I also added the "title" attribute on links ("a" elements).
Issue tracker link:
http://code.google.com/p/epub-revision/issues/detail?id=127
Regards, Daniel
Daniel Weck
On 13 Apr 2011, at 05:57, MURATA Makoto wrote:
> generated, the use of OL looks strange. Moreover, when the nav
> document is viewed by the browser, it will generate numbers when OL is
> used.
As you know, the EPUB3 Working Group reached a consensus [1] about
using a default user-agent CSS stylesheet with "list-style: none" for
"ol" lists, as described [2] in the latest draft specification.
If you strongly disagree with the rationale behind this choice (best-
articulated by Fantasai here [3]), please reply to the original email
discussion thread, so we can track your objection more formally than
via this separate batch of comments.
Many thanks !
Regards, Daniel
[1]
http://groups.google.com/group/epub-working-group/msg/9df50cc8b9077645
[3]
http://groups.google.com/group/epub-working-group/msg/028d911ec9865621
Daniel Weck
On 13 Apr 2011, at 05:57, MURATA Makoto wrote:
> of them are probably inappropriate for the nav element. Make clear
> which of the values can be used for the nav elements.
The concept of "HTML usage context" is defined as such in "EPUB 3
Structural Semantics Vocabulary" [1]:
"
The HTML usage context fields indicate contexts in HTML5 documents
where the given property is considered relevant. When processing HTML5
documents, Reading Systems may ignore properties that occur outside
the specified document context.
"
Now, I'm not convinced that the special status of "EPUB Navigation
Documents" [2] (in terms of their particular role within an EPUB3
publication) justifies specifying restrictions regarding the
applicability of "epub:type" attribute values (other than what is
already defined in [1]). As an implementor, I feel that the current
normative prose about the special meaning (and in some cases required
processing) of "toc", "page-list", etc. is sufficient.
Perhaps it is a cross-cutting concern that should be debated and
addressed at a higher level, for example by defining and using a
semantic profile as described in "Vocabulary Association" [3]. e.g.
profile="http://www.idpf.org/epub/30/profile/nav/" ?
Note that issue #73 [4] is related.
Regards, Daniel
[1]
http://epub-revision.googlecode.com/svn/trunk/build/vocab/structure/epub30-vocab-structure.html
[2]
http://epub-revision.googlecode.com/svn/trunk/build/spec/epub30-contentdocs.html#sec-xhtml-nav
[4]
http://code.google.com/p/epub-revision/issues/detail?id=73
Levantovsky, Vladimir
>
> 3.3.4
>
> There are some "characters" that can be rendered appropriately by SVG
> fonts but by nothing else. For such characters, it is not possible
> for authors to "reference a generic font using the font-family
> property."
>
The reverse is also true - there are some languages and writing systems where the text can only be rendered appropriately only with generic (OpenType) fonts, but *not* when using SVG fonts. I am not sure if the EPUB spec should go into this level of details to spell out all possible cases where things might go wrong.
Regards,
Vladimir
Daniel Weck
On 13 Apr 2011, at 05:57, MURATA Makoto wrote:
> [CSS3Lists]." unless an updated WD is published before the
> publication of EPUB3. We know that this is suboptimcal, but
> we can do nothing else.
On a related note, the CSS folks just posted this working group
resolution:
"
EPUB should use prefixed versions of properties that aren't yet in CR.
No recommendations on what the prefixed property means.
"
[1]
http://lists.w3.org/Archives/Public/www-style/2011Apr/0429.html
Peter Sorotokin
for SVG text, nothing else. As far as I know, we do not have a requirement
that SVG fonts are supported for XHTML text (I remember agreeing to WOFF
after a heated debate, I do not remember a debate about SVG fonts in XHTML
context). Perhaps that needs to be discussed and made more explicit.
I am also not aware of any characters that can be rendered by SVG font, and
not by an OpenType font (at least if OpenType is processed as it is supposed
to - with glyph composition rules). The only area where SVG font offers
something which I think is missing from OpenType is colored glyphs. I
suspect SVG font with glyph composition is being compared with OpenType
without glyph composition. Could this be clarified?
Adobe position is that SVG font is a marginal technology and while we can
see it is being used as an extension by some vendors, it is not something
that we can endorse on IDPF level (beyond fulfilling requirements of SVG 1.1
specification). We are not planning to support of SVG fonts in either
authoring or rendering side (beyond SVG 1.1 text) because SVG glyph
composition rules are not compatible with OpenType glyph composition (and as
far as I can tell with CSS font selection logic when a list of font families
are given).
Peter
On 4/13/11 12:08 PM, "Levantovsky, Vladimir"
Daniel Weck
On 13 Apr 2011, at 05:57, MURATA Makoto wrote:
> Is it OK to create a PLS document that is never associated with
> XHTML contents?
If this is a strong concern, then a similar issue should be raised for
CSS files. Is this really necessary ?
> 4.2
>
> What does "PLS Documents must be represented and located as defined in
> EPUB Publication -- Content Conformance [Publications30] ."
> Declaration in the manifest?
Ah, it looks like an entry is missing in the list for "2.1 Content
Conformance" [1] (mimicking the CSS entry):
----
EPUB PLS Documents
› It may contain zero or more EPUB PLS Document conformant to the
content requirements defined in EPUB PLS Document — Content
Conformance [ContentDocs30].
----
Daniel Weck
On 13 Apr 2011, at 05:57, MURATA Makoto wrote:
> features.
> We would like to suggest more features:
>
> T2S
> PLS
In EPUB3, Text-To-Speech (TTS) is a "meta-feature" that aggregates 3
sub-features, by means of a SHOULD Reading System Conformance
Requirement for each of the 3 sub-features. In other words, PLS,
SSML:phonemes, and CSS3-Speech cannot really be separated.
See:
http://epub-revision.googlecode.com/svn/trunk/build/spec/epub30-overview.html#sec-tts
and:
Regards, Daniel
MURATA Makoto
We are arguing against the present compulsory requirement: providing
OpenType of WOFF
falback when SVG font is used. There no compulsory requirements for the other
direction.
2011/4/14 Levantovsky, Vladimir <Vladimir.L...@monotypeimaging.com>:
--
MURATA Makoto
It is unfortunate that we have failed to establish common understanding
of the status quo. I, as coordinator of the EGLS sub-group, have always
thought that we agreed to allow SVG fonts for both SVG and HTML content
documents, but did not mandate the support of SVG font.
Let us check the record.
1) FontEmbedding, 2010-12
http://code.google.com/p/epub-revision/wiki/FontEmbedding
In December, we created a wiki page FontEmbedding for discussion the details
of font embedding. It did not say much about SVG Fonts but referencese to
a presentation by Fujisawa-san in the EGLS Taiwan meeting.
2) EPUB WG F2F in 2010-10
The implementation pipeline doucment
(http://code.google.com/p/epub-revision/wiki/ImplementationPipeline)
shows our agreements. It shows that Recommendation J from EGLS for
the Font embedding requirement
is ready.
Recommendation I (http://www.asahi-net.or.jp/~eb2m-mrt/epub/rec2WGRev.html#RecI)
Normatively reference CSS Fonts Module Level 3
(http://www.w3.org/TR/css3-fonts/) if it becomes a CR or reference "15
Fonts" in CSS 2.0 otherwise. + +
Note: If css3-fonts is not ready, this is effectively replacing an
existing normative requirement in EPUB2, not adding anything new. See
also Section 3.5.
Font_Embedding requirement
(http://code.google.com/p/epub-revision/wiki/EGLS_requirement_list#Font_Embedding)
Requirement EGLS_CG4: It should be possible for content providers to
embed fonts such as SVG fonts and WOFF fonts as part of EPUB
documents.
Recommendation I did not mention SVG Fonts. Requirement EGLS_CG4 did
mention SVG fonts,
but it did not mention HTML or SVG content documents.
3) EGLS sub-group meeting in Taipei, 2010-10
The output of this meeting was the recommendations, which contains Rec I.
As I mentioned in 1), Fujisawa-san (a co-editor of SVG 1.1) proposed
adoption of SVG Fonts in EPUB. His presentation is available at
http://www.slideshare.net/fujisawa/user-defined-characters-solution-proposal
He did propose to use SVG Fonts for HTML content documents. In one of
his examples,
an SVG font was directly embedded witin an HTML document.
4) EGLS sub-group meeting in Sapporo, 2010-08
The output of this meeting was the EGLS requirement document,
which contains Requirement EGLS_CG4.
Fujisawa-san (a co-editor of SVG 1.1) gave a talk about SVG Fonts.
His presentation
is avaialable at
http://www.slideshare.net/fujisawa/user-defined-characters-and-svg-fonts-4898651
2011/4/14 Peter Sorotokin <psor...@adobe.com>:
--
Brady Duga
adopt them. I seem to recall specifically from Taipei an objection
over accessibility when those fonts were embedded directly in HTML.
So, I believe that the decision was to not allow svg fonts without
fallback in HTML.
--Brady
Peter Sorotokin
composition rules are harmonized with OpenType. Today's browsers do not hit
these issues largely because they ignore glyph composition in OpenType (for
expediency and speed) except for Unicode codepoints that correspond to
languages that absolutely require them (e.g. Arabic). This is a pretty lame
way to do typography and we see this approach gradually changing.
Fujisawa-san presentation that you reference actually recognizes that SVG
fonts do not work in HTML (see the example at the last page).
That said, I do not see anything that would prohibit the use of any
non-WOFF/OpenType font technology as an extension, as long as it is
understood that the fallback is going to be system font and the document
should remain readable if non-standard font format is used.
Peter
MURATA Makoto
Do you think that SVG fonts as separate files in EPUB publications
have been adopted and SVG fonts embedded in HTML have not?
Regards,
2011/4/14 Brady Duga <du...@google.com>:
Brady Duga
special privileges over any other font format. So, the documents
should be generally legible when a reading system falls back to
another font (using CSS mechanisms). There is some question here about
what can be assumed about system fonts, but that's another story.