Bug report #7627

Wrong Label Scaling in Print or PDF

Added by Andreas Neumann over 11 years ago. Updated over 11 years ago.

Status:Closed
Priority:Severe/Regression
Assignee:Larry Shaffer
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 #:16550

Description

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 (777 KB) Andreas Neumann, 2013-04-16 08:11 AM

History

#1 Updated by Larry Shaffer over 11 years ago

Confirmed here on Mac. Looking into it.

#2 Updated by Tim Sutton over 11 years ago

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.

#3 Updated by Jürgen Fischer over 11 years ago

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

#4 Updated by Larry Shaffer over 11 years ago

Jürgen Fischer wrote:

bisecting leads to 8749b29936. 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. 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.

#5 Updated by Larry Shaffer over 11 years ago

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). :^)

#6 Updated by Andreas Neumann over 11 years ago

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

#7 Updated by Larry Shaffer over 11 years ago

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.

#8 Updated by Andreas Neumann over 11 years ago

  • Resolution set to fixed

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

#9 Updated by Andreas Neumann over 11 years ago

  • Status changed from Open to Closed

Also available in: Atom PDF