fill pattern rendered extremely thick

[tutey@…]

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

[rblazek]

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

[tutey@…]

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

[cavallini@…]

Might be related to #444?

[gsherman]

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.

[cavallini@…]

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.

[cavallini@…]

pdf output (only hole filled)

[cavallini@…]

screen display (all is filled, including holes)

[mapping.gp_at_gmail.com]

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.

[g_j_m]

Another symptom is in ticket #526

[timlinux]

Moved to milestone 0.8.2 since we wont be fixing any further issues before the 0.8.1 release

[msieczka]

Still present in SVN r8095, built and running against QT 4.3.3.

[timlinux]

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

[msieczka]

I'll keep an eye on that. Cheers.

[msieczka]

The bug is still present in the new map composer (SVN trunk r9258, 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.

[msieczka]

pattern fill looks OK in composer...

[msieczka]

pattern fill looks OK on display...

[msieczka]

...and in composer...

[msieczka]

... but is wrong in the PDF output

[msieczka]

the PDF itself

[mhugent]

This is adressed in r. Unfortunately, it does only work for ps, not for pdf output. This is probably a Qt bug.

[msieczka]

Replying to mhugent:

This is adressed in r.

(That's r9281.)

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?

[msieczka]

no change in PDF after r9281

[msieczka]

in PS no pattern at all, after r9281

[pcav]

I confirm, it happens with pdf (ps possibly ok). libqt4-core 4.5.1 on Debian testing

[lutra]

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?

[mhugent]

In r12777, 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.