Re: [Inkscape-user] pattern mismatch - the reason for it
I discovered now the reason for the mismatch:
The problem is that inkscape takes the path AND its stroke width into account when processing a tile clone, i.e. the offset of the new rows and columns is not based on the centre of the line but on the outline of it which depends on the stroke width (see attached screen shot). However, to produce a pattern which is good for a patternfill it is necessary that this process is based only on the centre of the line, i.e. the offset of the new rows and columns is independent from stroke-width.
(Screenshot: thin line results in small offset, thick line results in larger offset - take the grid as a reference; to make the pattern suitable for a fill pattern each line has to be place on the grid without offset)
A solution is to diminish stroke width to 0, do the tile-clone, and then adjust the stroke width to the wished value. However, the problem reoccurs when this pattern is used as a fill pattern! Even there the stroke width is taken into account! This could be easily fixed with a clipping mask. But the latter does not work with the command "objects to pattern", it results in an empty pattern.
Henning
On Wed, 29 Nov 2006 13:37:39 -0500, bulia byak wrote:
On 11/29/06, Henning Lorenz
<henning.lorenz-wmbx2sCzPmCzQB+pC5nmwQ@...2053...> wrote:
Then I changed the colour in the source, but there is a principal question: Is something wrong and if so, what? And why doesn't this affect the "pattern-pinstripes-diagonal" pattern? Maybe I just missed an important point in constructing patterns in inkscape?
It's hard to visualize what you're talking about without a sample or screenshot. However one thing you should be aware of is this: "Object to pattern" creates a rectangular pattern with its sides parallel to x/y axes. Only after that can you rotate or skew it. So if your existing pattern is rotated or skewed, then converting it to objects and then back to pattern will not give the same result. If you want to edit it, first rotate the pattern so it's rectangular, convert to objects, edit, convert to pattern, and rotate back to the original angle.
When applying "objects to pattern", is there a way to tell inkscape to define the height and with of the resulting pattern by the position of the nodes only, neglecting everything else which extends beyond the nodes (e.g. parts of the line depending on the strokewidth)?
Why? I found out that I can eliminate the problems I had with offsets in pattern-fills (see my earlier posts) by adjusting the height and width of the pattern to the heigth and width defined by the nodes of the lines which the pattern is based on.
On Thu, 30 Nov 2006 11:10:51 +0100, Henning Lorenz wrote:
I discovered now the reason for the mismatch:
The problem is that inkscape takes the path AND its stroke width into account when processing a tile clone, i.e. the offset of the new rows and columns is not based on the centre of the line but on the outline of it which depends on the stroke width (see attached screen shot). However, to produce a pattern which is good for a patternfill it is necessary that this process is based only on the centre of the line, i.e. the offset of the new rows and columns is independent from stroke-width.
(Screenshot: thin line results in small offset, thick line results in larger offset - take the grid as a reference; to make the pattern suitable for a fill pattern each line has to be place on the grid without offset)
A solution is to diminish stroke width to 0, do the tile-clone, and then adjust the stroke width to the wished value. However, the problem reoccurs when this pattern is used as a fill pattern! Even there the stroke width is taken into account! This could be easily fixed with a clipping mask. But the latter does not work with the command "objects to pattern", it results in an empty pattern.
Henning
On Wed, 29 Nov 2006 13:37:39 -0500, bulia byak wrote:
On 11/29/06, Henning Lorenz
<henning.lorenz-wmbx2sCzPmCzQB+pC5nmwQ@...2053...> wrote:
Then I changed the colour in the source, but there is a principal question: Is something wrong and if so, what? And why doesn't this affect the "pattern-pinstripes-diagonal" pattern? Maybe I just missed an important point in constructing patterns in inkscape?
It's hard to visualize what you're talking about without a sample or screenshot. However one thing you should be aware of is this: "Object to pattern" creates a rectangular pattern with its sides parallel to x/y axes. Only after that can you rotate or skew it. So if your existing pattern is rotated or skewed, then converting it to objects and then back to pattern will not give the same result. If you want to edit it, first rotate the pattern so it's rectangular, convert to objects, edit, convert to pattern, and rotate back to the original angle.
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=D... Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
On 11/30/06, Henning Lorenz <henning.lorenz@...2052...> wrote:
I discovered now the reason for the mismatch:
The problem is that inkscape takes the path AND its stroke width into account when processing a tile clone, i.e. the offset of the new rows and columns is not based on the centre of the line but on the outline of it which depends on the stroke width (see attached screen shot). However, to produce a pattern which is good for a patternfill it is necessary that this process is based only on the centre of the line, i.e. the offset of the new rows and columns is independent from stroke-width.
Why are you using both tile clones AND pattern fill? Won't one of them suffice?
(Screenshot: thin line results in small offset, thick line results in larger offset - take the grid as a reference; to make the pattern suitable for a fill pattern each line has to be place on the grid without offset)
For such a pattern, I would take a filled rectangle, not a stroke, and tile it when it's horizontal, then rotate the entire pattern. This would give you a seamless pattern.
We can provide a number of user setting for how the bounding box of an object is calculated: with or without stroke (currently with), with or without markers (currently with), with or without the blurred margin (currently without). Does anyone think it might be a good idea? I'd like to avoid the burden of supporting several different modes, but several people have requested the "without stroke" bboxes.
As for clipping, it's still relatively new, and may be poorly tested in combination with patterns etc. If you investigate the problem and submit a detailed bug report with sample files that would help a lot.
Why are you using both tile clones AND pattern fill? Won't one of them suffice?
Tile clone is ideal to produce a regular pattern. Of course I can then use the objects produce by tile clone and clip them to the shape I need. Much more comfortable is of course to make a pattern of it and use it easily with all shapes that should be filled.
For such a pattern, I would take a filled rectangle, not a stroke, and tile it when it's horizontal, then rotate the entire pattern. This would give you a seamless pattern.
I'll try, thanks.
We can provide a number of user setting for how the bounding box of an object is calculated: with or without stroke (currently with), with or without markers (currently with), with or without the blurred margin (currently without). Does anyone think it might be a good idea? I'd like to avoid the burden of supporting several different modes, but several people have requested the "without stroke" bboxes.
I think it would be very helpful. For me the "with stroke" is very irritating, e.g. object location (x,y) and dimensions (in the toolbar) change when I change stroke width.
As for clipping, it's still relatively new, and may be poorly tested in combination with patterns etc. If you investigate the problem and submit a detailed bug report with sample files that would help a lot.
I'll do that as soon as possible.
Henning
bulia byak wrote:
We can provide a number of user setting for how the bounding box of an object is calculated: with or without stroke (currently with), with or without markers (currently with), with or without the blurred margin (currently without). Does anyone think it might be a good idea? I'd like to avoid the burden of supporting several different modes, but several people have requested the "without stroke" bboxes.
Is there a reason to use the bounding box calculation with stroke? In any case, I would love to see a bounding box calculation without stroke (if I am really interested in the stroke I'll convert it to a path). As for markers, personally I think it would make sense to also leave them out of the bbox calculation.
On 12/8/06, Jasper van de Gronde <th.v.d.gronde@...226...> wrote:
Is there a reason to use the bounding box calculation with stroke? In any case, I would love to see a bounding box calculation without stroke (if I am really interested in the stroke I'll convert it to a path). As for markers, personally I think it would make sense to also leave them out of the bbox calculation.
It was without stroke before, and listed as a bug for a long time until finally fixed. I remember there were many problems with stroke-less bboxes, such as clipped bitmap export for example.
bulia byak wrote:
On 12/8/06, Jasper van de Gronde <th.v.d.gronde@...226...> wrote:
Is there a reason to use the bounding box calculation with stroke? In any case, I would love to see a bounding box calculation without stroke (if I am really interested in the stroke I'll convert it to a path). As for markers, personally I think it would make sense to also leave them out of the bbox calculation.
It was without stroke before, and listed as a bug for a long time until finally fixed. I remember there were many problems with stroke-less bboxes, such as clipped bitmap export for example.
I can imagine you'd want to incorporate the stroke whenever you're interested in determining the area covered by the shape (when doing things like hit-testing, or indeed when exporting a bitmap), but when the size of the shape is displayed to the user (and when creating tilings for example) I think it makes a lot less sense.
On 12/8/06, Jasper van de Gronde <th.v.d.gronde@...226...> wrote:
I can imagine you'd want to incorporate the stroke whenever you're interested in determining the area covered by the shape (when doing things like hit-testing, or indeed when exporting a bitmap), but when the size of the shape is displayed to the user (and when creating tilings for example) I think it makes a lot less sense.
I guess that's subjective and depends on what kind of work you do. For technical drawing, you are perhaps more interested in sizes that disregard strokes. But for artistic drawings, the "size" of an object is synonymous to its area coverage. And it's not only about the size displayed in the toolbar. It's also affects the displayed selection box (which may look rather unintuitive without taking stroke into account if the stroke is wide enough) and scaling behavior (which may be weird if you have a small object with wide stroke).
I guess that's subjective and depends on what kind of work you do. For technical drawing, you are perhaps more interested in sizes that disregard strokes. But for artistic drawings, the "size" of an object is synonymous to its area coverage.
I think some things (e.g. selection outlines) should probably always use the visual bbox. But the line between "technical" and "artistic" can be very fine. Even if we ignore technical users, there are artistic users (including myself) who sometimes require geometric bounds -- tiling is one of the most common cases, but there are others as well.
We need to have a better solution in those situations, because there, the lack of geometric bounds isn't just annoying, it's debilitating. I just wish I knew what that solution was. :/
-mental
On 12/8/06, MenTaLguY <mental@...32...> wrote:
I think some things (e.g. selection outlines) should probably always use the visual bbox. But the line between "technical" and "artistic" can be very fine. Even if we ignore technical users, there are artistic users (including myself) who sometimes require geometric bounds -- tiling is one of the most common cases, but there are others as well.
We need to have a better solution in those situations, because there, the lack of geometric bounds isn't just annoying, it's debilitating. I just wish I knew what that solution was. :/
I can change it back, but I don't want to get back all the problems we had with no-stroke bboxes, and I don't really want to introduce a user option which will be hard to explain to the user and a maintenance burden. On the other hand, we now have an even worse option in Options
Tools > Selector > Default scale origin, which is highly obscure and
rather buggy. It seems to me that if we add a "bounding box includes stroke" option we'll be able to get rid of that "default scale origin" which is a good thing in itself.
It would be still better to find a compromise which would work for everyone and therefore not require an option. Suggestions are welcome. Please also consider that we now have blur, and in at least some cases, it makes perfect sense to include the blur margin in the bbox too.
It'd at least be an incremental improvement if we had an option to select between "visual" (which should include filter area, IMO) and "geometric" bounding boxes.
But there are still a lot of questions around that: which things should it affect? As I noted before, I think selection cues should always correspond to the visual, and probably also selection/click sensitivity as well. Also, should it be one option for everything, or individual settings for separate purposes?
Here's an idea: what about making bbox calculation for most purposes geometric when in outline mode, and visual when in normal mode? I think that should interact well with people's expectations.
-mental
On 12/8/06, MenTaLguY <mental@...32...> wrote:
But there are still a lot of questions around that: which things should it affect?
Exactly - that's what we need, an analysis of all the places a bbox is used/displayed with an assessment of whether that place should use stroke/blur or not.
As I noted before, I think selection cues should always correspond to
the visual, and probably also selection/click sensitivity as well.
I think I agree.
Also, should it be one option for everything, or individual settings for separate purposes?
It's best to minimize options, of course.
Here's an idea: what about making bbox calculation for most purposes geometric when in outline mode, and visual when in normal mode? I think that should interact well with people's expectations.
I'm not sure. Changing e.g. scaling or snapping behavior depending on mode does not sound like a good idea to me. Also, it is useful to have the bbox show me the extent of the object with stroke even in outline mode - that way, I can see how wide is the stroke even without seeing the stroke itself.
bulia byak wrote:
On 12/8/06, MenTaLguY <mental@...32...> wrote:
But there are still a lot of questions around that: which things should it affect?
Exactly - that's what we need, an analysis of all the places a bbox is used/displayed with an assessment of whether that place should use stroke/blur or not.
That is definitely a good idea, to start this off I looked at the SVG specification to see what should be used for SVG, and if I read it correctly (Batik and Firefox seem to agree with me btw) Inkscape should at least ignore strokes when calculating bounding boxes for objectBoundingBox units:
"The bounding box is computed *exclusive* of any values for clipping, masking, *filter effects*, opacity and *stroke-width*."
See: http://www.w3.org/TR/SVG11/coords.html#ObjectBoundingBox
I filed this as bug 1612108 (with a test case which shows the problem).
(Note that the SVG test suite apparently doesn't test this, I could only find tests that don't use stroke or use userSpaceOnUse units.)
On 12/9/06, Jasper van de Gronde <th.v.d.gronde@...226...> wrote:
"The bounding box is computed *exclusive* of any values for clipping, masking, *filter effects*, opacity and *stroke-width*."
See: http://www.w3.org/TR/SVG11/coords.html#ObjectBoundingBox
I filed this as bug 1612108 (with a test case which shows the problem).
Thanks, that's a good point - it concerns SVG compliance and therefore must be fixed regardless of what we decide for other visual and UI aspects of bboxes. Unfortunately this means that at the moment, we display gradients, patterns, clippaths and masks slightly wrong when they have objectBoundingBox units and apply to an object with stroke, and their display will change when we fix this. But the good news is that Inkscape does not create objectBoundingBox itself (except filter areas I think), so such files can only come from elsewhere. If a gradient has objectBoundingBox units, it is converted to absolute units as soon as you edit the gradient or the object that uses it. So, this fix is likely to have a relatively low impact.
As for clipping, it's still relatively new, and may be poorly tested in combination with patterns etc. If you investigate the problem and submit a detailed bug report with sample files that would help a lot.
I cannot reproduce it now but will report when I come across the peculiar behaviour again.
participants (4)
-
bulia byak -
Henning Lorenz -
Jasper van de Gronde -
MenTaLguY