https://bugs.kde.org/show_bug.cgi?id=516625
Bug ID: 516625
Summary: Windows version – Printing output scaled down despite
100% scaling and driver-level “No scaling”
Classification: Applications
Product: okular
Version First 25.12.2
Reported In:
Platform: Microsoft Windows
OS: Microsoft Windows
Status: REPORTED
Severity: critical
Priority: NOR
Component: printing
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Environment
OS: Windows 10 Pro 64-bit
Okular version: 25.12.2
Installation types tested:
Microsoft Store (MSIX)
Standalone .exe installer
Printer: HP LaserJet Pro M203dw (network, Ethernet TCP/IP)
Paper size: A4
PDF source: Generated from Microsoft Excel
Display scaling: 100%
Comparison viewers:
SumatraPDF (prints correctly at true 1:1 scale)
Microsoft Edge (prints correctly)
Issue Description
When printing from Okular on Windows, the output is consistently reduced in
size, even when:
Print scaling is set to 100%
“Fit to page” / “Shrink to printable area” are disabled
Native system print dialog is used
Printer driver scaling is set to:
“Actual size”
“No scaling”
Paper size matches document size (A4 → A4)
The printed document appears uniformly scaled down.
The footer (page number) is shifted upward, indicating global scaling rather
than clipping.
The same PDF prints correctly (true 1:1 layout) from:
SumatraPDF
Microsoft Edge
This suggests the issue is specific to Okular’s Windows printing backend.
Diagnostic Steps Already Performed
Tested both MSIX (Store) and standalone .exe versions.
Overrode High DPI scaling in Windows compatibility settings.
Tested with Windows display scaling at 100%.
Printed to physical printer and to “Microsoft Print to PDF”.
Installed and tested HP Universal Print Driver:
PCL6 (default)
PostScript (v8.1.0)
Created manual TCP/IP port using IPv4 (not WSD).
Disabled all scaling options at driver level.
Confirmed identical behavior regardless of driver scaling configuration.
Note:
The HP M203dw does not support native PostScript, so PS driver jobs remain in
queue. However, the scaling issue persists independently of driver type.
Observed Behavior
Okular appears to reduce content to fit within printer-reported hard margins.
Scaling occurs even when 100% scale is selected.
Behavior is consistent across different printer configurations.
Printing to virtual PDF also shows layout reduction.
Expected Behavior
When scaling is set to 100% and paper size matches the document, Okular should:
Preserve exact 1:1 layout
Not apply additional automatic scaling
Match output from other PDF viewers
Technical Hypothesis
The issue may be related to Qt’s QPrinter handling on Windows:
Strict interpretation of printer hard margins
Automatic internal scaling to avoid clipping
Difference between Qt Windows print backend and native Windows rendering
Other viewers (SumatraPDF, Edge) appear to ignore or compensate for driver hard
margin reporting, resulting in true 1:1 output.
Impact
This affects professional and institutional use cases where exact layout
reproduction is required, such as:
Official documents
Technical reports
Budget sheets
Government documentation
Accurate 1:1 printing is critical in these contexts.
Thank you for maintaining Okular
--
You are receiving this mail because:
You are watching all bug changes.
