W3C home > Mailing lists > Public > www-svg@w3.org > May 2007

Re: SVG Filters and SVG Print specifications published

From: Sergiu Dumitriu <sergiu.dumitriu@gmail.com>
Date: Mon, 7 May 2007 15:31:21 +0300
Message-ID: <fdafd3230705070531s56bc16at2c6e94ab70508398@mail.gmail.com>
To: "Chris Lilley" <chris@w3.org>, www-svg@w3.org

Hello,

I have some observations regarding the SVG Print specifications.
- In section 3.3 of Part 2 (The masterPage element), it is not
specified when the MP should be rendered. If, for example, there are
no pages that use that MP (another MP follows right after it, or it
was the last element in the pageSet), a user agent could skip it
entirely, influencing the  computation time and css counters.
- In the same section, it is not specified if the MP counts as a
different instance on each page. This affects, for example, how css
counters are incremented.
- It would be nice to be able to reuse/extend MPs. For example, a
presentation could have 3 types of slides: title slides, normal slides
and advanced slides. The title slides occur every once in a while
between normal slides. Advanced slides are the same as normal slides,
with an extra (Adv.) added on the side. Instead of redefining the
complete slide layout each time the slide type changes, it would be
better to define only one title MP and one normal slide MP, and the
advanced slides MP could extend the normal one. Of course, this can be
achieved by using defined elements in the global <defs>, but more
complicated situations can be imagined where this is not feasible. A
solution would be to add a new attribute to the masterPage element,
"base".
- In section 3.4 of Part 2 (The rendering-order attribute), it states
that "A User Agent for Printing or Print Preview MUST render content
that is part of the Background Master Page on each displayed page,
before the page content" (and similar for foreground MP). "Render" is
used here with the meaning that the MP must actually be rendered for
each page? Or can it be rendered only once and have the result reused?
- In section 3.5 of Part 2 (Default master pages), it says: "This
might be confusing to some authors, who might expect elements   in
defs to be available to all pages". Doesn't this contradict the
comment is section 3 of Part 1 (An example with a bit of everything),
which states:
   <defs>
     <!-- definitions here are available on each page -->
   </defs>
- The color-interpolation attribute (section 5.1 of Part 2) affects
not only printing content, but also SVG files that should be displayed
on screen, because it affects "color animations". Shouldn't it be
defined elsewhere? It is not defined in the Tiny spec, but it is often
referenced in SVG 1.2 Filters.
- Section 3.1 (The pageSet element) of Part 2 states that "A User
Agent for Printing or Print Preview MUST treat all children of a
pageSet element as unsupported elements except for page elements and
masterPage elements". Doesn't this contradict section 3.4 (Referencing
other pages) from Part 1?
- Section 3.4 (Referencing other pages) from Part 1 has no
corresponding section in Part 2 at all.
- About referencing complete documents. I think this would be a nice
feature, allowing a document to be split into sections (or chapters),
each chapter being written in a different document. This allows
parallel development, and keeping files to a reasonable dimensions.
-- Referencing the complete document would contradict the definition
of the SVG use element in SVG Tiny; for this reason, maybe the
reference should be made to the pageSet element.
-- The reference should be allowed inside pageSet elements only; after
the element will constitute an exception to "A User Agent for Printing
or Print Preview MUST treat all elements from the SVG namespace
between the closing pageSet tag and the closing svg tag as unsupported
elements", and before it will constitute an exception to the
definition of the default master pages. And inside a page, well, pages
from outside are not content that goes inside a page, but between
pages.
-- Regarding the Master pages in use, I think that both alternatives
have their use cases. Perhaps the difference could be made by the
value for xlink:show: "embed" means use the MP from the included file,
"other" means use the MP from the includer. Or, if the included
document does contain MPs (excluding the default), then use them.
Otherwise, discard the default MP from the included document and use
the currently active MP from the includer.
- There is nothing about page/section counters in the specs. The
content generator could manually write <text> elements corresponding
to the numbers, but for human generated content, it would be better to
have automatic numbers. One solution would be to use css counters, but
some clarifications are needed for this. A CSS counter attached to an
element appearing in all masterPage-s will increment on each page, or
on each section?

Regards,
Sergiu Dumitriu

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
>
>
>



-- 
http://purl.org/net/sergiu
Received on Monday, 7 May 2007 12:31:32 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:36 GMT