Wrong Label Scaling in Print or PDF

[qgib]

Author Name: Andreas Neumann (@andreasneumann)
Original Redmine Issue: 7627
Affected QGIS version: master

Assignee: Larry Shaffer

---

When printing to the Printer or PDF the labels are rendered way too big. There seems to be a DPI problem or label scaling problem.

The display on the screen is fine, but the printed output has wrong label scaling.

As a result, labels also overlap - see attached PDF file.

Thank you for having a look at this issue.

---

• grundplan_av_win_master.pdf (Andreas Neumann)

[qgib]

Author Name: Larry Shaffer (Larry Shaffer)

---

Confirmed here on Mac. Looking into it.

[qgib]

Author Name: Tim Sutton (Tim Sutton)

---

Yes I was about to report the same issue here. Confirmed again on OSX. I think its only in the last few days that the regression happened.

[qgib]

Author Name: Jürgen Fischer (@jef-n)

---

bisecting leads to 8749b29. I suppose @QPainter::drawPicture@ doesn't work correctly, when the paint device is a printer.

[qgib]

Author Name: Larry Shaffer (Larry Shaffer)

---

Jürgen Fischer wrote:

bisecting leads to 8749b29. I suppose @QPainter::drawPicture@ doesn't work correctly, when the paint device is a printer.

That's exactly the problem, and I am "working on a fix":https://github.com/dakcarto/Quantum-GIS/commits/labeling_pdf-export-fix_2. I have it functional for text, buffers, and backgrounds but still have issues with shadows. The approach scales the QPicture-related painters by a ratio of their native paint device dpi versus the dpi of the QgsRenderContext's painter, if different. Seems to work well, but requires more testing.

If that doesn't solidly work, I can fall back to the previous means of direct painting with the QgsRenderContext's painter, but this will add more redundant code to functions that are already very procedural, and may require some rewriting of the shadow functionality which relies on the QPicture method.

Should be done by tonight.

[qgib]

Author Name: Larry Shaffer (Larry Shaffer)

---

Seems to be fixed with commit 046fbee

My projects are probably not complex enough to fully test, and I don't produce PDFs via QGIS Server calls, so please put it through the paces. If it works well, I won't be touching that code again without some solid units tests with image comparisons (at least 12 of them). :^)

[qgib]

Author Name: Andreas Neumann (@andreasneumann)

---

Hi Larry,

I tested with QGIS Server. It works fine. I can test with QGIS Desktop at home.

Thanks - I am very glad this is fixed.

Andreas

[qgib]

Author Name: Larry Shaffer (Larry Shaffer)

---

Hi Andreas,

I don't have a QGIS Server setup on this Mac, yet. So, any info on how the backgrounds and shadows look when served would be helpful. Thanks!

The rendering of text and buffer is the most important, and while we can always fall back to the previous method of painting those, I would prefer to continue using the stored QPicture method I am using now. This is because such a method will probably continue to be used when all label rendering components (text, buffer, background) get moved to ng-symbology marker classes and showdows still need applied. Once moved to symbology, things should get a bit simpler (or at least more flexible) as that code is much more object-oriented.

[qgib]

Author Name: Andreas Neumann (@andreasneumann)

---

we can close this bug - and reopen another one if there are other or additional issues. The label scaling itself works fine now.

---

• resolution was changed from to fixed

[qgib]

Author Name: Andreas Neumann (@andreasneumann)

---

• status_id was changed from Open to Closed