- From: Sergiu Dumitriu <sergiu.dumitriu@gmail.com>
- Date: Mon, 7 May 2007 15:31:21 +0300
- 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 UTC