Re: SVG Filters and SVG Print specifications published

On Monday, May 7, 2007, 2:31:21 PM, Sergiu wrote:

SD> Hello,

Hello Sergiu. Thanks for your detailed comments, which have been
discussed the the WG during an SVG print telcon. Here are our
responses your comments.

Your last comment up to the top, since your earlier comments refer to
it in passing and it seems easiest to deal with this comment first:

SD> - There is nothing about page/section counters in the specs. The
SD> content generator could manually write <text> elements corresponding
SD> to the numbers, but for human generated content, it would be better to
SD> have automatic numbers. One solution would be to use css counters, but
SD> some clarifications are needed for this. A CSS counter attached to an
SD> element appearing in all masterPage-s will increment on each page, or
SD> on each section?

You are correct that there is no mention of page counters. This is
deliberate. The SVG Spec does not say how to get "page 3 of 7" printed
in whatever language and numbering system. Indeed, it says nothing
about headers, footers, textual areas, multiple columns, and so on.

These are the domain of other specifications, for example HTML and
CSS, or XML and XSL-FO. Or some other process entirely. But when the
pages have been laid out, one of the options for printing them should
be SVG Print.

Please refer to the section on using SVG with XSL-FO, which explains
how the different stages of the processing model interact. Given your
comment, we should probably explain this more in the section on SVG
Print and CSS.

So if automated page numbering is used, it has already happened by the
time that SVG Print is used.

SD> I have some observations regarding the SVG Print specifications.
SD> - In section 3.3 of Part 2 (The masterPage element), it is not
SD> specified when the MP should be rendered. If, for example, there are
SD> no pages that use that MP (another MP follows right after it, or it
SD> was the last element in the pageSet), a user agent could skip it
SD> entirely, influencing the  computation time and css counters.

You have drawn the correct inference, that an unreferenced master page
is simply unused. in this it is like other SVG elements such as
symbols, gradients etc. if they are defined but not referenced, they
have no effect on rendering.

Depending on the implementation method, its likely that unused
elements have no impact on processing time beyond a slight increase in
parsing time and some additional memory.

As noted above, page counters are unrelated here.

SD> - In the same section, it is not specified if the MP counts as a
SD> different instance on each page. This affects, for example, how css
SD> counters are incremented.

Given that we don't use counters, and that pages are not animated, the
difference does not have an effect.

SD> - It would be nice to be able to reuse/extend MPs. For example, a
SD> presentation could have 3 types of slides: title slides, normal slides
SD> and advanced slides. The title slides occur every once in a while
SD> between normal slides. Advanced slides are the same as normal slides,
SD> with an extra (Adv.) added on the side. Instead of redefining the
SD> complete slide layout each time the slide type changes, it would be
SD> better to define only one title MP and one normal slide MP, and the
SD> advanced slides MP could extend the normal one. Of course, this can be
SD> achieved by using defined elements in the global <defs>, but more
SD> complicated situations can be imagined where this is not feasible. A
SD> solution would be to add a new attribute to the masterPage element,
SD> "base".

Thats something we discussed. On the one hand it adds more
flexibility; on the other hand, more complexity and makes discard
harder.

There is a similar facility with gradients, which can refer to other
gradients. Feedback so far is that this feature is not much used and
is found to be over complex.

On balance therefore we decided not to allow master pages to chain arbitrarily.

However, we do agree on the need to have multiple master pages.

SD> - In section 3.4 of Part 2 (The rendering-order attribute), it states
SD> that "A User Agent for Printing or Print Preview MUST render content
SD> that is part of the Background Master Page on each displayed page,
SD> before the page content" (and similar for foreground MP). "Render" is
SD> used here with the meaning that the MP must actually be rendered for
SD> each page? Or can it be rendered only once and have the result reused?

Render means that it shows up in the output. Whether the
implementation re-evaluates it entirely, partially, or caches the
rendered bitmap is an implementation detail that does not affect the
rendered output (since there is no animation, so rendering the master
page on first use and cacheing it is entirely possible).

SD> - In section 3.5 of Part 2 (Default master pages), it says: "This
SD> might be confusing to some authors, who might expect elements   in
SD> defs to be available to all pages". Doesn't this contradict the
SD> comment is section 3 of Part 1 (An example with a bit of everything),
SD> which states:
SD>    <defs>
SD>      <!-- definitions here are available on each page -->
SD>    </defs>

Its good practice to have a defs before the pageSet, for reused
resources. These are available on every page.

The wording you cite is indeed confusing; the content before the
pageset is no longer used as a (default) master page; but the content
is still there (its not discarded, which the current wording implies).
So any content in defs will continue to be available.

After discussing your comments, we have decided to clarify the wording
to change "is discarded" to "is no longer used as a default master
page". And delete tha part about it being confusing, since it is no
longer confusing :)

SD> - The color-interpolation attribute (section 5.1 of Part 2) affects
SD> not only printing content, but also SVG files that should be displayed
SD> on screen, because it affects "color animations". Shouldn't it be
SD> defined elsewhere? It is not defined in the Tiny spec, but it is often
SD> referenced in SVG 1.2 Filters.

Its not defined in Tiny 1,2, because SVGT1.2 only uses the default
value. However it is defined in SVG Full 1.1, and its extended in SVG
Print, not defined for the first time

http://www.w3.org/TR/SVGMobile12/painting.html#Color

This is why the Print spec says

"The color-interpolation property, not in SVG Tiny 1.2 but used in SVG
1.1 [SVG11], is extended by this specification to add new values using
the CIE L*a*b* color space. Both the cartesian (CIE-Lab) and polar
(CIE-LCHab) forms are supported."

SD> - Section 3.1 (The pageSet element) of Part 2 states that "A User
SD> Agent for Printing or Print Preview MUST treat all children of a
SD> pageSet element as unsupported elements except for page elements and
SD> masterPage elements". Doesn't this contradict section 3.4 (Referencing
SD> other pages) from Part 1?

Yes - we will change change "except for page elements and masterPage
elements" to "except for page, masterPage, and use elements"

SD> - Section 3.4 (Referencing other pages) from Part 1 has no
SD> corresponding section in Part 2 at all.

Sometimes the primer doesn't have anything to say about a particular
language feature. And sometimes the primer needs an extra section to
introduce or explain things, which doesn't correspond to a specific
language feature. So this is normal.

SD> - About referencing complete documents. I think this would be a nice
SD> feature, allowing a document to be split into sections (or chapters),
SD> each chapter being written in a different document. This allows
SD> parallel development, and keeping files to a reasonable dimensions.

There is already xinclude, which looks more generic and more suitable.

SD> -- Referencing the complete document would contradict the definition
SD> of the SVG use element in SVG Tiny; for this reason, maybe the
SD> reference should be made to the pageSet element.

Right. But its not clear the extra complexity buys you much.

SD> -- The reference should be allowed inside pageSet elements only; after
SD> the element will constitute an exception to "A User Agent for Printing
SD> or Print Preview MUST treat all elements from the SVG namespace
SD> between the closing pageSet tag and the closing svg tag as unsupported
SD> elements", and before it will constitute an exception to the
SD> definition of the default master pages. And inside a page, well, pages
SD> from outside are not content that goes inside a page, but between
SD> pages.

Yes, I would need extra wording if it was allowed.

SD> -- Regarding the Master pages in use, I think that both alternatives
SD> have their use cases. Perhaps the difference could be made by the
SD> value for xlink:show: "embed" means use the MP from the included file,
SD> "other" means use the MP from the includer. Or, if the included
SD> document does contain MPs (excluding the default), then use them.
SD> Otherwise, discard the default MP from the included document and use
SD> the currently active MP from the includer.

Overall we are tending towards not defining an extra mechanism here
but to reuse an existing one that seems to have good traction among XML
tools.

Many thanks for your helpful comments!

SD> Regards,
SD> Sergiu Dumitriu

SD> On 5/2/07, Chris Lilley <chris@w3.org> wrote:

>> Hello www-svg,

>> The SVG Working group is pleased to announce the publication of two specifications, in five documents:

>> http://www.w3.org/TR/2007/WD-SVGFilterReqs12-20070501/
>> SVG Filter Requirements
>> http://www.w3.org/TR/2007/WD-SVGFilterPrimer12-20070501/
>> SVG Filters 1.2, Part 1: Primer
>> http://www.w3.org/TR/2007/WD-SVGFilter12-20070501/
>> SVG Filters 1.2, Part 2: Language


>> http://www.w3.org/TR/2007/WD-SVGPrintPrimer12-20070501/
>> SVG Print 1.2, Part 1: Primer
>> http://www.w3.org/TR/2007/WD-SVGPrint12-20070501/
>> SVG Print 1.2, Part 2: Language

>> SVG Filters were previously published as part of SVG 1.1. The new documents republish that functionality as an add-on for SVG Tiny 1.2, with corrections and clarifications and a few new features such as shortcut filters (dropshadow ..) and control over filter regions. This specification is also resuable by other specifications like CSS or XSL.

>> SVG Print 1.2 updates the earlier SVG print specification. SVG Print adds multiple pages and color management (both needed for print), and also adds new color interpolation spaces to lift the restriction on colors in the sRGB gamut.

>> --
>>  Chris Lilley                    mailto:chris@w3.org
>>  Interaction Domain Leader
>>  Co-Chair, W3C SVG Working Group
>>  W3C Graphics Activity Lead
>>  Co-Chair, W3C Hypertext CG










-- 
 Chris Lilley                    mailto:chris@w3.org
 Interaction Domain Leader
 Co-Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Thursday, 19 July 2007 05:58:26 UTC