Hi all.
I have a proposal for the SVG group about patterns.
In a pattern definition if you extend the with and height, the result is a gap between objects in pattern. if you reduce the width/height in less ammount than the original item/s bounding box, the result is croped and not too much useful in my point of view.
My proposal is the patern mix with colindants to alow make seamless pattterns easy, without any extension, clones and extra staff.
And if the order is based on each item in the pattern, not based in the full pattern, this make coolest effects without colisions.
I home this seems useful.
Cheers, Jabier.
This has my support, for sure.
On 30 Oct 2016 7:50 pm, "Jabiertxo Arraiza Cenoz" <jabier.arraiza@...2893...> wrote:
Hi all.
I have a proposal for the SVG group about patterns.
In a pattern definition if you extend the with and height, the result is a gap between objects in pattern. if you reduce the width/height in less ammount than the original item/s bounding box, the result is croped and not too much useful in my point of view.
My proposal is the patern mix with colindants to alow make seamless pattterns easy, without any extension, clones and extra staff.
And if the order is based on each item in the pattern, not based in the full pattern, this make coolest effects without colisions.
I home this seems useful.
Cheers, Jabier.
The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Thanks!
On Sun, 2016-10-30 at 22:42 +0000, C R wrote:
This has my support, for sure.
On 30 Oct 2016 7:50 pm, "Jabiertxo Arraiza Cenoz" <jabier.arraiza@...3286...... ker.es> wrote:
Hi all.
I have a proposal for the SVG group about patterns.
In a pattern definition if you extend the with and height, the result is a gap between objects in pattern. if you reduce the width/height in less ammount than the original item/s bounding box, the result is croped and not too much useful in my point of view.
My proposal is the patern mix with colindants to alow make seamless pattterns easy, without any extension, clones and extra staff.
And if the order is based on each item in the pattern, not based in the full pattern, this make coolest effects without colisions.
I home this seems useful.
Cheers, Jabier.
The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi Jabier.
First, a comment on process:
The SVG working group uses GitHub issues for most discussion, including feature requests. You can always start a thread at https://github.com/w3c/svgwg/issues.
For new features, the plan for the future is that the next step would be to move to the W3C's Web Incubation Community Group to create a complete proposal. We haven't actually tried that out in SVG yet, though.
Second, on your specific proposal:
There are a few different ways you might want to adjust a pattern to different tile sizes.
The one you're asking for (keep pattern contents the same size, but allow them to overlap) has been most recently discussed here: https://github.com/w3c/svgwg/issues/129
Theoretically, you should be able to create this effect simply by setting overflow=visible (as attribute or style) on the <pattern>. But browsers didn't implement it, and the SVG 1.1 spec explicitly allowed them to ignore it (the behavior is undefined). SVG 2 doesn't change that yet, but does add a warning that we might change it in the future & encourages implementations to support overflow patterns. See the note here: https://www.w3.org/TR/SVG2/pservers.html#PatternNotes
I tested in Inkscape 0.91, and visible overflow is not supported. But maybe Tav has already made changes to the latest builds? (I've attached a test case. There are two patterns, one with visible overflow and one with hidden overflow. If it all looks like the same pattern, visible overflow is not supported!)
I think visible overflow would be a great feature to add to the Inkscape renderer. However, at this point I would not recommend adding a GUI option to turn it on, because of the lack of support in web browsers. It might, however, be useful to create a script/extension that generates a pattern that mimics visible overflow by copying elements with <use>. (See the Github issue thread above for discussion of that method.)
If you just want to scale the pattern to a different size, that's easier. SVG allows `viewBox` on a <pattern> so that you can adjust the size of the tile and then have the contents scale to match. Alternatively, you can apply a transform to the entire tiled pattern.
Inkscape also supports the pattern transform, including in the pattern-creation GUI, which allows you to scale the pattern larger and smaller, without changing the pattern tile width & height.
Inkscape correctly renders patterns with a viewBox, but I don't think it is easy to create this type of pattern in the GUI. In the past, the result was also quite buggy in web browsers. But the worst bug in Firefox was fixed more than a year ago, so if you want to look into integrating it in Inkscape that would be really cool. The main benefit (relative to transform) is that you can adjust tile sizes in both directions without stretching the aspect ratio.
Now, what would be the most interesting, from my perspective, is if you could position elements in the pattern relative to the edges of the pattern tile. So that instead of using a viewBox or transform to scale everything together, you could use percentages to space fixed-size elements closer or farther apart.
The adoption of CSS syntax in SVG will make some of this easier. You will be able to position elements as a calculated combination of percentages and fixed lengths, using the CSS calc() function.
Unfortunately, percentages don't work in a useful way in pattern tiles. Ideally, 100% width or 100% x value would be 100% of the pattern tile width, or of the pattern viewBox width if you're using a viewBox. But it's not. Instead, it's the value of 100% width from the SVG, adjusted by whatever scaling factors are different when comparing user units between the SVG and the pattern.
This is one of the worst design decisions in the SVG spec, as far as I'm concerned. It makes percentages in patterns completely useless. Markers, clip-paths, and masks all have the same problem. And the reason why it's one of the worst problems is because it can't easily be fixed without risking backwards compatibility.
There has been strong interest from the web community to integrate SVG viewBox with CSS transforms and layout. If this happens, it may be possible to also introduce a new property that resets or defines the container scope for percentages. That is my hope, anyway.
Hope that's lots of ideas, Best, Amelia
On 30 October 2016 at 13:48, Jabiertxo Arraiza Cenoz < jabier.arraiza@...2893...> wrote:
Hi all.
I have a proposal for the SVG group about patterns.
In a pattern definition if you extend the with and height, the result is a gap between objects in pattern. if you reduce the width/height in less ammount than the original item/s bounding box, the result is croped and not too much useful in my point of view.
My proposal is the patern mix with colindants to alow make seamless pattterns easy, without any extension, clones and extra staff.
And if the order is based on each item in the pattern, not based in the full pattern, this make coolest effects without colisions.
I home this seems useful.
Cheers, Jabier.
The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi Amelia.
Thanks so much for the great info you send me.
I hope soon we can made pattern overlapped/seamless in inkscape as previous step to define it in SVG pattern overlaping spec.
Anyway there is a extension to make seamles pattern in Inkscape 0.92 using clones but, as you tell, is a bit ugly in comparsion to a css line.
All the best, Jabier.
On Sun, 2016-10-30 at 19:2 4 -0600, Amelia Bellamy-Royds wrote:
Hi Jabier.
First, a comment on process:
The SVG working group uses GitHub issues for most discussion, including feature requests. You can always start a thread at https://github.com/w3c/svgwg/issues.
For new features, the plan for the future is that the next step would be to move to the W3C's Web Incubation Community Group to create a complete proposal. We haven't actually tried that out in SVG yet, though.
Second, on your specific proposal:
There are a few different ways you might want to adjust a pattern to different tile sizes.
The one you're asking for (keep pattern contents the same size, but allow them to overlap) has been most recently discussed here: https://github.com/w3c/svgwg/issues/129
Theoretically, you should be able to create this effect simply by setting overflow=visible (as attribute or style) on the <pattern>. But browsers didn't implement it, and the SVG 1.1 spec explicitly allowed them to ignore it (the behavior is undefined). SVG 2 doesn't change that yet, but does add a warning that we might change it in the future & encourages implementations to support overflow patterns. See the note here: https://www.w3.org/TR/SVG2/pservers.html#PatternNotes
I tested in Inkscape 0.91, and visible overflow is not supported. But maybe Tav has already made changes to the latest builds? (I've attached a test case. There are two patterns, one with visible overflow and one with hidden overflow. If it all looks like the same pattern, visible overflow is not supported!)
I think visible overflow would be a great feature to add to the Inkscape renderer. However, at this point I would not recommend adding a GUI option to turn it on, because of the lack of support in web browsers. It might, however, be useful to create a script/extension that generates a pattern that mimics visible overflow by copying elements with <use>. (See the Github issue thread above for discussion of that method.)
If you just want to scale the pattern to a different size, that's easier. SVG allows `viewBox` on a <pattern> so that you can adjust the size of the tile and then have the contents scale to match. Alternatively, you can apply a transform to the entire tiled pattern.
Inkscape also supports the pattern transform, including in the pattern-creation GUI, which allows you to scale the pattern larger and smaller, without changing the pattern tile width & height.
Inkscape correctly renders patterns with a viewBox, but I don't think it is easy to create this type of pattern in the GUI. In the past, the result was also quite buggy in web browsers. But the worst bug in Firefox was fixed more than a year ago, so if you want to look into integrating it in Inkscape that would be really cool. The main benefit (relative to transform) is that you can adjust tile sizes in both directions without stretching the aspect ratio.
Now, what would be the most interesting, from my perspective, is if you could position elements in the pattern relative to the edges of the pattern tile. So that instead of using a viewBox or transform to scale everything together, you could use percentages to space fixed-size elements closer or farther apart.
The adoption of CSS syntax in SVG will make some of this easier. You will be able to position elements as a calculated combination of percentages and fixed lengths, using the CSS calc() function.
Unfortunately, percentages don't work in a useful way in pattern tiles. Ideally, 100% width or 100% x value would be 100% of the pattern tile width, or of the pattern viewBox width if you're using a viewBox. But it's not. Instead, it's the value of 100% width from the SVG, adjusted by whatever scaling factors are different when comparing user units between the SVG and the pattern.
This is one of the worst design decisions in the SVG spec, as far as I'm concerned. It makes percentages in patterns completely useless. Markers, clip-paths, and masks all have the same problem. And the reason why it's one of the worst problems is because it can't easily be fixed without risking backwards compatibility.
There has been strong interest from the web community to integrate SVG viewBox with CSS transforms and layout. If this happens, it may be possible to also introduce a new property that resets or defines the container scope for percentages. That is my hope, anyway.
Hope that's lots of ideas, Best, Amelia
On 30 October 2016 at 13:48, Jabiertxo Arraiza Cenoz < jabier.arraiza@...2893...> wrote:
Hi all.
I have a proposal for the SVG group about patterns.
In a pattern definition if you extend the with and height, the result is a gap between objects in pattern. if you reduce the width/height in less ammount than the original item/s bounding box, the result is croped and not too much useful in my point of view.
My proposal is the patern mix with colindants to alow make seamless pattterns easy, without any extension, clones and extra staff.
And if the order is based on each item in the pattern, not based in the full pattern, this make coolest effects without colisions.
I home this seems useful.
Cheers, Jabier.
The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (3)
-
Amelia Bellamy-Royds -
C R -
Jabiertxo Arraiza Cenoz