Bug report #454
fill pattern rendered extremely thick
Status: | Closed | ||
---|---|---|---|
Priority: | Low | ||
Assignee: | Marco Hugentobler | ||
Category: | - | ||
Affected QGIS version: | master | Regression?: | No |
Operating System: | All | Easy fix?: | No |
Pull Request or Patch supplied: | No | Resolution: | fixed |
Crashes QGIS or corrupts data: | No | Copied to github as #: | 10513 |
Description
Lines and points in the fill pattern are rendered extremely thick compared to the Map View. See the atached screen dumps and their respective pdf output.
Maciek
History
#1 Updated by Redmine Admin almost 18 years ago
To fix this we must enable pattern scaling. That should be possible using QBrush::setMatrix which was introduced in Qt 4.2 but it requires changes in QgsVectorLayer and all renderers classes including changes of methods' prototypes of course composer map GUI. That cannot be done a week before code freeze IMO.
BTW it seems that Qt prints patterns as rasters so it is rather useless.
We could use a hack and set the matrix on QPainter and read the value in renderers but it will be better to do it well in 0.9.
Radim
#2 Updated by Redmine Admin almost 18 years ago
It worked OK in 0.74. I'm attaching two epss created in 0.74 with 100 and 200 dpi respectively. As you can see by changing dpi setting it was possible to control the pattern scale; in default 300 dpi the pattern in the eps output matched the Map View quite OK in 0.74. It's got broken in 0.8.
If pattern scaling is really not possible in 0.8 at the moment, at least please do something so that the pattern isn't so extremly thick as currently; make it match the Map View somewhat.
Maciek
#3 Updated by Redmine Admin almost 18 years ago
Might be related to #444?
#4 Updated by Gary Sherman almost 18 years ago
This sounds like a problem introduced by the move from Qt 3.x to 4.2. We may have to push this back to 0.8.1 for reconsideration.
#5 Updated by Redmine Admin almost 18 years ago
Furthermore, in case of shapefiles with holes, only the hole is filled in the print (everything is filled on the screen - none of them is the desired outcome). See attached files.
#6 Updated by mapping-gp_at_gmail-com - almost 18 years ago
I have a user work-around for this and to ticket #444? (as mentioned above which I also think is related). Although its only a user work-around it may be instructive from a programming perspective.
User fix: In composer make the page size large. I chose ISO A0 but depending on your circumstances you could use an even larger custom size. This then allowed me to use 'Line Width', 'Symbol', & 'Font size' scales of 1 or above. It seems that if the scaling factor is less 1 --chunky graphics result. This can also be seen to be the case for ticket #444 were the symbol scale factor is set to 0.5. Font scaling factors of much less than 1 cause the font to be unreadable.
This also fixes the same problem with legends and scale bars.
To print to a smaller page size you must produce a PNG file using above method and insert in OpenOffice document or some other similar app.
The dpi setting doesn't help in the above fix. [but does seem to have some odd qwerks. For instance , I set it to dpi=200 this works fine and produces a file of about 1.1MB. I then change it to dpi=210 and I get a warning from Composer which tells me "To create image 6953 x 9830 requires circa 205 MB of memory" -- This seems a bit excessive for such a small dpi change. If I click 'OK' to do it anyway it produces a file of about 1.1MB.]
BTW - I'm using:
Ubuntu Edgy on Pentium4
Version 0.8.0 (6200M) "Titan preview2"
Compiled against Qt4.2.0, running against same.
Compiled against GDAL/OGR 1.3.2.0, running against same.
Ubuntu Edgy QGIS set from: Les-ejk UbuntuGIS repository by Jachym Cepicky at http://les-ejk.cz/ubuntu (Thanks Jachym - works well - nice job).
Gary.
#7 Updated by Gavin Macaulay - almost 18 years ago
Another symptom is in ticket #526
#8 Updated by Tim Sutton over 17 years ago
Moved to milestone 0.8.2 since we wont be fixing any further issues before the 0.8.1 release
#9 Updated by Maciej Sieczka - almost 17 years ago
Still present in SVN 4c3169ff (SVN r8096), built and running against QT 4.3.3.
#10 Updated by Tim Sutton over 16 years ago
Can you test this once the new print composer code from Marco Hugentobler is merged in and then verify if the issue still exists? I'm going to assign this ticket to Marco so he can keep it in mind while testing his branch.
Regards
Tim
#11 Updated by Maciej Sieczka - over 16 years ago
I'll keep an eye on that. Cheers.
#12 Updated by Maciej Sieczka - about 16 years ago
The bug is still present in the new map composer (SVN trunk 0a6dbb71 (SVN r9259), QT 4.4.0, Debian testing amd64).
See the attached attached screendumps and the output PDF:
display-OK.png - a polygon in QGIS filled with Dense7 pattern
composer-OK.png - looks OK in print composer...
pdf-BAD.png - ...but in the output PDF the pattern is very oversized
pattern_too_big.pdf - the pdf output itself
This bug virtually disables pattern usage in print composer.
#13 Updated by Marco Hugentobler about 16 years ago
This is adressed in r. Unfortunately, it does only work for ps, not for pdf output. This is probably a Qt bug.
#14 Updated by Maciej Sieczka - about 16 years ago
Replying to [comment:16 mhugent]:
This is adressed in r.
(That's 911038bb (SVN r9282).)
Unfortunately, it does only work for ps, not for pdf output. This is probably a Qt bug.
On my machine it doesn' work for either now. See attachments.
In PDF - no change, the pattern is too thick as it was.
In PS - no pattern at all.
On display and in the map composer looks OK.
Debian testing amd64, QT 4.4.0. What is yours?
#15 Updated by Paolo Cavallini over 15 years ago
I confirm, it happens with pdf (ps possibly ok). libqt4-core 4.5.1 on Debian testing
#16 Updated by Giovanni Manghi over 15 years ago
By the way,
quick print seems to give much better results (qgis 1.2 rev. 11023) than normal print does (see attached files). Is the solution near?
#17 Updated by Marco Hugentobler almost 15 years ago
- Resolution set to fixed
- Status changed from Open to Closed
In 697ef558 (SVN r12778), there is a SVG fill renderer in the new symbology that is supposed to scale properly to the print resolution. I'm therefore closing this ticket.
#18 Updated by John Tull over 12 years ago
- Affected QGIS version set to master
- Pull Request or Patch supplied set to No
- Crashes QGIS or corrupts data set to No
Did this crop back up again in the 2.0 trunk? I have scaling issues again with output to pdf as non-raster.