LastCall for SVG Print 1.2

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

LastCall for SVG Print 1.2

Chris Lilley

Hello www-svg-print,

This is a Last Call Working Draft transition announcement for SVG Print 1.2, which is in two parts:

SVG Print 1.2, Part 1: Primer
W3C Working Draft 21 December 2007
    http://www.w3.org/TR/2007/WD-SVGPrintPrimer12-20071221/

SVG Print 1.2, Part 2: Language
W3C Working Draft 21 December 2007
    http://www.w3.org/TR/2007/WD-SVGPrint12-20071221/

Feedback should be sent to [hidden email] which has a public archive at http://lists.w3.org/Archives/Public/public-svg-print/ by 8 February 2008.


SVG Print is aimed at software which generates formatted, paginated material for printing. The process of generating that content (eg from XSL, or from CSS, or from a wordprocessor  or charting package, or whatever other means, is at a level above SVG Print and orthogonal to it. Where SVG Print fits in is the case where the printer itself (or some print processor) understands SVG as a page description language.

Print creation software that is talking to an SVG-aware printer can easily use standard SVG features to do multiple pages per physical page (impression); to print crop marks, registration marks, quality control swatches and job control information as well as the original content.

SVG Print defines conformance classes for SVG Print documents, for SVG Printing Devices, and for an SVG Print Preview device.

The SVG Print 1.2 language adds two main features to SVG - one is a set of elements for dividing content into pages and for defining master page content (eg 'draft' printed in grey under each page) and the other is improved color specification information.

Previous specifications from W3C (SVG 1.1, CSS, XSL) allowed ICC-based color specification but made it optional and thus, not testable. Given the crucial industry importance of color management, SVG Print makes ICC-based color management mandatory and thus, testable and reliable. In addition to the sRGB and ICC-based color specifications from SVG 1.1 (eg, for calibrated CMYK) SVG Print 1.2 adds names colors, 'device' (ie, uncalibrated) colors, and allows color interpolation to occur in the CIE LAB color space. The latter feature means that colors may be freely used which are outside the gamut of sRGB.


For CSS WG, SVG WG is interested to hear of anything in CSS that would be problematic to represent in SVG Print.

For XSL FO, SVG WG is interested to hear of anything in XSL FO that would be problematic to represent in SVG Print, and also interested to explore reuse of color specification material to allow common use in XSL and SVG. Many XSL FO processors also understand SVG and it would be convenient to allow color-matched documents for that use case.


--
 Chris Lilley                    mailto:[hidden email]
 Interaction Domain Leader
 Co-Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG


Reply | Threaded
Open this post in threaded view
|

Re: LastCall for SVG Print 1.2

Sergiu Dumitriu-2

Hello,

A few comments:

- In section 3.3 of Part 1, "Master Page", the wording of "if a
rectangle was drawn prior to..." and of "If a masterPage was specified
after the rectangle was drawn" seems a bit wrong, as the rectangle is
not simply drawn. How about "if a rectangle was declared prior to..."
and "... after [displaying/printing/drawing] the rectangle on the
background for several pages..."
- Still there, a minor typo in the next paragraph: "it is good practice
to have the _objectsto_ be reused"
- Section 3.5 of Part 1, "Selecting a Master Page when referencing a
page", says: ``The current Master Pages from the externally referenced
document may be applied to the externally referenced page. In which case
use-master-page= "external"''. The dot doesn't belong there, that's not
proper english. The same thing for the next two phrases.
- Still there, "Alternatively" makes the default behavior look like a
merely possible thing, not something enabled by default.
- Section 3.7 of Part 1, "noPrint", should be changed to reflect the new
name of the attribute used in Part 2, print-display.
- The diagram in section 3.9 of Part 1 is a bit too big, maybe a smaller
variant should be used inline, with a link to the big version. Also
consider adding a caption.

P.S.: Just noticed the reply to my previous comments, thanks for
considering my previous observations.

Regards,
Sergiu Dumitriu


Chris Lilley wrote:

> Hello www-svg-print,
>
> This is a Last Call Working Draft transition announcement for SVG Print 1.2, which is in two parts:
>
> SVG Print 1.2, Part 1: Primer
> W3C Working Draft 21 December 2007
>     http://www.w3.org/TR/2007/WD-SVGPrintPrimer12-20071221/
>
> SVG Print 1.2, Part 2: Language
> W3C Working Draft 21 December 2007
>     http://www.w3.org/TR/2007/WD-SVGPrint12-20071221/
>
> Feedback should be sent to [hidden email] which has a public archive at http://lists.w3.org/Archives/Public/public-svg-print/ by 8 February 2008.
>
>
> SVG Print is aimed at software which generates formatted, paginated material for printing. The process of generating that content (eg from XSL, or from CSS, or from a wordprocessor  or charting package, or whatever other means, is at a level above SVG Print and orthogonal to it. Where SVG Print fits in is the case where the printer itself (or some print processor) understands SVG as a page description language.
>
> Print creation software that is talking to an SVG-aware printer can easily use standard SVG features to do multiple pages per physical page (impression); to print crop marks, registration marks, quality control swatches and job control information as well as the original content.
>
> SVG Print defines conformance classes for SVG Print documents, for SVG Printing Devices, and for an SVG Print Preview device.
>
> The SVG Print 1.2 language adds two main features to SVG - one is a set of elements for dividing content into pages and for defining master page content (eg 'draft' printed in grey under each page) and the other is improved color specification information.
>
> Previous specifications from W3C (SVG 1.1, CSS, XSL) allowed ICC-based color specification but made it optional and thus, not testable. Given the crucial industry importance of color management, SVG Print makes ICC-based color management mandatory and thus, testable and reliable. In addition to the sRGB and ICC-based color specifications from SVG 1.1 (eg, for calibrated CMYK) SVG Print 1.2 adds names colors, 'device' (ie, uncalibrated) colors, and allows color interpolation to occur in the CIE LAB color space. The latter feature means that colors may be freely used which are outside the gamut of sRGB.
>
>
> For CSS WG, SVG WG is interested to hear of anything in CSS that would be problematic to represent in SVG Print.
>
> For XSL FO, SVG WG is interested to hear of anything in XSL FO that would be problematic to represent in SVG Print, and also interested to explore reuse of color specification material to allow common use in XSL and SVG. Many XSL FO processors also understand SVG and it would be convenient to allow color-matched documents for that use case.
>
>



Reply | Threaded
Open this post in threaded view
|

Re: LastCall for SVG Print 1.2

Sergiu Dumitriu-2
In reply to this post by Chris Lilley


> Hello, A few comments: - In section 3.3 of Part 1, "Master Page", the
> wording of "if a rectangle was drawn prior to..." and of "If a
> masterPage was specified after the rectangle was drawn" seems a bit
> wrong, as the rectangle is not simply drawn. How about "if a rectangle
> was declared prior to..." and "... after [displaying/printing/drawing]
> the rectangle on the background for several pages..." - Still there, a
> minor typo in the next paragraph: "it is good practice to have the
> _objectsto_ be reused" - Section 3.5 of Part 1, "Selecting a Master
> Page when referencing a page", says: ``The current Master Pages from
> the externally referenced document may be applied to the externally
> referenced page. In which case use-master-page= "external"''. The dot
> doesn't belong there, that's not proper english. The same thing for
> the next two phrases. - Still there, "Alternatively" makes the default
> behavior look like a merely possible thing, not something enabled by
> default. - Section 3.7 of Part 1, "noPrint", should be changed to
> reflect the new name of the attribute used in Part 2, print-display. -
> The diagram in section 3.9 of Part 1 is a bit too big, maybe a smaller
> variant should be used inline, with a link to the big version. Also
> consider adding a caption. P.S.: Just noticed the reply to my previous
> comments, thanks for considering my previous observations. Regards,
> Sergiu Dumitriu



... and of course a happy new year for all readers.
Marco

--
-- GoldED/386 2.42.G0614+
-- http://www.gadgetscout.org