Bug report #7627
Wrong Label Scaling in Print or PDF
|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|
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.
#4 Updated by Larry Shaffer over 7 years ago
Jürgen Fischer wrote:
bisecting leads to 8749b29936. I suppose
QPainter::drawPicturedoesn'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 7 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). :^)
#7 Updated by Larry Shaffer over 7 years ago
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.