-
New path commands will be added to make the drawing of arcs easier: “arc”, “ellipse”, and two forms of “arcTo”. These will match the path implementation found in canvas.
An example of arcTo. In this example, p0 is the previous path point. p1, p2, and the radius r are arguments of the arcTo command.
-
If arcTo isn’t enough goodness for you, making rounded corners for shapes, polygons, and polylines will be child’s play with a new rounded corner option where one supplies the radius for the rounded corners. It is still to be decided if generic paths will have this option.
An example of rounded corners for two polyline elements.
- Speaking of polygons, SVG2 will have a star/polygon element for convenience. It will support most if not all the options available with the Inkscape Star Tool.
- A new extrapolated line join style was tentatively approved at the last SVG Face-To-Face meeting (see my previous blog entry). It is now approved to be added to the specification.
-
Hatches have been approved. The exact syntax has yet to be worked out. It will be something like:
<hatch id="complex" angle="90" hatchUnits="userSpaceOnUse" pitch="10" x="0" y="0"> <hatchPath offset="0" stroke-width="1"/> <hatchPath offset="5" stroke-width="1" stroke-dasharray="5 2 1 2"/> </hatch><hatch id="complex" angle="90" hatchUnits="userSpaceOnUse" pitch="6" x="0" y="0"> <hatchPath offset="0" stroke-width="1" d="m 1,0 c 0,4 8,6 8,10 8,14 0,16 0,20"/> </hatch>Cross hatching will be handled by allowing one to combine two hatchings together.
Examples of the hatches given above.
-
Marker fill automatically matching stroke color got a step closer to reality with “context-fill”, “context-stroke”, and “context-fill-opacity” being approved for SVG2. A new property, “context-value” was also endorsed. This value allows one to pass in stroke style properties such as “dash-array”.
<marker id="yeah" fill="context-stroke" .../>
- The Working Group endorsed auto-smoothing of mesh gradients (without smoothing, gradients are subject to Mach banding). Auto-smoothing is done both by Adobe and CorelDRAW. However, when they export the meshes, for example to PDF, they export an 8 x 8 array of patches for each native patch since PDF (and PostScript) don’t have smoothing built in. The Working Group has asked the Adobe representative if Adobe would be willing to make public their smoothing algorithm. This would allow, for example, Illustrator to directly write smoothed meshes to SVG.
- Connectors, useful for flow charts, organizational charts, etc. will be standardized in a separate module. A very simple routing (basically a straight line) will be provided. Content creation programs (e.g. Visio, Dia, Inkscape) can override the default routing and supply a more complicated connecting path. See the Editor’s Draft for details.
- As a result of a comment at SVG Open, the Working Group has approved Internationalization of <title> and <desc> elements. One will be able to supply multiple elements with different “lang” attributes. An SVG renderer will select which element to use via these attributes.
- The Working Group is investigating a new type of noise for filters that would be easier for hardware acceleration.
-
Mozilla demonstrated the use of SVG inside of Open Type Fonts. Firefox nightly has experimental support for Mozilla’s SVG OTF proposal. Adobe also has a proposal on the table with a different syntax. The two proposals will need to be merged.
Here are two glyphs with different fill colors that are passed into the glyphs using “context-fill” and “context-stroke”.
SVG Working Group Meeting Report – Rigi Kaltbad
The SVG Working Group had a three day Face-to-Face meeting in Rigi Kaltbad (Switzerland) just after The Graphical Web (formerly SVG Open) conference. Thanks to the conference organizer, Andreas Neumann, I was able to attend the meeting in person. While a lot of the work focused on the nitty-gritty details of more interest to browser vendors and developers, there were still a number of things of interest to artists and designers:
Fantastic news! I can’t tell you how excited I am about the arc feature. When do you think these changes will arrive in Inkscape?
It will be awhile. We’ve (the SVG WG) agreed to add the arcs to the specification but the addition hasn’t bee done yet. Once added, we’ll need to review it and get feedback. It would be added to an Inkscape stable version only after it was sure that that part of the specification is stable and won’t change (maybe after it was implemented by at least one of the browsers without a vendor prefix).
Thanks!
Great! Long waiting for this feature! Thanks!
They really should have. There are people walking under the sun who’d kill for this feature
Generic paths with curves are a bit more difficult to handle than paths with straight lines. Someone needs to make a concrete proposal (with required math and rules) on how to implement rounding on paths.
Wow. I like especially the hatching and cross hatching. A huge improvement for the use of SVG in technical figures and CAD-near envirements. Great job!
This is a long one, for I try to say all my thoughts on recent advancements.
As an artist, I appreciate your efforts to have decent gradient meshes in SVG & Inkscape. Hope you’ll have meshes working with alpha channel (translucency) as well. If you can match those in Adobe Illustrator and Corel Draw – it will be a tremendous improvement for art, SVG-based icons, etc. I also think they use some kind of cubic Bézier interpolation. There’s a number of photorealistic vector illustrations using smooth gradient meshes. I think there must be a way to have non-smooth parts within otherwise smooth gradients, maybe by placing 2 or more vertexes in one spot and zeroing their respective handles length (also, they can be discontinuous or have only first derivative continuity in one direction and smooth in another – all by appropriate vertex and handles placing and picking colors). I need to see how it works in existing proprietary software. If it works, and have alpha values, it will be a universal tool to make any imaginable gradient – with tears, steep cliffs that smoothly blend into other parts of the gradient, etc.
Can something be done with topology though? Like having subdivision meshes and inserting new vertexes only where they’re needed. Synthax can be like inserting a table with its own rows and cells into a cell of a bigger table (mesh).
Original meshes can be tedious to manipulate, although less tedious than trying to achieve complex shadings with linear and radial gradients, transparency and filters.
Can you tell me, are these meshes going to be GPU-accelerated?
A lot of comments and questions:
It should be possible to have non-smooth parts by placing overlapping vertices.
It will be possible to have translucency for the entire mesh, but inside the mesh it is difficult for regions that overlap. It is something to think about.
We are not thinking about having subdivisions inside meshes. The syntax is already getting complicated. Authoring tools could simulate this if they want.
It will be up to each implementer to decide if they accelerate the meshes with the GPU. In principle it shouldn’t be hard.
Well, should overlapping regions happen they maight be handled two ways, as I see it.
1. Let the overlapping parts combine like 2 different transparent objects with their gradient alphas and colors. It is already working with existing fills.
2. Truncate overlapping part and let it have sharp boundary, ignore the underlying part.
Or precise behavior might be an option.
I hope someone can check how overlapping is handled in existing implementations or is is simply not allowed to happen. I’ll try to check myself.
I wondered if Inkscape somehow might handle rendering in GPU, since all the complexities seem slow at the moment.
What I found out is that Corel is not a good example. First, it handles overlapping in gradient meshes awfully – the output is aliased. Anyway, it is avoidable.
But much bigger problem that its smoothing work fine unless you add more vertexes than basic 2*2 mesh. Visible second-order discontinuities appear which we want to avoid with SVG smoothing.
Thought 3rd degree splines can be subdivides without introducing any variations in curve shapes (and color profiles, consequently) – just like curves in SVG are 3rd order Bézier curves that can have a new point inserted seamlessly.
Maybe I’m wrong about Corel Draw and there is a way to make everything smooth but I couldn’t find it right away and such vertex insertion is undesirable.
I also examined Illustrator’s handling of meshes, and overlapping seemed done just by cutting ‘underlying’ part of the mesh. Illustrator allows for setting opacity values for mesh vertexes, and as far as I can judge simply truncates opacity in overlapping areas and interpolates it as it does color values. So this should not be a problem.
Vertex insertions altered the mesh anyway so it’s hard to say how it should be done. Inserted vertex just assumes the last color selected. The best behavior might be just trying to insert it without altering overall color profile, like inserting a new vertex into a Bézier curve. I think it might be possible considering the very nature of color profiles which are Bézier curves themselves.
You can download a trial version of illustrator and see how it works.
There’s only one little drawback in meshes in Illustrator compared to those in Corel Draw I’ve noticed so far: Corel’s app allows for cusp nodes in their meshes, i.e. arbitrary alignment of handles in horizontal plane at every vortex. But this can easily be achieved, in theory, by overlapping votexes and zeroing some handles.
I also didn’t find control over vortexes intuitive in Illustrator – where’s the deletion option for rows/columns?
Upd: I accidentally made some vortexes cusp, seemingly – by playing around and tangling everything, but I struggle to find an explicit control for it. I hope controls can be done better when it comes into Inkscape. I suppose it must have the same set of controls like for editing vertexes and handles in curves. Like, making a line straight or curve, retain or snap angle holdng Down Ctrl, even stitching and cutting meshes (stitching uneven meshes produces more patches in lesser mesh to fill the remaining area, probably transparent, you only specify at what vertexes you start).
More intuitive control will turn Inkscape into a killer artist app.
Having tried gradient meshes quickly in both Adobe Illustrator and Corel Draw I made the following conclusions on how they should work in SVG and Inkscape in particular.
1) They must be 2nd-derivative smooth, first derivative smoothness or discontinuity can be achieved by accurate close positioning of handles and vertexes, and choosing appropriate colors. This will work automatically. If you intend to allow for cusp nodes etc. – let it be controlled in the same manner as ordinary curves. It must be intuitive for current Inkscape users (I couldn’t arbitrarily control them in Illustrator right away).
2) I like your idea of smoothing, Tavmjong – having zeroes at maximums and minimums, while interpolating slope, per every color channel (minimums and maximums may not match in different channels). But slope is linear for quadratic curves, cubic curves have linear 2nd derivative and quadratic first. So it preferable to interpolate linearly 2nd derivative for non-maximums for every channel, I guess. This way it is compatible with behavior of cubic color profiles with two handles and will allow for insertion of nodes without altering mesh look unless you change new vertexes colors, positions, etc. It is consistent with how contours work.
The only difference is that handles don’t control slope for color profile at nodes, they only control color influence of every node.
3) Any overlapping in existing apps is dealt with by simple truncation of what’s behind, regardless of the following point, which is
4) Opacity (alpha). Illustrator allows it on per-vertex basis, just interpolating it independently of color channels. It may lead to strange effects that arise naturally from this behavior. I.e. if you have a yellow vertex with alpha=0 (fully transparent) amidst black ones, the black will fade into increasingly transparent and washed down yellow. It easily can be made more intuitively looking by fading into black with alpha=0 or by calculating intermediate color for the adjacent vertexes for ‘natural’ look.
Please consider these, especially alpha and interpolation that will allow, in theory, smooth nodes insertion. Even in Illustrator adding a new node distorts colors in the mesh in a newly inserted row and column. I think this requires also interpolating mesh curves like Illustrator does – they assume shape closer to either of adjacent mesh curves, depending on closer to which one you insert. Interpolation of handles must be something that produces this result: The color of any point inside the patch is determined by a two-dimension bi-linear interpolation of the corner colors followed by a geometric mapping defined by the Bézier patch sides. I think the same geometric mapping will let us find the right color and handles position at every new vertex that will make it non-intrusive for current mesh – it think it is highly desirable behavior and should be the default one in Inkscape. As for deletion – there can be option for plain deletion and best fitting of remaining profile like it happens with normal curves. That is good for consistency.
I guess insertion and deletion is done way easier for linearly interpolated Coons patches. but in similar manner.
I hope somebody can check the math here. As far as I understand, satisfying this condition and setting a color for a new node (and all the nodes along 2 new lines) based on the current underlying color will allow exactly for insertion of new nodes without altering the appearance of the mesh elsewhere – like adding a new node into curve doesn’t alter its appearance unless you start to edit it.
With all these features SVG and Inkscape in particular will have the best gradient meshes ever, since those present today have some nasty features – I’m not sure if it’s internal to the AI and CD formats or just the way software handles their editing.
I also noted how Illustrator produces visible triangulation – very visible on a good IPS LCD panel, and it might be a hint on how their rasteriser works. Maybe a more accurate mode is somewhere in the settings.
Let me know what you think. We may try to discuss it via email.