Feedback on SVG Print 1.2 WD 2007-12-21

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

Feedback on SVG Print 1.2 WD 2007-12-21

Jeremias Maerki-2

Feedback on SVG Print 1.2 WD 2007-12-21

Foreword: SVG is still somewhat "under-adopted" in various fields which
is unfortunate. It is good to see a light-weight print format based on
XML/SVG. I'd like to emphasize "light-weight" since IMO there is (or
will be) a better and more comprehensive approach in the form of Adobe's
Mars format which is also based on SVG. I think that both have their
justification. Mars is probably just a bit too complex to fit on
resource-restricted devices, but SVG Print in its current setup does not
have the potential to even get near the functionality of PDF to which
Mars can become an alternative. IMO SVGP should be reduced to target
constrained resource printing and Adobe should be encouraged to bring
Mars to the W3C so it can cover the missing functionality between SVGP
and PDF (features like special color spaces, encryption, signatures,
marked content/logical structure, forms etc.). Realistically, SVGP will
not be able to go against PDF (or Mars if Adobe chooses to put more
energy into it, i.e. propagate it as a successor to PDF). SVGP will most
likely remain a niche standard with the most chances in the constrained
resource printing. Therefore, reduction to the necessary is IMO a good

My background: I'm a developer in the Apache XML Graphics project which
looks after Apache FOP (open source XSL-FO implementation) and Apache
Batik (I'm sure that one's well known here).

Part 1:
5.1: Typo: "uuses"
5.2: "for the most part has not been well understood". It would be good
to include a reference to educational material if you know any.

Part 2:
3.9, The use-master-page attribute
I'd skip this to keep SVG Print as light-weight as possible. I
personally don't see a use case that makes sense.

3.10, The print-display attribute
IMO, the print-display attribute as specified is fine like that.

5.2, Specifying paint
It's important to synchronize XSL-FO and SVG as much as possible as they
are often used together. Unfortunately, this hasn't happened. I'd like
to point out the differences below. Maybe something can be done on some
levels to bring the two more closely together.

ICC is still not understood very well and although it's widely used in
various technical specifications, real-world usage still seems limited.
Many print shops I've worked with often say: "I don't care about color
profiles, just give me a CMYK-PDF and don't dare use anything RGB!"
Which includes sRGB. That's an indication that there are educational
gaps. I can't even say myself that I really understand this complex
field (so take what I write here with a grain of salt. I'm still
learning.). Often there are also gaps in the software that is used.
Anyway, people still want device-specific CMYK and they want Pantone
spot colors. The introduction of the deviceColor tells half that story,
I guess.

(Note: syntax simplified, the listing is just to point out the differences)

XSL-FO: rgb(num, num, num) or #rgb
SVGP: rgb(num, num, num) or #rgb

ICC color:
XSL-FO: rgb-icc(num, num, num, <name>, num*)
SVGP: <color> icc-color(<name>, num*)

ICC named color (=spot color, often requested by users of XSL-FO):
XSL-FO: not supported
XSL-FO, proprietary RenderX XEP: rgb-icc(num, num, num, #SpotColor, <spot-color-name>, tint-value, alt-color-space, num*)
XSL-FO, proprietary AntennaHouse: rgb-icc([num, num, num,] #Separation, <spot-color-name>[, tint-value] [,C,M,Y,K])
SVG 1.2 Tiny: not supported
SVGP: icc-named-color(<name>, value*) but possibly also via device-color, implementation-specific???
Adobe Mars: using device-color() function via Separation and DeviceN color spaces

Drawback of the icc-named-color approach: It requires a profile with the
color names. I wonder how many people know how to produce that. I don't,

This shows that there is a gap between reality and the ideal world. :-)
I hope the experts in the WG have good ideas how to improve the

5.4, deviceColor Element
I'm not entirely happy with this. I agree that a device-color() method
is necessary for specifying paint. But the deviceColor element is IMO
too vague. The TODO about conformance criteria is an indicator that this
may not be thought through, yet. I see this as a very important point
where interoperability can become a problem. Of course, there are
fallbacks in place (at least sRGB, maybe even ICC as noted in another
TODO). I suggest that at least for device-specific CMYK, RGB and Gray a
default representation in the deviceColor element should be specified to
increase interoperability. These are AFAIK the most commonly used color
spaces besides sRGB and ICC-based. Otherwise, the likelyhood of
different approaches is too big. Alternatively, these three color space
could be specified as implicitely defined pseudo-profiles like Adobe
Mars does (DeviceRGB, DeviceCMYK, DeviceGray). Some degree of
standardization for spot colors could also be good in case
icc-names-color isn't well adopted. But then, thinking back to the
light-weight idea, the use of deviceColor should probably better be
discouraged by the spec. It's a good idea to specify the use of
additional color space in SVG in general, but maybe not in SVGP.

Adobe Mars:

Ideas for SVG Print:

- an optional page-label attribute on the page element. This can be
interesting for print preview devices. In XSL there's a distinction
between page index (1, 2, 3) and page label (I, II, II, 1, 2). But of
course, this opens the door for other wishes like a bookmark tree and
annotations etc. So this is probably a bad idea and should be left to

- 4.2: possibly mention a ZIP-based container as alternative
bundling/packaging method. (Mars uses a ZIP-based container and I
personally prefer that to the MIME approach.)

I'm looking forward to help modifying Apache Batik so I can, at some
point, implement SVGP output support for Apache FOP and to turn Batik
into a SVGP converter (to PDF, PS, AFP etc.). Should be fun. Thanks to
the WG for your work here.

Best regards,
Jeremias Märki
Jeremias Märki, Software-Development and Consulting
Contact Information:

Reply | Threaded
Open this post in threaded view

Re: Feedback on SVG Print 1.2 WD 2007-12-21

Chris Lilley

On Tuesday, February 5, 2008, 10:46:18 PM, Jeremias wrote:

JM> Feedback on SVG Print 1.2 WD 2007-12-21

Jeremias, many thanks for your careful review and numerous suggestions. Your feedback is timely since the SVG WG is meeting next week at a face to face meeting where your comments will be discussed.

Your offer to implement is also very much appreciated. SVG Print should be a fairly small delta on top of Batik 1.7.

SVG WG and XSL-FO subgroup have been discussing closer integration between XSL-FO and SVG for XSL 2.0; your notes on syntactic differences and the shade/tint extensions in some implementations are most helpful.

More specific comments after next weeks meeting ...

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