Bug report #4046
Composer raster problem printing - PDF
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: | - | ||
| Category: | - | ||
| Affected QGIS version: | master | Regression?: | No |
| Operating System: | Win7 | Easy fix?: | No |
| Pull Request or Patch supplied: | No | Resolution: | duplicate |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 14032 |
Description
Duplicate I suspect of issue closed earlier - below. I can reproduce this in trunk and 1.7 on Win7.
It is only associated with the pdf engine in composer.
If I ouput to a pdf driver installed as a printer it does not offest, i.e. prints correctly. Also prints correctly via native SVG engine. However if I use the pdf engine in composer it clearly offsets the raster from the correct position.
A major issue has cropped up with the handling of raster data in composer output. Rasters appear to be rendered multiple times with a datum shift at each render. I've attached an example I made using the spearfish data (geology raster layer and archsites vector layer). This should be replicable, but testing by others would be appreciated. I used default settings for the composer item (A4, landscape page). Printing as raster, vector, exporting as image—all have the same result as shown below.
History
#1
Updated by Bill Williamson over 13 years ago
I am having trouble adding a file to show this problem, are there only some image types which suit redmine? The extent of the offset I am seeing is not as great as the original ticket
#3622
#2
Updated by Nathan Woodrow over 13 years ago
- File Test.pdf added
- Priority changed from Low to Normal
Confirmed on WinXP
#3
Updated by Jürgen Fischer over 13 years ago
- Resolution set to duplicate
- Pull Request or Patch supplied set to No
- Status changed from Open to Closed
duplicate of #3028
#4
Updated by Bill Williamson over 12 years ago
- Affected QGIS version set to master
- Crashes QGIS or corrupts data set to No
This appears to be happening again.
#5
Updated by Giovanni Manghi over 12 years ago
Bill Williamson wrote:
This appears to be happening again.
can you be more specific? That would allow me to do some test and eventually re-open the ticket or file a new one.
#6
Updated by Bill Williamson over 12 years ago
- File test_redacted.pdf added
Sorry G,
In 1.8 Trunk, I have a project which uses Google Steets / Openlayers as a background. It renders the map OK in print composers, nicely aligned, but on printing or pdf it offsets the underlying Openlayer. It is the same effect as this earlier ticket when underlying rasters were being offset.
I am trying to unpick the project but have had no luck so far in retracing my steps.
Attached is the effect.
The property boundary in the mid left should align but doesn't.
Appreciate your time on this.
#7
Updated by Giovanni Manghi over 12 years ago
Bill Williamson wrote:
Sorry G,
In 1.8 Trunk, I have a project which uses Google Steets / Openlayers as a background. It renders the map OK in print composers, nicely aligned, but on printing or pdf it offsets the underlying Openlayer. It is the same effect as this earlier ticket when underlying rasters were being offset.
I am trying to unpick the project but have had no luck so far in retracing my steps.
Attached is the effect.
The property boundary in the mid left should align but doesn't.
Appreciate your time on this.
Hi Bill,
as far as I know printing in the composer of the layers available with the Openlayers plugin is not supported (the overlays do not align), I believe the main issue is that such layers are available only at prefixed scales. On the other hand with standard WMS layers there are no issues. See the attached screenshots.
#8
Updated by Bill Williamson over 12 years ago
With the latest trunk, and latest update of the openlayers plugin, this problem has gone away for me.
ta