The SVG Working Group had a three day Face-to-Face meeting in Tokyo at the beginning of June. The first two days (hosted by Mozilla) were devoted to SVG proper while the third day (hosted by Google) was a joint meeting with the CSS Working Group. As typical, a lot of time was devoted to nitty-gritty details that only browser coders could love but there were still plenty of things of interest for artists and their brethren:
I presented a proposal based on using the CSS Exclusions and CSS Shapes specifications. As I wrote earlier, the current Level 1 version of these specifications are missing the exact features we need, namely “shape-inside” (to provide a wrapping context) and references to SVG elements; both were recently removed. However, when we met with the CSS working group we were told that they would be back in the Level 2 specs. Alan Stearns promised to get the Level 2 drafts out soon so we have something to reference.
Doug Schepers presented his idea on a simple way to provide a rectangular wrapping context which would not require CSS Exclusions or CSS Shapes:
<text x="20" y="30" width="200" font-size="20px" alignment-baseline="top">This text wraps at 200 pixels.<text>
Or for vertical text:
<text x="20" y="30" height="200" font-size="20px" alignment-baseline="text-before-edge">テキストは 10文字の後に折り返されます。<text>
Specifying only the “width” or the “height” creates an infinitely long rectangle for wrapping text. Specifying both creates a finite rectangle. The visibility of text that overflows this finite rectangle is controlled by the overflow property.
One small problem with Doug’s proposal is that the values of “x” and “y” normally refer to the baseline of the first line of text and not the upper left corner of the rectangle wrapping area. This can be changed by specifying the “alignment-baseline” property to top or text-before-edge.
Note that Doug’s proposal and my proposal are not mutually exclusive and we will mostly like incorporate both.
Both the SVG and CSS working groups are amenable to the proposals. There are some details to work out. For example, in my initial proposal one would specify that text should flow sequentially into two different objects by giving a comma separated list: shape-inside=”url(#shape1), url(#shape2)”. This, I am told, won’t work as in CSS it indicates that the text should flow into the two shapes as if they were one shape. Instead, it has been suggested that either CSS Regions and/or CSS Fragments be used. This, however, seems overly complex.
Variable width stroke:
We discussed various aspects of variable width strokes. It is clear that it will take some work to come up with a good specification. Problems include: how to specify positions, widths, smoothing, line joins, and end caps. Whether or not this gets into SVG 2 will depend on how fast these issues are resolved and in the timing of SVG 2. It it doesn’t get into SVG 2, it certainly will get into the next version.
For example, here are some possible ways of drawing a “round” stroke-linejoin:
Circles and ellipses work well when the two line segments intersect at 90 degrees. At other angles or when the line widths are changing they aren’t as useful. Here is an attempt at using a Bezier with a handle length chosen so that it matches a “round” stroke-linejoin when the width is constant.
Here is a challenge: Come up with a method that produces a suitable “round” stroke-linejoin in each of the following cases:
Marker rendering issues:
SVG renderers differ on how markers are rendered for corner cases such as a polyline with one point (see: http://paullebeau.com/svg2/markers/). We sorted out the details. As part of the discussion, we agreed that markers should apply to rectangles, ellipses, and circles (and in the future stars). The basic rule, is that markers are drawn as if these shapes were rendered as paths. We explicitly decided that circles and ellipses would have four markers.
New value for the marker property orient: “auto-start-reverse”:
This value indicates that a marker should be reversed if it is at the start of a path. This is so that one needs to define only one marker (like an arrowhead) and use it both as a start and an end marker (like a double-headed arrow). This has already been added to the spec and is in the process of being implemented in Firefox.
<defs> <marker id="MyArrowHead" viewBox="0 0 10 10" refX="0" refY="5" markerUnits="strokeWidth" markerWidth="4" markerHeight="3" orient="auto-start-reverse" fill="black"> <path d="M 0 0 L 10 5 L 0 10 z" /> </marker> </defs> <path marker-start="url(#MyArrowHead)" marker-end="url(#MyArrowHead)" d="m 75,75 150,0" />
I recently added hatch patterns to the SVG 2 specification. The work was approved with a few small changes (renaming a property and specifying that only solid colors can be used… no hatches inside hatches!).
Multiple fill and stroke properties:
As part of our discussion of hatch patterns, we discussed the ability to specify multiple fill and stroke properties. This is useful, for example, to draw a hatch over a gradient fill, or in drawing cross-hatching. We agreed to how this would be specified. This is a first step to allowing things like multiple stroke widths and colors on paths but at the moment there is some resistance to handling these more complicated cases. The feeling is that we need to start limiting what is being added to SVG 2 so that we can get it finished.
<defs> <hatch id="MyHatch1" ... > <hatch id="MyHatch2" ... > </defs> <rect x="50" y="50" width="200" height="200" fill="url(#MyHatch1),url(#MyHatch2),#a0a0ff"</rect>
Filter compositing: feBlend:
As anybody who has used the feBlend filter primitive to blend an element with transparency with a background image knows that the background gets added twice, once with the blending and once when the blend result is composited with the background. (See my example.) We can’t change the behavior of feBlend as there is too much content out there that uses it. We did agree to add a new attribute that will allow turning off compositing.