Bug report #454

fill pattern rendered extremely thick

Added by Redmine Admin over 17 years ago. Updated over 11 years ago.

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

points.png (21.2 KB) Redmine Admin, 2006-12-13 12:04 PM

points.pdf (123 KB) Redmine Admin, 2006-12-13 12:04 PM

lines.png (21.9 KB) Redmine Admin, 2006-12-13 12:05 PM

lines.pdf (123 KB) Redmine Admin, 2006-12-13 12:05 PM

pattern_074.tar.bz2 (92.9 KB) Redmine Admin, 2006-12-17 10:53 AM

__stdin__.pdf - pdf output (only hole filled) (100 KB) Redmine Admin, 2006-12-28 11:29 PM

screen.jpeg - screen display (all is filled, including holes) (210 KB) Redmine Admin, 2006-12-28 11:30 PM

display-OK.png - pattern fill looks OK in composer... (20.8 KB) Maciej Sieczka -, 2008-09-05 01:01 AM

display-OK.2.png - pattern fill looks OK on display... (20.8 KB) Maciej Sieczka -, 2008-09-05 01:02 AM

composer-OK.png - ...and in composer... (13.1 KB) Maciej Sieczka -, 2008-09-05 01:02 AM

pdf-BAD.png - ... but is wrong in the PDF output (9.76 KB) Maciej Sieczka -, 2008-09-05 01:04 AM

pattern_too_big.pdf - the PDF itself (27.4 KB) Maciej Sieczka -, 2008-09-05 01:04 AM

print.pdf - no change in PDF after r9281 (35.2 KB) Maciej Sieczka -, 2008-09-07 09:29 AM

print.ps - in PS no pattern at all, after r9281 (76.6 KB) Maciej Sieczka -, 2008-09-07 09:30 AM

print_test.tar.gz (218 KB) Giovanni Manghi, 2009-07-04 03:02 PM

History

#1 Updated by Redmine Admin over 17 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 over 17 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 over 17 years ago

Might be related to #444?

#4 Updated by Gary Sherman about 17 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 about 17 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 - about 17 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 - about 17 years ago

Another symptom is in ticket #526

#8 Updated by Tim Sutton about 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 - about 16 years ago

Still present in SVN 4c3169ff (SVN r8096), built and running against QT 4.3.3.

#10 Updated by Tim Sutton over 15 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 15 years ago

I'll keep an eye on that. Cheers.

#12 Updated by Maciej Sieczka - over 15 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 over 15 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 - over 15 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 almost 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 14 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 about 14 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 11 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.

Also available in: Atom PDF