W3C home > Mailing lists > Public > www-svg@w3.org > November 2004

SVG 1.2 Comment: Multiple pages

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 23 Nov 2004 12:26:52 -0600
Message-ID: <41A380EC.7010307@mit.edu>
To: www-svg@w3.org


"This translates to a printed page for hardcopy output." -- the antecedent of 
"This" is not clear to me.  It sounds like you mean "an ordered list ...", and 
per standard English usage that's what it would be.  But I don't see how such an 
ordered list translates to "a printed page".

The error handling when a resource in one page is referenced from another page 
is not defined.  It should be.

The use of "i.e. before the pageSet element" implies that resources may not be 
placed _after_ the pageSet element and referenced from pages.  This is stated 
later on, but it would be better to say it up front if the prose is going to 
refer to it in offhanded ways like this.

Are <svg> elements allowed inside a <page>?  The relaxNG schema is not clear on 
this to me, especially since I can't find the relaxNG schema for <svg> (all 
that's given in 1.1 is the doctype definition, and 1.2 doesn't seem to have this 
information).  If <svg> is allowed inside a <page>, what is the correct 
rendering of something like:

              <page />
              <page />
        <page />


The same issue arises if a <page> contains a <foreignObject> which contains an 
<svg> which contains a <pageset>.

Error-handling when an element in the SVG namespace is placed between the 
closing pageSet tag and the closing svg tag needs to be defined.


"an SVG document, i.e. the root element of the document is an SVG element"

This means that DOM mutations can change whether a document is "an SVG 
document"?  That does not seem at all desirable, given all the comments 
elsewhere in this specification about how things should be done differently for 
"SVG Documents" (eg CSS parsing is different).  Is there a normative definition 
of "SVG Document" somewhere in this specification?  If so, mentions of the term 
should link to that definition.


Given the prose in this section, is there a good reason not to simply use the 
SMIL seq and par elements?  If there is, this section needs to be elucidated to 
explain exactly what is meant by "is the equivalent of", since the sets of 
elements are clearly not equivalent in some fundamental way (if they were, the 
SMIL elements could be used).


Last paragraph: "dissalowed" is a spelling error.


"The viewBox transformation applies to printed SVG in the same way as screen 
display." -- This would mean, in typical English usage, that the viewBox 
transformation applies in the same way as screen display applies.  That can't be 
what's mean here, though...


It's not clear to me what should happen if a <page> cannot fit on an actual 
printed page when printing.  Is intra-<page> pagination allowed?  Is it 
required?  For interoperability, it would be good to define the behavior here or 
at least to clearly state what the allowed behaviors are.

Received on Tuesday, 23 November 2004 18:34:29 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:01 UTC