Bug report #8975
line pattern fill: the style is applied to symbol border and not to line fills, as a user would expect
Status: | Closed | ||
---|---|---|---|
Priority: | Severe/Regression | ||
Assignee: | - | ||
Category: | Symbology | ||
Affected QGIS version: | master | Regression?: | No |
Operating System: | Easy fix?: | No | |
Pull Request or Patch supplied: | No | Resolution: | fixed/implemented |
Crashes QGIS or corrupts data: | No | Copied to github as #: | 17636 |
Description
See attached image:
in the line pattern fill, when choosing the line style this is applied to the symbol border, not to lines used to create the fill, as user expect.
I'm not sure this is bug or it is by design. If it is the latter I would say that is wrong.
History
#1 Updated by Radim Blazek almost 11 years ago
Partially fixed in 8f8ea0e, the line symbol layer is now used for fill, outline is not drawn (like with point pattern fill). The color and width should be probably removed from line pattern fill widget.
The problem is, that current implementation is based on tiles (QgsImageFillSymbolLayer) and line patterns may become discontinuous. I am not even sure if it is possible to always find a tile size with continuous pattern for arbitrary pattern length (or lengths if there are multiple lines) and angle. If yes, it can be quite big. It could be easier to render a tile image big as current extent but that can cause problems with performance and PDF output?
#2 Updated by aperi2007 - almost 11 years ago
Yes the border problem seem resolved.
The problem is, that current implementation is based on tiles (QgsImageFillSymbolLayer) and line patterns may become
discontinuous. I am not even sure if it is possible to always find a tile size with continuous pattern for arbitrary
pattern length (or lengths if there are multiple lines) and angle. If yes, it can be quite big. It could be easier to
render a tile image big as current extent but that can cause problems with performance and PDF output?
How many pixel is the tiles size ?
The problem you report could be due to video resolution.
Perhaps it is not a problem with a print resolution (300dpi or more) ?
#3 Updated by Paolo Cavallini almost 11 years ago
IMHO the problem will be apparent with any device: the discontinuity between adjacent tiles will always be visible unless a different approach will be taken.
I suggest closing this, as it appears solved, and opening another one.
#4 Updated by Paolo Cavallini almost 11 years ago
- Status changed from Open to Closed
- Resolution set to fixed/implemented
#5 Updated by Mathieu Pellerin - nIRV almost 11 years ago
IMO, this needs to be re-opened as follow-up clean ups are needed:
1/ Saved symbols that relies on line pattern fill are now broken: migration code is needed to upgrade the symbol(s) to 2.1/2.2 logic
2/ Color widget in the line pattern fill panel is not working / ignored: the color is now set via the simple line panel, but right now, this is all very confusing as the line pattern fill color widget is still present
3/ Line width input from the line pattern fill panel is not working / ignored: as with the point above, this setting is now adjustable within the simple line panel, but the width input is still present in the pattern fill panel, very confusing for any user, especially the ones that will have used this symbology type prior to the above changes
#6 Updated by Giovanni Manghi almost 11 years ago
- Affected QGIS version changed from 2.0.1 to master
- Resolution deleted (
fixed/implemented) - Priority changed from Normal to Severe/Regression
- Status changed from Closed to Reopened
#7 Updated by Radim Blazek almost 11 years ago
- File tile-ok.png added
- File tile-err.png added
aperi2007 - wrote:
How many pixel is the tiles size ?
The problem you report could be due to video resolution.
Perhaps it is not a problem with a print resolution (300dpi or more) ?
The problem is principle. It is impossible to create repeatable tile for arbitrary marker line interval, line pattern distance (between lines) and angle. It is possible for angles 0, 90 deg and 45 deg where the marker interval is integer multiple of distance between lines. See attached pictures tile-ok.png and tile-err.png.
I'll try to fix these three cases.
Another problem is that multiple line patters may have different interval. In the worst case, the common interval (least common multiple) is multiplication of intervals. However, because patterns without a small common interval would look strange, we can probably simply take the longest.
#8 Updated by Radim Blazek almost 11 years ago
This issue has common background with #8974, some problems you may find testing this issue were fixed there.
#9 Updated by Radim Blazek almost 11 years ago
Color/width: removed from QgsLinePatternFillSymbolLayerWidget in 95c3c6f because such options (for sub symbols) are not present in other compound layers (marker line, outline marker line,...).
It is still possible to overwrite layer of all sub layers from the top level fill symbol. In the same way like it is possible for other symbol layers. This is still a bit confusing (for all symbols, out of this issue scope), because if sub layers are changed the top symbol color remains unchanged, it should be probably synced with sub colors if possible (all the same) or blurred if there are multiple sub colors.
#10 Updated by Radim Blazek almost 11 years ago
Vertical and horizontal markers lines fixed in c21973f.
The longest interval is taken as pattern length. Smaller intervals must fit to the longest interval (the longest must be multiple of all smaller intervals). For example intervals 8,4,2 are OK but 8,5 are bad. Otherwise the pattern will be discontinuous. This is feature (at least for now).
#11 Updated by Radim Blazek almost 11 years ago
Regarding backward compatibility. This was obviously buggy in 2.0 and I am not convinced that we have to keep backward compatibility with features broken in previous versions.
I am leaving this open for this last problem, but I am not going to fix that.
#12 Updated by Giovanni Manghi almost 11 years ago
I am leaving this open for this last problem, but I am not going to fix that.
I'm personally ok with this. When a new master build will be available I will test the rest and let you know.
Thanks!
#13 Updated by Paolo Cavallini almost 11 years ago
Agreed, no migration should be necessary
#14 Updated by Giovanni Manghi almost 11 years ago
- Resolution set to fixed/implemented
- Status changed from Reopened to Closed