![](https://secure.gravatar.com/avatar/84524eb6e916f5d548e7c7c0e41fd127.jpg?s=120&d=mm&r=g)
Hi,
At last weeks SVG Working Group meeting it was resolved that meshes be accepted as part of SVG 2.0. It was decided that meshes should be treated as geometric primitives if defined outside a <defs> section and as a paint server if defined inside.
I've put my code into a branch that can be obtained at:
bzr branch lp:~tavmjong-free/inkscape/mesh
It must be linked against Cairo trunk.
I've made a few changes since the SVG WG meeting. The attribute 'stop-path' has been rename 'path' at the WG's request. The code now handles 'stop-opacity'. There are five example SVG files in the share/examples directory (their names all begin with "mesh") including one that shows the effect of setting an opacity of less that 1 on two corners of a patch. The examples can also be seen at:
http://tavmjong.free.fr/SVG/MESH/Mesh_Inkscape.html
Note that there is no ability to edit the meshes, it only handles meshes used as gradients, and that there are frequent crashes (possibly in the cairo code).
Tav
![](https://secure.gravatar.com/avatar/014b988254e77ad61312267eb1d2d696.jpg?s=120&d=mm&r=g)
On Tue, Aug 2, 2011 at 7:22 AM, Tavmjong Bah <tavmjong@...8...> wrote:
I've made a few changes since the SVG WG meeting. The attribute 'stop-path' has been rename 'path' at the WG's request. The code now handles 'stop-opacity'. There are five example SVG files in the share/examples directory (their names all begin with "mesh") including one that shows the effect of setting an opacity of less that 1 on two corners of a patch. The examples can also be seen at:
With the opacity, I would expect that it would show through to the "underlying" part of the mesh beneath the overlaps (such that a z-order would exist within the object)... is it not designed in such a way and is this how PDF's meshes work? Meshes seem like they could be exceptional to create effects like fabric or cellophane or other things which might not be completely opaque, but would have overlaps. Just curious.
Cheers, Josh
![](https://secure.gravatar.com/avatar/42dcf90d1f97672ba2d708191adc6fdf.jpg?s=120&d=mm&r=g)
On 03/08/11 00:02, Josh Andler wrote:
With the opacity, I would expect that it would show through to the "underlying" part of the mesh beneath the overlaps (such that a z-order would exist within the object)... is it not designed in such a way and is this how PDF's meshes work? Meshes seem like they could be exceptional to create effects like fabric or cellophane or other things which might not be completely opaque, but would have overlaps. Just curious.
Cheers, Josh
Mesh gradients in PDF (and cairo which implements the PDF specification of mesh gradients) always overwrite when patches fold over or later patches in the mesh cover earlier patches.
You can still create fancy effects by splitting the patch at the folds and putting the subdivided patches in separate meshes so they will blend with each other when drawn.
![](https://secure.gravatar.com/avatar/a44c92d4f696f70ea564e33127844ee5.jpg?s=120&d=mm&r=g)
On Tue, Aug 2, 2011 at 6:22 PM, Tavmjong Bah wrote:
Note that there is no ability to edit the meshes, it only handles meshes used as gradients, and that there are frequent crashes (possibly in the cairo code).
Do you think that editing is decidedly a post 0.49 feature?
Alexandre Prokoudine http://libregraphicsworld.org
![](https://secure.gravatar.com/avatar/014b988254e77ad61312267eb1d2d696.jpg?s=120&d=mm&r=g)
On Tue, Aug 2, 2011 at 8:15 AM, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On Tue, Aug 2, 2011 at 6:22 PM, Tavmjong Bah wrote:
Note that there is no ability to edit the meshes, it only handles meshes used as gradients, and that there are frequent crashes (possibly in the cairo code).
Do you think that editing is decidedly a post 0.49 feature?
I almost feel it's irrelevant because I'm not terribly confident we'll see a stable cairo release with the mesh code prior to 0.49.
Cheers, Josh
![](https://secure.gravatar.com/avatar/014b988254e77ad61312267eb1d2d696.jpg?s=120&d=mm&r=g)
On Tue, Aug 2, 2011 at 7:22 AM, Tavmjong Bah <tavmjong@...8...> wrote:
It must be linked against Cairo trunk.
I checked it out and the edges of the objects in your mesh example files aren't anti-aliased. Is this a cairo thing or just something that needs to be flipped in our rendering code.
This is a two pronged inquiry. One, I was just wondering. Two, users have been asking for years to have a preference available to turn anti-aliasing off in Inkscape.
Cheers, Josh
![](https://secure.gravatar.com/avatar/84524eb6e916f5d548e7c7c0e41fd127.jpg?s=120&d=mm&r=g)
On Fri, 2011-08-05 at 15:27 -0700, Josh Andler wrote:
On Tue, Aug 2, 2011 at 7:22 AM, Tavmjong Bah <tavmjong@...8...> wrote:
It must be linked against Cairo trunk.
I checked it out and the edges of the objects in your mesh example files aren't anti-aliased. Is this a cairo thing or just something that needs to be flipped in our rendering code.
This is a two pronged inquiry. One, I was just wondering. Two, users have been asking for years to have a preference available to turn anti-aliasing off in Inkscape.
I think it must be a Cairo thing. As Cairo is not doing anything special when a boundary is shared between two patches, it might be done so there are no artifacts at the boundary.
Tav
participants (4)
-
Adrian Johnson
-
Alexandre Prokoudine
-
Josh Andler
-
Tavmjong Bah