Interview with Nikos Andronikos, chair of the SVG WG

PDF has a cousin deep inside W3C web technology: SVG.

Nikos Andronikos, chair of the W3C's SVG Working Group (WG), was kind enough to sit down for an interview about SVG, the relationship between SVG and PDF and the nature of W3C specification development.

Duff Johnson: What’s the key value-proposition of SVG, as you see it?

Nikos Andronikos: SVG provides a web-native vector graphics language that supports scripting, complex animation and interaction, and is developed in the open so anyone can contribute. SVG is safe and free to use thanks to the royalty free IP licensing commitments made by contributors.

DJ: How do you feel about the uptake you are seeing in consumer software? Do browser developers “get” SVG? Are their any browsers that do an especially good (or especially bad) job of handling SVG, and why?

NK: All browsers have a high level of SVG support. Each has it's own quirks. The key exception is the lack of SMIL animation support in Microsoft products. This lack of support is a great danger to the future of declarative SVG animation. Nowadays, implementations of SVG are a mix of the SVG 1.1 SE specification and SVG 1.2 Tiny. SVG 2 will help to remedy this situation, pulling in all the implemented features from both of those specs, while adding some nice new features. SVG 2 is much more clearly defined than previous versions, so we hope that this will help browsers fix their quirks.

SVG is becoming more and more popular, especially as Flash recedes into history. We are seeing SVG used more widely on the web, and being used for larger portions of a sites content. Because SVG is an open format, it is supported by many applications and so is very popular as an interchange format. It is also used heavily for engineering drawings by some of the world's top engineering organisations.

DJ: A similar question regarding producers.. what trends do you see? Uptake? Reliance on specific consumers?

NK: The big development of recent times is support for exporting SVG from Adobe Photoshop. That took me by surprise because you would expect Illustrator to be the tool of choice for creating SVG graphics. However it seems some designers prefer using Photoshop and Adobe has responded to that. JavaScript libraries are also important producers of SVG content. Many visualisation (e.g. D3.js) or animation (e.g. GSAP) libraries use SVG for display. I expect that most SVG content is the output of libraries rather than being hand authored, but the numbers may be evening up.

DJ: Are there notable similarities between the SVG and PDF rendering models? What use-cases clearly indicate SVG vs. PDF, and vice-versa?

NK: There are very many similarities, but some key differences. The main difference is that SVG does not define pixel perfect rendering requirements. SVG supports the PDF transparency model and shares most of the same vector graphics operators and painting methods. Another key difference is how text layout is handled. SVG text is placed at an anchor point and the layout is handled by the implementation, rather than by the producer.

DJ: Many in the web technology space wonder why, with available technologies like SVG, there’s still a need for PDF. Do you think that SVG can or should take over from PDF?

NK: SVG in itself couldn't take over from PDF. SVG is a graphics language rather than a document language. HTML + CSS + SVG on the other hand might be able to offer some competition, but these technologies are designed for consumption on screens and favour speed of processing and memory consumption over exact replication of results. PDF is essential for print, where exact results and colour management are important, and I can't see web technologies competing here. What's important is that, when defining features, we consider conversion between document formats, so that users are able to choose the best format for the task at hand and are not locked into a single format.

DJ: Is interop between SVG and PDF important? I understand that the W3C WG recently made a number of changes to SVG that have implications for interop with PDF. What can you tell us about those?

NK: As I mentioned in the previous question, I do consider interop between SVG and PDF to be important. In general, things are improving in terms of interoperability of SVG and PDF. Where I can I do try to push things towards being interoperable across document formats. This is mostly for small corner cases - in terms of the big things we are already closely aligned. Some examples of this are the way zero length path segments render depending on the cap type, or how stroke dashing renders when a negative offset is given.

One of the road blocks for interoperability for SVG is that implementations are often constrained by underlying platform graphics libraries. If those libraries render in a particular way, it's very difficult to get support for rendering any other way.

DJ: What about SVG Print?

NK: SVG print is something that comes up every so often. There's certainly use cases, but not a lot of real demand and I don't think anyone is going to put any effort behind it. DJ: SVG and PDF are both - basically - drawing systems and “related stuff”. Once upon a time, SVG was going to “take over” from PDF. What are the future key directions for SVG that you see?

NK: And then Flash came along? Now that Flash is out of the way, SVG has established itself as the vector graphics format for the web. There are other uses, but these can all be considered niche compared to the massive reach of SVG as part of the web platform.

SVG is going to be more and more closely integrated with HTML and CSS. Already that trend has been going for some time. Many features from SVG (e.g. PDF blend modes, masking, etc) have been moved into higher level specifications that can apply to HTML, CSS, and SVG. Many SVG attributes have been promoted to presentation attributes - attributes that have a corresponding CSS property that allows the parameters of SVG objects to be defined via CSS. SVG 2 is the first SVG specification to require full CSS support. And though this isn't something I am in favour of, animation of SVG objects is likely to be controlled through CSS rather than via an SVG element syntax as is the case currently with SMIL based animation in SVG.

DJ: SVG defines conformance requirements, but one thing we’ve seen in the real world is that implementers either take their own road or simply adopt technology such as webkit that more-or-less replaces conformance to a specification with conformance to an implementation. Is this inevitable, or is it reasonable to hold out hope that browser developers will gravitate towards specifications rather than implementations?

NK: In the W3C world implementations rule. A specification is only the documentation for known interoperable implementations. If browser vendors don't implement a feature, or implement differently than specified (perhaps due to performance constraints) then the specification will be changed to match the implementation rather than the other way around. This is good, as bells and whistles are nice, but it's interoperability that is most important for users. With the browser wars largely behind us, browser vendors are more cooperative than not. Dependent on manpower, they do strive to make their implementations interoperable with others. At the engineer level, there's a great deal of communication between implementors and it's a nice environment to work in.

DJ: I understand that SVG uses rendering suites as a form of validation; something that we’re considering for PDF. What can you tell us about the pros and cons of this model?

NK: The only way a specification can advance to a Recommendation and be considered complete, is for there to be interoperable implementations of all the specified features. We need a way to test this interoperability, so a test suite is essential for us. The biggest benefit is that a properly complete test suite removes any doubt about what the correct output should be.

I suppose if PDF had gone this route in the past, various implementors wouldn't have had to copy the bugs in the Adobe implementations. On the downside, creating the test suite is as much work again as creating the specification and it's not particularly interesting work so there's risk that the manpower may not be available with the result that progression of the specification is blocked.

SVG has a passionate community who are active creating demos that show off the capabilities of SVG, so we're hoping to be able to leverage that community and have some crowd sourced development. This has been somewhat successful in the past with the Test the Web Forward events held by the W3C.

DJ: How does the SVG WG decide on what new features get adopted into the specification? Is this worked out in the context of CSS and HTML specification development?

NK: It's a process similar to most specifications where we accept proposals for new features. These proposals come from within the working group and from the wider community. The working group's charter sets what sort of topics are in scope for SVG. Each proposal must have a champion who drafts the specification text and takes the lead tackling the issues that arise. Often we accept interesting graphics features that later get dropped because not all implementers are not interested or have the manpower available to include a feature. We do work very closely with the CSS working group, often co-locating meetings. The W3C also has a group called the Technical Architecture Group who review all specifications to ensure technical consistency.

DJ: Thank you very much for your time, Nikos!