Doug Schepers wrote:
Hi, bulia-
bulia byak wrote (on 7/16/10 4:34 PM):
On Fri, Jul 16, 2010 at 4:40 AM, Jasper van de Gronde
However, don't let that stop you. In my mind the right solution here wouldn't be to make SVG simpler, but rather to make it easier to make a renderer. One of the things I've been thinking about is making a different (much more basic) format and defining how SVG maps to that format. At the very least it would make the standard much less ambiguous, but I expect it would also help in finding problem areas, and it could help implementations by suggesting a way to break down rendering.
That is a good idea I think. Right now, we often use Batik as the "standard" because in the spec, there are many unclear and confusing areas.
If there are areas which are unclear or confusing, you should ask for clarification on the SVG mailing list, www-svg@...2382... We continually issue errata, and right now are in the process of publishing an update, SVG 1.1 Second Edition, to roll some of these errata back into the spec. Browser vendors, other implementers, and even content creators have filed numerous "bugs" with the spec, and we try to correct them as quickly as possible; in addition to clarifying the text in the spec, we try also to make a new test for that feature, so it is clear to implementers what is expected.
The point here is not that current specification isn't clear enough, but rather that it could help to more formally define the semantics of SVG. First of all this helps in writing the specification, as it forces you to think about it in a more concrete way, but it also helps in implementing the standard, as the semantics are virtually unambiguous and could even provide a starting point for implementers to break down the specification into simpler tasks.
If we had a "basic SVG", for example with featureset of Postscript, and a strictly-defined mapping from the rest of SVG to basic, it would help implementers a lot.
I'd be concerned about profiling SVG, since that risks fracturing consistency of support. You expressed concern about this lack of consistency in different implementations, and profiling tends to promote such fracturing. However, it's true that only certain features of SVG make sense to implement in a static authoring tool (for example, scripting doesn't necessarily make sense for a drawing tool.
It wouldn't necessarily be a profile that you would actually write a document in, but rather a mental model (that could hopefully be mirrored in an implementation). For example, SVG currently has at least four methods to composite images (three filter elements and the "normal" compositing mode), although this might be a candidate for simplification in a future standard anyway it serves as an example of how a standard like SVG will ALWAYS have multiple ways to do more or less the same thing. Currently this kind of overlap in functionality isn't exposed in the spec at all, which makes it hard to avoid duplicating code and hinders implementing new features (as it is less easy to build on what you already have).
A positive example of something like this in the spec is the definition of rect in terms of path (although I wouldn't mind a less verbose and more formal mapping).